Chapter 4 – The Initial Process
- Without a plan, they had no idea how big the project really was, no basis to know where they stood, and no way to justify the additional resources when they got in trouble
- Reasons things go chaotic
- commitment discipline (Feature creep):
- even simple features need to be planned out before being committed to. afterall, if it is a simple feature, then the planning should be simple as well
- often features which are forced in when the schedule is already as risk will be done in the lowest-risk, brute force method which can cause supportability issues for the code in question down the road
- gurus: As long as they continue to be successful, they will be given progressively larger and more demanding assignments until they hit one that is beyond them. Sounds much like the Peter Principle in action. Might also be why VCs will put their people in management roles (developers; which are invariably the ones who start tech companies, usually make poor managers)
- magic: Belief that magic makes all the details seem so unnecessary that the hard work is deferred while Rome burns or There is no silver bullet. My “favourite” version of this is “We can buy and we can cut from the schedule”. Ooookay….
- problems of scale: eventually, all large projects become too big to fit inside anyone’s head, so knowledge becomes distributed, but often in a very disjointed and organized manner ultimately resulting in a system which various people understand different components but no one has a clear picture of the overall structure. There is no metric in the book, but I would guess that these start to kick in full-force around the 3rd major release of a project or 20 developers; whichever comes first
- implications of scale: It is much like taking a beachhead. If the airstrikes, the naval guns and the landing craft are not precisely in sync, they will likely end up shooting at each other. When a large-scale process veers out of control, seemingly proper nuclear actions can have potentially serious large-scale consequences. Say for instance your project is made of highly segregated modules, each with their own dedicated dev team. If Module A changes an interface without proper communication and discussion, they might as well be taking off the head of the Module B team
- commitment discipline (Feature creep):
- Software Process entropy
- often we do not really understand what we want, or how to build it until we have finished
- Brooks: build a prototype, then throw it out and build what you wanted in the first place
- all changes to software end up increasing it’s size
- management systems focused on the current crisis. not that that actually exists in the real world…
- The way out
- general steps
- apply systemic project management
- adhere to careful change management
- utilize independent software assurance
- Robert Frost: The best way out is through coincidentally, I just finished Mystic Quest in which one of the characters often says this
- basic principles of controlling chaos in a software process
- plan the work
- track and maintain the plan
- divide the work into independent parts not just “client” and “server”, but break “client” down into small, manageable parts. Again, no evidence for this, but maybe into tasks that take no longer than a week (or 5 days really)
- precisely define the requirements for each part
- rigorously control the relationships between the parts
- treat software development as a learning process
- recognize what you do not know
- when the gap between your knowledge and the task is severe, fix it before proceeding
- mangae, audit and review the work to ensure it is done as planned
- commit to your work and work to meet your commitments
- refine the plan as your knowledge of the job improves
- general steps