Code Complete - Ch.1

So, what is software construction? I've been learning to code for a couple of years, and before I opened this book I had not come across these two words put together. Software development, software design, software engineering, software architecture, programming, and coding—these are all terms used ubiquitously and sometimes interchangeably, for better or for worse. Construction is of course just another word for building, and that's just what is meant in this context. Software construction is the actual nuts and bolts (and mortar and beams and roof and windows) of creating a computer program. Coming from the actual architecture industry (it really bothers me that the term "software architect" now seems more commonplace than that of the traditional variety), this metaphor is plain enough and quite sensible. Following along in that vein, construction also implies planning out the project, designing what it will be, and checking the work after everything is built.

Altogether, we have the software construction portion of the software development lifecycle. There are plenty of other activities that fall outside of the scope of construction: UI design, for example, or determining what the goals and needs of the project are ("problem definition" and "requirements development", respectively). And yes, even software architecture falls outside of this scope, so from now on when I write the word "architect" you know I mean the real kind. Many self-taught programmers—and I think that covers most computational designers I know—might never make much of a distinction between development and construction; for them, the writing of the code and getting it to work is the entirety of developing an informal project. When I start a new Grasshopper script, I might spend a moment or two defining the problem and what the required outputs are, and I might even spent another minute thinking about what plugins to use and how to go about it (i.e. the script's "architecture"), but after that I'm just diving in and hammering away. Forget testing—once it works, it works until it doesn't, which is usually the next time someone opens my esoteric script and tweaks just one tiny condition.

From our list at the top of the page, we can focus on the last two terms: programming and coding. These two are confused often, but they are not the same. Coding is a more limited activity. It implies the translation of an idea or concept into a language that is readable by a computer. Coding is an important part of the process, but it doesn't encompass the creativity and judgement that programmers employ when building software (or constructing it, rather). In Code Complete, McConnell states that he uses "programming" and "construction" interchangeably. These terms together describe a collection of activities that form the core and bulk of the whole development path: detailed design to address the problem and requirements, construction planning to address the decided-upon architecture, coding and debugging to write and document the various parts of the program, unit testing to test and check the parts individually, integration to fit the parts together, and integration testing to test and check the fitting of the parts.

So why is this important? Well, simply put, programming is important because of the amount of time it takes up (a lot), the result of that labor (the source code for the program), and the relative importance of that result to the whole software product (very important). That importance also marks construction as the only part of the whole development process that is actually 100% necessary. As we saw in the earlier example of my crappy Grasshopper script, you can launch into programming without much planning or consideration and still get something out of it. As long as we're recklessly diving headfirst into these sort of computational problems, we might as well try to be half-decent at swimming.

That's the conceit of Code Complete; to be a good programmer you need to holistically understand software construction. It's not enough to have a really great idea or to be completely fluent in this or that programming language. Architects love to describe themselves as generalists, diligently coordinating dozens of areas of expertise into one set of documents that describes an entire building. I'll try not to stretch this metaphor too much—at least not too far past the next chapter, which is actually called "Metaphors for a Richer Understanding of Software Development"—but I do think it's worth pointing to the nuance and creativity inherent in technical vocations as well as the technical rigor required to truly excel in the more "creative" pursuits. Architects embody this dichotomy, working between art and engineering. One of the most exciting and satisfying discoveries I've made of the past few years is that the motivations that drew me, a "creative" person, to architecture are completely applicable in designing and crafting computer programs. The crossover potential is what makes computational design such an interesting and optimistic field right now, though I think we could all use a little more technical rigor in order to excel. I know I could, which is why I've embarked on this project.

So, what is software construction? A good bit of designing and planning, a huge amount of problem solving and documenting, some time spent fitting the pieces together, and checking the work to make sure nothing will go wrong in the future. If you, dear reader, are an architect or designer of any sort, you should immediately recognize this conceptual framework as something quite familiar. I hope you'll think differently about the software you use on a daily basis and stick with me to unpack this metaphor a little further.

If you're new to this series, you can read more about my motivations for this project in the introductory post:

Code Complete - Introductions

Why I’m doing this, what I hope to get out of it, and how you might benefit from following along.

CLSMColin L.S. Matthews