| Steve McConnell Microsoft Press 1996 |
Summary
This is a huge book covering every aspect of how to develop software faster. The main point is that you don't develop faster by cutting corners - you only turn your code into a muddle that will probably be so buggy it may not even ship without a rewrite. Given this, what is the alternative to slow, methodical development? It turns out there are actually a lot of alternatives. Generally McConnell suggests developing quickly, but argues that it is possible to develop too quickly. Whilst speed of development may sometimes be the overriding criteria it is generally not worth the trade-offs involved in optimising totally for speed of release.
What McConnell suggests therefore are a number of strategies for improving the speed of development whilst maintaining a reasonable balance with the other activities of keeping code maintainable, of good quality, well designed and structured. The first two thirds of the book present detailed discussions on various aspects of software development and management, from estimating to teamwork to managing risk to various lifecycle models. The last third of the book goes through McConnell's "best practises" in rapid development.
Fundamentals
Rapid Development isn't always the only goal - you also need to consider optimising a project for schedule speed, schedule risk or schedule visibility - you need to decide what you want. There is a story (not in the book, but seems a good example) of a lift company, who made a lift for a high-rise block of flats. Everyone complained that the lift was not fast enough, but no matter what the company did it seems they could not make the lift travel fast enough for the tenants. Then someone suggested a simple solution which solved the problem. They put mirrors where people waited for the lift. While waiting people would either look at themselves or glance sideways at other people and no longer noticed how long the lift took to arrive. In the same way if a project increases its visibility this sometimes reduces the pressure to deliver. Because people can see what is happening in the project and the progress that is being made, they are not left "doing nothing" while waiting for it to arrive.
The four pillars of rapid development are:
- Avoid classic mistakes
- Development Fundamentals
- Risk Management
- Schedule-Oriented Practises
The four-dimensions of development are:
- People
- Process
- Product
- Technology
Instead of going for all-out rapid development, go for efficient development, fast, but not fast at all costs.
Here are the classic mistakes by category:
People
- Low motivation
- Weak personnel
- Uncontrolled problem employees
- Heroics ("can do" doesn't usually come through)
- Adding people to a late project
- Noisy crowded offices
- Friction between developers and customers
- Unrealistic expectations
- Lack of effective project sponsorship
- Lack of stakeholder buy-in
- Lack of user input
- Politics placed over substance
- Wishful thinking
Process
- Over-optimistic schedules
- Insufficient risk management
- Contractor failure
- Insufficient Planning
- Abandonment of planning under pressure
- Wasted time during the fuzzy front-end
- Shortchange upstream activities (e.g. didn't have time to do design)
- Inadequate design
- Shortchange quality assurance
- Insufficient management controls
- Premature convergence (push to get the product ready to go out)
- Omitting necessary tasks from the schedule
- Plan to catch up later
- Code-like-hell programming
Product
- Requirements gold-plating - insisting on a lot of complex features
- Feature creep
- Developer gold-plating (technically interesting features)
- Push-me, pull-me negotiating - allow a slip then add tasks
- Research-oriented development
Technology
- Silver-bullet syndrome
- Overestimated savings from new tools and methods
- Switching tools in the middle of a project
- Lack of automated source control
Risk control. List the risks, assess the most important and prioritise on these.
Schedule
Where the time goes, this is where time should be spent:
| | Small Project (<25,000 lines) | Large Project (500,000)
|
| Architecture/Design | 10% | 30% |
| Detailed Design | 20% | 20% |
| Code/Debug | 25% | 10% |
| Unit Test | 20% | 5% |
| Integration | 15% | 20% |
| System Test | 10% | 15% |
Lifecycle
The Pure Waterfall lifecycle has the following architecture:
- Concept
- Analysis
- Design
- Detailed Design
- Code and debug
- System Testing
Alternatives:
- Spiral - have a small deliverable, and keep adding to it
- Waterfall with subprojects
- Build the "essence" of the system, have this approved, then add the detail
Estimating
Keep two estimates, the optimistic and pessimistic and keep bringing the two together. So at the beginning of a project you may say the project will take between 10-30 weeks. This is because there just isn't enough information for a more accurate estimate. As more time is spent on the project, the two estimates will converge. Resist the pressure to state a single figure.
Tips:
- Allow time to estimate
- Use data from previous projects
- Get developer-based estimates
- Have a walk-through to compare estimates
- Estimate at a low level of detail
- Don't forget tasks
- Use software estimation tools
- Use several techniques and compare results
- Keep re-estimating as the project progresses
Prepare case-based estimates:
- Best case
- Planned case
- Current case
- Worst case
Use coarse time periods and dates. Page 194 and 196 contains tables to assist in estimating, there are two tables, one for nominal schedules and the other for efficient schedules. There are columns for shrink-wrapped, business products and systems products and for each area a schedule in months and in effort (work-months) for projects starting from 10,000 lines of code up to 500,000 lines of code. The shortest length of time is for 10,000 lines of code to be developed for a business product in an efficient schedule (4.9 schedule months and 5 work-months). For a nominal schedule the same task takes 6 schedule months and 9 work-months.
If you miss a week at the start of the project, don't assume it can be made up later, but also don't just add it on the end. Instead calculate the factor your original estimate was out, and apply that to the whole project.
Research has shown developer estimates to be 20-30% optimistic.
You can't compress a schedule more than 17% by increasing resource.
Check the rate of work of a developer - how many work-hours per day is assumed? Is this valid?
General Points
- Customer-oriented development - keep a customer on the project team, keep a customer aware of project development.
- Developers need to be motivated - this is achievement, goal-setting, feedback, growth and not de-motivated, unrealistic schedules, lack of appreciation for effort, low quality etc.
- Teams can be a major contributer to productivity. They need to get on well, respect each other, trust each other,enjoy what they do. There are various team structures which vary for different projects - research, bug-fixing, upgrades, new products etc. For example some teams need to have good problem solving skills for designing a new product, others need to be careful and thorough for a bug-fix release.
- Consider creating a minimal specification for a product, this could be one of the following:
- short paper spec of about ten pages or less on what will be built;
- point-of-departure spec, a one-shot agreement on what will be built, it is not kept up to date;
- write a user manual instead of a spec
- user-interface protypes
- paper storyboards
- vision statement - should include what won't be developed as well as what will be
- product theme - guidelines for what should be included
- Note the "article of understanding" on p.325, which basically says software can never be totally specified and so can't be wholly estimated; where we come to a re-specification of some detail, this may require a re-estimation of effort.
- Advantages of minimum specification is the general impossibility of detailing everything and the huge effort involved in maintaining a detailed specification. The disadvantages are missing important aspects of the product, not controlling what will be developed and using it as an excuse not to plan ('code like hell' approach). If using a minimal specification at least get the UI checked and agreed.
- "Scrubbing" features is one of the most powerful ways to shorten development. Even if a feature doesn't take long to code it will have to be documented and tested. However scrubbing during development won't save as much time as scrubbing at the beginning, because some implementation may already have been done.
- McConnell insists that all details of an application cannot be specified in advance - he gives a simple example of a charting program - what control should the user have in changing the program? McConnell lists ten alternatives, which are by no means all of them, which vary in development time from zero to weeks of development. If a project has guidelines or "themes" then these will help developers make sensible decisions on what to do in these circumstances.
- "Gold-plating" is the term for over-development, spending weeks implementing a fantatic array of options when only the basic functionality was required, which would have taken a few days.
- Change Control. All projects will experience change in requirements and the answer isn't just to say no. However any change not only needs to be estimated, but users need to understand that even spending time estimating will add to the schedule. "It will take a day to estimate this, will you accept a day's delay to the project to provide this estimate?" The skill is to give the impact of the change and see if this is acceptable, or whether a smaller change which requires less work will still be acceptable. Changes need to be negotiated in the sense of understanding what is required and identifying the best, most efficient way to implement it.
- If a project is running late - perhaps because new additional features have been added - the end date can be broughtin by cutting low-priority features. To allow for this, always develop these features last, to allow them to be cut.
- Productivity tools are not a silver bullet. A study by Fred Brooks in 1987 found that no single technology will increase productivity 10-fold in the way the move from assembler language improved productivity. In fact no tool will improve productivity by 25% per year for 10 years. In 1995 he re-affirmed his position. McConnell agrees - we can only find tools that will improve productivity at best by 15-25% for several years using a combination of tools, that appears to be the upper limit.
- Any productivity tools need to be fully assessed before being used. Studies have shown organisations can waste 50% of money spent on tools and 30% of tools have limitations that make them unsuitable for the purpose they were bought for. 10% of tools are never used after aquisition. The biggest risk is there will be a limitation of the tool that won't become apparent until development is underway. This is why a careful intelligence gathering and evaluation period is necessary.
- Productivity tools don't typically product benefits immediately because of the learning curve. Thus they are unsuitable to use as a way of meeting a tight deadline.
- Even a coding time reduction of 75% with a productivity tool won't reduce the project by 75%, as other items such as testing and documentation still take time, and not all development may be suitable using the tool. In McConnell's example the eventual savings in project time was a mere 8%, because the 75% coding time reduction didn't apply to all the code.
©John Mann, 2000