“This is what we do. We code complete.”
In the United States, the mid-1980s television series Miami Vice was something of a phenomenon. Its “MTV” style and colorful characters captivated many viewers and made it a favorite. The series was broadcast in over 100 countries and watched by an estimated one billion people worldwide.
One aspect of Miami Vice that contributed to its success was its music. The show’s soundtracks featured several songs that became international hits, including the No. 1 single, “You Belong to the City,” by Glenn Frey of The Eagles.
The show’s theme song is “In the Air Tonight” by Phil Collins. You may remember a distinctive element: drummers playing along with a synthesized drum track, for an unusual effect. It worked well for the song, but when Phil Collins tried it during concert performances, it didn’t work so well—or at least it didn’t work as well as he wanted it to. He pondered ways to improve his live performances and eventually decided to use some visual cues in addition to audio cues to help synchronize his drummer with the synthesized drum track. At his concerts he now uses video monitors suspended behind his drummers so they can see both their hands and feet on
A general guideline is to code complete a class before moving on to another class. Code completion is more than just coding, however.
It also involves writing unit tests and documentation, as well as performing a few other tasks. The goal is to get the module in a state where you can forget about it for a while and not have to think about it when you start working on a different module.
As you work through the design, implementation, testing, and documentation of a routine or class, your understanding of it grows. If you stop before the module is finished, this understanding may be lost over time when you pick up the module again.
By contrast, if you code complete the module, you will have all that information fresh in your mind and won’t need to spend time relearning the details of the module’s internals. You’ll have unit tests that will catch any inadvertent changes that may have been introduced as a side effect of modifying other classes and routines as well as any modifications that may be necessary for future changes to the code base. You’ll also have documentation so that you or others can understand how to use the module later on.
The idea of a code-complete milestone is to mark the end of initial development and the beginning of bug fixing and test work. Code-complete can mean different things on different projects.
In some cases, code-complete means that all functionality has been implemented. In other situations, it means that all functionality except for one or two features has been implemented. In still others, it means that everything has been implemented except for the user interface.
Whatever code-complete means on your project, you should use the milestone as a time to step back and get a handle on where you are in terms of quality, progress, and planning. To help you do this, I’ve listed 10 questions that you can ask yourself at the code-complete milestone. Asking these questions will help you achieve a high level of quality in your software and also help you plan how much time you’ll need for testing and maintenance.
Complete is a relative term. In practice, projects rarely reach the state in which they are completely done. It’s more likely that they reach the point at which they’re good enough to ship. The project manager and customers have to decide when that point has been reached.
Subjective factors like these make any attempt to get code completely right seem ridiculous to some people. It also makes it easy for them to dismiss any attempt at improving code quality as a waste of time. But what’s really silly is trying to improve software quality by throwing hardware at the problem, as if you could write code as sloppy as you want and then run it fast enough on enough machines that no one would notice.
Incomplete software always has bugs in it, even if they haven’t appeared yet. Even when we don’t know what a program’s bugs are, we can be sure there are some lurking there ready to creep out at the worst possible moment if the program ever becomes popular. And if we do know what a program’s bugs are, we know that other ones are still hiding in its depths waiting to be discovered by an unsuspecting user at some time in the future
The software developer’s life manual
You can’t write a good program without knowing something about the problem you’re trying to solve. You’ll never be able to write a great program that way, either.
Most programmers don’t think of their work as involving significant design issues. They think of themselves as coders, not designers. This is unfortunate because, in software development, coding is really the easy part. The hard part is figuring out what to code.
“The hardest single part of building a software system is deciding precisely what to build.”
–Fred Brooks, The Mythical Man-Month
Unfortunately, many developers focus on the coding part rather than the design part. They don’t want to spend much time thinking about what to do before they jump into writing code. They want to just start coding and see where it leads them. That’s how you get code that’s hard to read and maintain, and that has lots of errors in it.