Who has heard of Code Complete? Have you ever read it? Did you just say to yourself, yes I know the book and I remember reading it back in 2004? Did you date yourself and self-admit to having read it in 1993? Respect.

Ok, so let’s assume you don’t know the book, or let’s assume it has been a while and you loaned your copy to a friend and never got it back (I’m looking at you Tim). It is a really good book, maybe a little dated but it holds up…kinda like Empire Strikes Back is the best Star Wars movie. Why does it matter to me right now? There is a concept Steve McConnell writes about called Software Construction, and it is resonating with me.

Software Construction is a process, sometimes a complicated process that McConnell describes as:

Problem Definition
Requirements Development
Construction Planning
Software Architecture, or High-Level Design
Detailed Design
Coding and Debugging
Unit Testing
Integration Testing
Integration
System Testing
Corrective Maintenance
Not a short list. If you think of the development cycle, you might think some of these sound like developer tasks and others sound like architecture or testing tasks, but I recently bought another copy of the book, and this time I read that list and think, yep these are all developer tasks. Maybe it is the influence of modern development trends where individual developers are empowered and expected to do each of these things because it is “agile” or “lean” or maybe you are just expected to be able to do them all because your team is comprised of senior people who have been there, and done that so expecting coverage is a factor of being experienced. This time, I read this and think, a junior developer should be able to do all these things.

When I take a look at any one of these Software Construction processes, I think yes, a junior developer could do this if…and this got me thinking that the Software Construction is not a macro-level process but it is a process that can be recursively applied to smaller or more fine-grained aspects of an application development effort. McConnell says, “Construction is a large part of software development. Depending on the size of the project, construction typically takes 30 to 80 percent of the total time spent on a project. Anything that takes up that much project time is bound to affect the success of the project.” If the process is this important, it should be understood by all contributors on the team and if it is a good process, then applying it to smaller development tasks should be natural. If this is a natural process that gets good results, then what you have now is a predictable, repeatable framework to get things done and a way to assimilate new developers onto your team, regardless of experience and skill.

I’d like to admit I am not a “process guy” — I am a developer who is results driven, but I will concede that a good process that is natural and leads to good results is one that I can embrace. I do a lot of work on my own, so this Software Construction process is something that feels natural to me, because a single developer wears many hats. You should work in a way that gets the results you want in the time you want, regardless of whether the team is large or small or just one person. I reread this book and saw it with new eyes. I don’t read it and think this is great if you are a legacy, waterfall development team (there are criticisms of the book that sound a lot like this). McConnell says early in the book that he doesn’t expect everyone to agree with some generalizations he makes, and he expects some strong dissent but that is a healthy way to read books like this, do you get something out of it that can help you now? If so, it is a good book, and that is how I feel about it today.

This is just a small slice of good stuff in the book, if you have the time, I definitely recommend it. I will be rereading the The Pragmatic Programmer next.