A couple of books finally arrived yesterday. I started reading The Mythical Man Month, mostly because I've heard from so many different sources that it's a must read. And after three chapters, I can only agree...
So here are the key observations as I see it. Mostly so I'll remember the important parts myself :)
Feel free to chip in.
1 - The Tar Pit
Large scale programming is different from programming in the small. It requires a lot more non-programming stuff to be finished, like testing, documentation, integration etc.
"Human beings are not accustomed to being perfect, and few areas of human activity demand it. Adjusting to the requirement for perfection is, I think, the most difficult part of learning to program."
2 - The Mythical Man Month
We are bad at estimating, which at heart is based on the false assumption that all will go well.
Programmers are optimists.
The incompleteness of our ideas only become evident during implementation. Practice is important for theory.
For any single task, a bad estimate isn't so important. But tasks add up, and in sequence they are very unlikely to conform to the total estimate.
Tasks can be implemented in parallell only if they are independent and require no communication effort on the part of the designers/programmers. If not, the communication effort adds overhead which may overcome the effect of more people.
We must have courage to stand by our estimates, in spite of outside pressure. "The urgency of the patron may govern the scheduled completion, but it cannot govern the actual completion."
Adding manpower to a late project makes it later.
The incompleteness of our ideas only become evident during implementation.
That's why the agile methods prefer to deliver software early and often. The sooner you can get to the implementation, the sooner you start getting feedback from the code and the customer about what's really going on.
That's not appropriate in all situations, but it works for a great deal of the modern programming world. Treating every project as if it were a massive engineering project hasn't done the software world many favors.
Re: Implementation Revelations
jplindstrom on 2003-05-16T22:02:49
This is my experience too. Having business analysts dream up requirements without touching base with the nitty gritty details of reality can lead to the most complex and convoluted designs.
The most annyoing thing with that is that as requirements are added to an inconsistent model, it's impossible to incorporate them with the existing solution without working around previous bad design desicions, which were possibly forced by other bad desicions etc, etc. It inevitably leads to a fragile and strict set of business rules.
Come to thing of it, it all resembles the way people thought the moon moved way back (Ptolemy?). The moon movement was described as a perfect circle. Only it didn't work, so they added other perfect circles on top of it to match the observed movement. Then yet more perfect circles...
So starting with a small, simple idea is a good way of avoiding complexity in the first place.
And if it doesn't express all of the business requirements, maybe some of the business requirements should be re-evaluated. Complex business rules implemented, even in a rock-solid way, are a bad sign. Especially if you're gonna communicate them to, or let them affect, customers. This is by definition often the case.
