Blog Articles
Code Complete Book Review (6 of 7)
In reviewing these sections of Code Complete
by Steve McConnell there was a lot of discussion about tools. Of course, using the right tool will make programmers more productive. I steered away from these discussions because it seems to me that the tool vendors are doing a great job getting their point across. I'll focus on ideas that we can internalize to improve our software.
- System Considerations
- Program Size
- As programs increase in size and add more programmers, testers, business analysts, communications channels rapidly jump up (n * (n-1)) / 2 where n is the number of team members. This is why status reports, and chains of management make for better communication and coordination on larger teams rather than everyone trying to talk to everyone.
- As programs increase in size, defect density goes up, while programmer productivity goes down. This seems to be an endorsement of SOA, where each project focuses on providing a specific service, then composite applications mashup the existing services.
- Managing Construction
- Encourage good coding with practices such as pair programming and formal reviews.
- As programs grow, the need for formal configuration management grows as well. Use a Change Control Board to discuss and rank requested changes to ensure that you are working on the most important requests. XP uses cards for this and every iteration, the custom picks the most important cards, "stories", for implementation.
- Be sure to use version control software, and have backups to quickly recover from construction missteps.
- Configuration Management Checklist
- You can estimate the size of a project and the effort required to complete it in any of several ways. It is important to first identify why you are estimating. Is this a rough order of magnitude estimation for a go-no go decision? Is this for a detailed customer quote? In my experience, the most effective approach is to use at least two estimating techniques. (I prefer a top-down estimation based on similar projects, and a bottom-up estimation from the software design). If these estimations are close, then you can have additional confidence. If not, maybe you need to choose a third approach.
- Integration
- If you construct and integrate software in the wrong order, it's harder to code, harder to test, and harder to debug. If none of it will work until all of it works, it can seem as though it will never be finished. It too can collapse under its own weight during construction—the bug count might seem insurmountable, progress might be invisible, or the complexity might be overwhelming—even though the finished product would have worked.
- Incremental integration (developing one part of a system at a time, and then adding it to the rest), makes work much easier than a grand "integration phase".
- The basic strategies for integration are top-down and bottom-up integration. Top-down integration lets you test the architecture earlier, but leaves testing the system interfaces for last. Bottom-up integration tests tricky system interfaces first, then architecture and design last. Since both of these approaches have benefits and drawbacks, many teams use a hybrid version.
- Integration Checklist
This material is copied and/or adapted from the Code Complete 2 Website at cc2e.com. This material is Copyright © 1993-2007 Steven C. McConnell. Permission is hereby given to copy, adapt, and distribute this material as long as this notice is included on all such materials and the materials are not sold, licensed, or otherwise distributed for commercial gain.
Article Tags
|
