 |
| Brooks's Law: Adding manpower to a late software project makes it later (page 25) |
From Chapter 2: "The Mythical Man-Month"
ExcerptThe law is pithy and clear; the graph illustrative. In the text, Brooks provides a cursory sketch of causes and some descriptive math to depict the relationship between labor and time. It's a tidy summary of what I've repeatedly experienced. It reaches into the heart of what traditionally has been called "the software crisis".1
There's no point in summarizing the chapter for the umpteenth time. The 'mythical man-month' has been a topic of research and discussion for decades. There's a zillion blogs, and journal articles. Rather, I plan to focus on my experiences coping with budget and schedule constraints, the underlying reasons for why they are what they are and how I managed overruns and slips.
A personal note... I can't read the chapter without a tightening of the gut. I was no match for the forces that drive the law. As a colleague often suggested(quoting a poster from Despair.com) "Perhaps the purpose of your life is only to serve as a warning to others." Sadly, I was succored by the struggles around me; I saw little objective evidence that any my colleagues or acquaintances were doing better. (However, the most successful were much better at managing perceptions--a topic for another day.)
I'll close this entry with an admonition for any software development manager with budget authority: you owe it to your team to read Chapter 2.
1 If you have a chance, I recommend also reading Dijkstra's 1972 Turing Lecture: "The Humble Programmer".
hey kenny! what do you think of the whole github thing?
ReplyDeleteI know some guys who really like GitHub. It's got a good set of support tools.
DeleteIf there's a knock against Git, it's the same one that applies to all "silver bullet" development tools that promise world peace... you've still got to think through the requirements, the schedule, the dependencies, the testing, etc. That's the bulk of the effort.
If you're doing all that with existing tools, then Git won't be much help. If you're not, then Git might save the effort building some of the infrastructure.
One more thing comes to mind...
DeleteThe hard part of CM (not just source control) is the management current development and multiple versions with a common code base. Stream based CM systems surpass branch/truck systems for managing that complexity. However streams require a different mindset than the SVN approach. The problem gets stickier when you couple with issue trackers and workflow. While you probably want that, someone needs to think really hard about how it's all going to work.