I'll start by quoting Brooks Law, as no doubt you expect me to:
Brooks's law is a principle in software development which says that "adding manpower to a late software project makes it later". It was coined by Fred Brooks in his 1975 book The Mythical Man-Month
The truth of this is blatantly obvious to anyone who has ever been involved in a project that was slipping its schedule. It is so blatantly obvious that The Mythical Man-Month is almost legendary in development circles largely due to that one brilliant observation.
The often suggested way to avoid Brook's Law biting your backside when you are faced with a project that is rapidly disappearing into the future is around segmentation, breaking your project into manageable chunks that can be developed in isolation. Teams can then take these chunks and develop while a core team is repsonsible for integration of their work. As Wikipedia correctly points out, when the segmentation is done poorly this can actually increase the time to deliver the project even more than just filling a single room with more developers - preventing developers on separate teams interacting easily, when they are actually working on common code is a near catastrophic mistake.
And now to my real point, correct segmentation can only work when there is a clear and clean architecture underlying the system upon which new developers and teams can easily add new functionality in complete and total isolation from each other, whilst still maintaining the integrity of the system.
One Common Vision
The architecture or framework is important in any project, it provides the one common point of reference that all developers have, a project can succeed or fail based solely on getting this part of the project right. Without this in place, all development work on the project is in real danger of producing an inconsistent and incohherent system, that at best will meet the majority of the business requirements but be totally unmaintainable over a period of time - a greenfield legacy system.
In a large project with multiple developers, and potentially multiple teams, the architecture is critical to the project success. Without this common vision teams will start going off at tangents, will duplicate work, and will spend more time trying to get their code to work nicely with their colleague's code than they ever will providing real business functionality.
And then Brook's Law not only hits you up the backside, it reverses back over you a few times just to be sure you are really suffering. Project managers, in a way that only project managers could do, ask for more developers to help integrate the code, and your descent into hell has begun.
So, if you do nothing else right on a project, get the fundamental architecture and framework right, early. Get a walking skeleton of all critical functionality running early against this architecture to prove it is right, and then ask the business to validate it. You will be amazed how much easier this will make things in the long run.
05-08-2008 8:39 AM