The Fundamentals of Software Development: The Core Process

Software development is an interesting world in which no formal education, certification, apprenticeship, examination, or even much in the way of financial cost is required to get started and even to be successful. Children, teenagers, and adults of any age can get involved, tinker, build, and solve problems. Over time, “coding” has become easier, requiring less skill, money, and time than it used to. On the other hand, the “interesting” software that businesses are built upon and from which fortunes are typically made, are more complex than they used to be and require a great deal of skill, time, and money.

This “scaling” of software development, from a simple personal project to a billion dollar, multi-year project requiring hundreds (or more) people, presents an interesting opportunity to explore and understand the building blocks and fundamental aspects that are involved. What must be done to build software regardless of the complexity and size? What isn’t required and why? What is the core process followed by every software developer, whether they are an accomplished developer with decades of experience or whether they are a youth who wants to build a website for their school’s science project? Is there a fundamental difference between how a team of highly skilled developers will build an artificial intelligence system to understand a cook’s spoken English and that same cook who will use that system to verbally “program” a smart oven? (“Oven, raise the temperature to 400 degrees and hold that temperature until the food reaches 204 degrees; then reduce the temperature to 250 degrees for two hours and increase humidity by 30 percent.”)

The question of what’s both necessary and sufficient to produce software may seem simplistic or uninteresting. However, when we explore the fundamentals of producing software, we may find insights that can change the way we approach it in the future. Those insights probably won’t help us program a smart oven, but they may help us build that artificial intelligence system. Fundamentals of software development are a foundation upon which individuals and teams can produce software.

The Core Process

The answer to the question of what is both necessary and sufficient to produce software is a question about process. The answer isn’t about using a particular tool or language, but about what steps are taken. The following paragraphs detail this process. Though this process is introduced as if it were fact, I accept that this is ultimately an opinion about the answer I found to the above question.

First, you must have requirements. You need to know what it is that the software must do in order for it to have meaning. Monkeys typing on typewriters don’t produce meaning until you decide what it is that has meaning from all that typing. In other words, the requirements represent an end state of the software that has meaning to someone or something.

Second, there must be some effort to “build” the software. This may be code in some computer language. It may be complex configurations of existing software. It may even be verbal commands by a cook that operates a smart oven in a particular way. In some way, we expend effort to express the needs specified in the requirements to get a computer to do what we want.

Finally, whatever is built must be “published.” For some, that means deploying hundreds of instances of the software onto hundreds of servers running “in the Cloud.” For others, it may be showing what you built to the teacher’s assistant to get a grade on a homework assignment. It might just be running a simple script once in order to configure some server, or it may be the oven cooking your food.

The simplicity of this process can be disappointing. Is that all there is to producing software? Would anyone actually build software this way? Well, hopefully not. This isn’t the end of the story, because what’s not in the process is critical, and what’s not in the process is due to the nature of the question. The question didn’t ask what was both necessary and sufficient to build quality software. And therein lies the insight.

What About Quality

If all that’s necessary to produce software, in terms of the process you must follow, is to require, build, and publish, then for any non-trivial software project, you’re going to get a mess. This is where the quality professionals typically get out their pitchforks and chase me off into the woods. However, this merely showcases the real insight from acknowledging this core process: everything that you add to the core process, theoretically, must be to ensure the quality of the software. Architecting and designing, performing code reviews, testing (in all of its various flavors and types): all of these things are practices to ensure the quality of the software. In fact, anything that is done as part of producing software that doesn’t help to achieve “quality” of the software can be stopped. There’s no use for it.

You don’t get to add practices to improve quality without some form of cost. Whether it’s measured in money, time, complexity, or something else, all quality processes come with a cost. You might argue that for a given practice, it’s worth the cost. That’s fair, and, in fact, that’s the assumption. If it’s not worth the cost, then don’t do it. In fact, plenty of “process improvement” activities can be done by merely analyzing a given practice and its cost to determine if it’s really worth it: does it help you achieve the quality you want? If not, stop doing it.

So, in summary, software is produced by a simple core process: require, build, and publish. You add practices to improve quality as long as they are worth it. If you review every software development methodology that exists today, whether it’s Waterfall, Scrum, Extreme Programming, or one of the many others (and even the custom-developed ones), you’ll find that they all have the core process embedded within them and all of them have added practices that in some way or another are meant to improve the ultimate quality of the software.

What is Quality?

There is a key aspect to this that hasn’t been mentioned, and it’s key to understanding everything stated above. Since we’re talking about a process and the output of that process, the term “quality” has been used loosely. Many books and articles have been written about quality and what it means. For some, it means the absence of bugs in the software. For others, it represents how well the software is accepted by those using it. I’ve always liked the statement: “does it do what it’s supposed to do and does it not do what it’s not supposed to do?” It’s typically associated solely with the end product. However, in terms of the core process, quality actually refers to not only the attributes of the software created but also to the process involved in that creation.

Quality represents the values of those involved in the creation of the software (including any stakeholders). For example, an aspect of quality could refer to the speed at which the software was produced. It could represent the enjoyment of its developers, or the lack of defects, or the usability, or the overall financial costs, or whatever else those involved value.

For example, a business may produce a piece of software that has thousands of defects, and that software might be highly successful in terms of financial gain for the company that built it. Another organization may produce a piece of software in which a single defect causes a catastrophic failure. Software built too slow may miss a marketing window, causing the company to go out of business with thousands of employees losing their jobs. Software that costs too much to build may never get built because no one wants to pay for it.

Conclusion

The reason the relationship between the core process, quality, and cost is so important is because it enables organizations, companies, teams, and individuals to make purposeful decisions about how they go about producing software. If they think purposely about what quality means and the associated costs, they can choose an appropriate methodology (or develop their own), improve it as they need to, and ultimately build software successfully. For individual developers, these insights can help us look at producing software differently. It becomes a powerful tool to improve the processes we already follow because we can be more purposeful about how we think about what we do.