Thoughts on Software Engineering

Monday, December 06, 2010

Oh NO!!! All the processes are not just flexed version of the Waterfall, just to support the client's need for viewing the product

I disagree. Everything in this world is process-driven. Whether you are traveling in a public transport vehicle or you have to book a gas cylinder or for that matter, even if you need admission in a college, you follow a process. Software development is no different. Every process has its own set of roles; each having some responsibilities. Every process has associated products that it uses and another set that it delivers. There are several stake-holders in all cases; client is just one stake-holder in the case of software product development. Processes are mandatory in a software eco-system to socially co-exist and run efficiently performing and highly impacting teams.

Coming to the nature of waterfall, it has been widely accepted that software systems are not typically built to an agreed specification. It is not like manufacturing a mobile phone, for example. In most cases, software systems evolve. For example, you do not make a N95 mobile, sell it to user, take it back, modify it again and ask the same user to now use it again! N95 does not evolve. Nokia builds N95 as a product towards a specification that it thinks will work the best and sells it hoping that it will work. If you consider a vocabulary tool as a product and if your team is an expert team in technology, product visualization, design, etc., you will probably be able to come up with a specification in just two days and implement to that specification in a matter of 2 or 3 weeks. In such cases, we could really stick to waterfall.

Processes are tools to work in an eco-system and socially co-exist in such a way that every stake-holder finds a satsifactory role/benefit.

All that said, processes should not be confused with lifecycle models. These are two different things. Ultimately every human being take birth, eats food, lives for some time and dies. This is a very high level visualization of human lifecycle model. At this height, all is same! Constructing a under-sea railway track is not like constructing a out-house. Ultimately you may still generalize in saying that its just about understanding what to build, how to build and then build it!! I am sure the nature of stake holders and their roles will be drastically different in that case.

I encourage you to read articles such as "Mythical Man-Month" and the case of "Killer Robot". These are beautiful manifestation of software engineering issues. They bring out the essence of troubles a software engineer has to go through to successfully survive. You should then start appreciating the wide basket of choices we have at each step of software engineering and how this decision making becomes important and difficult in no time.

Thursday, December 02, 2010

Big Teams or Deep Technical Dives!

Have you ever wonedered what exactly growth means to you? If you have been a software engineer for reasonably long time, you should either have thought about taking more and more responsibilities and driving huge teams towards success. If this has not been the case, you have wanted to turn in an extremely techncial task that nobody else dreamt of closing & delivering so soon. I am kind of in a crazy territory, jumping across these two ends. Proabably as you tend to become a "true" software engineer, engineering good software products matter to you and not really what part of engineering thread that you hold.

------------------------------------------------
http://vvtesh.co.in
http://aptuse.com
http://pudida.com
http://sites.google.com/site/vvtesh