Software development is new product development

I read through the first few pages of a great book from Craig Larman, Agile and Iterative Development: A Manager's Guide. Actually read it online, using Amazon's online reader.

Most software is not a predictable or a mass manufacturing process. Software development is new product development.

So true! The two sentences above speaks a lot about how software development should be managed in terms of cost, human resource, time frame and maintenance. The only mass manufacturing part of software is when you copy it (copy ), burn it to the CD for distribution, upload it to the internet for download and/or seed it for torrent downloads.

One big word in software development is CHANGE. Change is constant in this type of work as new data and feedback comes up during the development process. Change should be part of the process and the software, like the code, should be able to change and adopt easily -- without losing a lot of momentum and work progress.

BUT, what is often common in software dev projects are: clients always asks for a fixed price, fixed time frame, fixed this, fixed that -- and at the same time, expects work that changes over time. They always expects a programmer to give them a date of when everything will be finished -- and they will even consider you incompetent if you can't give a definite date!

MORE BUT, another common misconception on software development is that more resources, more people, more code, more libraries, the more whatever will speed up the development process. A lot of programmers and dev team managers think this is a solution, since in a way, it is giving the clients a visible sign of progress -- more people typing on the keyboards! When in fact, this is the very reason why software projects fail and why they fail big!

In some projects, there are even two different teams of programmers working on the same product. One works on the current version (buggy perhaps) and another works on the next version. This might be ok if both teams has experience with both products for some time, and are working on the same dev process. However, in an effort to speed up the dev time -- some projects encourages both to work on their own process (which in a way is right, since more communication overhead, means less time coding). I don't think this is really going to work. Perhaps it will, and when that time happens -- i'm sure it will be worth a look, perhaps even a book written about it!

Anyway, the book talks more about these topics in details. Can't wait for our copy to get here, and explain more about how and why software development fails and how to manage it without losing your sanity.