The same plight still exists today!

More than a decade ago, I read the famous book Mythical Man Month. It was developed by a smart software development manager who worked at IBM. In the book, he cited examples after examples about how simply adding more resources to a software project to avoid missing deadlines is not a good idea. Software engineering is not like other labor intensive work. After a certain point, adding more people will just slow down the whole process.

Ｉ read the book Agile Software Development a while ago. In appendix C of the book, two development scenarios are depicted. On the left hand side, it describes a poorly managed project. And on the right hand side, it outlines how it should be done. Unfortunately, many of us did experience the scenario on the left hand side, more often than we would like.

Software engineering methodology has evolved tremendously, from simple models like the waterfall, to extreme programming and agile methodology. It has become better and better. Unfortunately, many folks in charge of engineering haven't spent the time to learn these new methodologies. I was recently at a startup that was acquired by a relatively large software company. As usual, many original folks did leave the company after the acquisition. New management as well as developers have been put in place. The team is still trying to launch a significant release in the next few months. But management is committing all the mistakes outlined in both Mythical Man Month and Agile Software Development. The chance of a successful release is not very good. Staff turnover and low morale will probably result.

This is not only limited to product development. In the consulting team, the same situation happens. The executives are forcing the time consuming and pointless processes and tools onto all of us. At one point, the consultants were asked to generate 16 100-page documents for even a 2-3 week engagement. Needless to say, it doesn't make sense at all.

On the contrary, I came across many smaller and more nimble software houses. They embraced the new ideas, like test-driven development, pair programming, and short features stories. Those folks were so excited about their work. It is quite a contrast to the morale of the company I recently left.