Laying the Foundation

For a programming textbook, Code Complete begins by decidedly not diving into programming practice; in the first four chapters we didn't inspect or discuss a single line of code. I think spending this much time discussing all the work that goes into an idea before putting pen to paper contains a valuable lesson: foundations are important, as much in the metaphorical sense as in the physical one.

In Ch.1 we learned about the idea of software construction: what it is and what it is not. We differentiated between the ideas of coding and programming, with emphasis on the necessity of programmers to have a holistic understanding of software development in order to do good work. This allows for creativity and judgement to be incorporated into what would otherwise be rote technical work.

In Ch.2 we addressed the power of metaphor, or broadly-understandable conceptual models that help explain esoteric complexity. With the acknowledgement that conceptualizing the right problem is sometimes more difficult that actually solving it, we explored the use of heuristics as suggestive path-finding tools that allow us to formulate robust solutions. With a nod to the idea of software construction, the metaphor of "building" was presented as an extensible and useful model for what programmers do, but we also acknowledged that metaphors can go too far and lead us astray. Sometimes an air conditioner is just an air conditioner.

Ch.3 addressed the actual foundation activities in software development, or the upstream prerequisites of a project. These activities are all about planning and risk reduction so that when it comes time to dive in there will be minimal reworking, which we know to be expensive and inefficient. This chapter also emphasized how crucial it is for people doing technical jobs to be able to explain what they're doing and why it's meaningful. Employers might not understand why the programmer they hired is not producing copious amounts of code right off the bat; it's essential to get buy-in for an adequate amount of planning and preparation. The three upstream prerequisite activities are:

1. Problem definition: a vision statement for the project; a problem presented from the user's perspective, without any attempt at solution.
2. Requirements: explicit goals and benchmarks to ensure that the user's needs are met and to limit the scope of work.
3. Software architecture: a technical framework for the construction process that addresses high-level design considerations.

Finally in Ch.4 we covered the final bit of foundation-laying by investigating different programming languages through the lens of linguistic relativity. The Sapir-Whorf hypothesis suggests that our understanding of language actually directs our thought processes, with big implications for the choice of programming language in any given project. Once a language is chosen we must then define conventions for using it, similar to how architects devise drawing conventions so that big-picture ideas can flow seamlessly into the smallest details (and vice-versa). In devising conventions we should keep in mind the importance of programming into rather than in a language as well as our place on the technology wave.

As we have yet to dive into esoteric discussions of class structure, data types, pseudo-code, or variable naming, it's been relatively straightforward (and helpful, even) to draw comparisons between laying a foundation for programming versus laying a foundation for other pursuits—namely, architectural design. It might be difficult to relate these two practices through future chapters (we'll see just how extensible the "building" metaphor truly is). I hope that my writing will continue to be of use to designers and programmers alike, even as we get further into the weeds. Computational design is a wonderful marriage of creative experimentation with technical rigor; it's one of the most dynamic and optimistic parts of the AEC industry and can only grow in importance for architectural design. I started this blog to document my own learning process, but as I'm reflecting on Part I of my Code Complete project, I realize that my ultimate aim is to educate and help others get excited about making their creativity more impactful. Next week we'll embark on a five-week reading through Part II: Creating High-Quality Code.

bool timeForCoding = true;
if (timeForCoding)
{
    Console.WriteLine("finally!");
}
else
{
    Console.WriteLine("sorry bud, come back next week);
}