Software development sits on the threshold between science and practical knowledge. On one hand, software has to be encoded in a rigorous formal language to ensure it can function properly when instanced in a machine, such as a computer. On the other hand, deciding how to best represent a problem so that it can be solved through calculation requires imagination, technical know-how and plenty of trial and error, in other words practice. Because it is simultaneously formal and practical, software development can be made easier, more efficient, and less error-prone through the use of a number of principles derived from experience. In the process of developing software, certain ways of going about solving problems come to be recognized as being in some way superior, and thus get adopted as guide-lines for future development.
These guidelines or principles can vary in scope from small-scale one, like how to best display an image on a web-page, to broader recommendations on how to structure code in general. In the following article, we will give a small overview of the latter in order to give laymen an idea of how software engineers think, as well as to give fledgling developers some general advice to keep in the back of their head while writing code.
Don’t Repeat Yourself (DRY)
One of the reasons we develop software is to automate a repetitive activity, for example solving a series of algebraic equations. On the level of code, this automation is accomplished by abstracting away the particular values of an equation, and writing out its general form so it can be reused when needed. However, the same kind of repetitiveness we were trying to reduce can also occur while we are writing code. The tendency to copy-paste code is an especially egregious example of this. The problem with repetitive code is that it duplicates the problem it is trying to solve. Additionally, repetitive code is more prone to bugs, more difficult to maintain, and harder to parse.
To remind developers not to be mindful of repetition while writing code, a principle called DRY or “Don’t repeat yourself” was coined. It states that every recurring piece of information within a piece of code should have a single, authoritative representation within the system. So instead of writing the same lines of code multiple times, we should instead reference a more general model or form of which they are an example.
Keep It Simple, Stupid! (KISS)
As we have mentioned in the opening paragraph, the practical side of writing software comes from the fact that there are multiple ways of solving a particular problem. Some of these solutions produce the exact same results, but the methods they employ can vary greatly in terms of complexity and speed. The trouble is, sometimes a complex solution might seem more intuitive than a simpler one, which results in a piece of software that wastes resources doing unnecessary computations.
The KISS principle, which is shorthand for “Keep it simple, stupid!”, exists to remind developers to always look for the simplest possible solution to a given problem. Developers are people like everyone else, so they tend to write code that makes most sense to them, but this doesn’t necessarily lead to simple solutions. Simplicity in software development is essential, and the KISS principle is good way to remind yourself of the fact.
You Aren’t Gonna Need It (YAGNI)
The practical reasons for why people develop software is to solve a particular problem. However, it is often the case that during development, a particularly enterprising programmer will create a piece of code that can do more than what was originally demanded. These extra features are a testament to both the ingenuity of the developer, as well as to the power of computer-based problem solving. Unfortunately, since software is usually developed for a specific purpose, these additional functionalities can become a hindrance. They require additional time and effort to implement, and they probably won’t end up being used.
Keeping developers on the right track during software development is important when what they are creating is a commercial product that has to meet multiple deadlines, and thus the YAGNI principle came to be. It stands for “You aren’t gonna need it”, and it refers to the fact that while additional features can be useful, they are not needed in order to deliver the final product.
Release Early, Release Often (RERO)
On a broader level, software development is often organized according to something that’s called the “waterfall method”. This simply means that the process of development proceeds in one direction through a succession of phases, including conception, initiation, analysis, design, construction, testing, deployment and maintenance. Once a particular phase is complete, the developer won’t realistically be returning to it. This can create problems if there is a mistake that is inherited from an earlier phase, resulting in a faulty product down the line.
To avoid this problem, some developers started focusing on creating multiple prototypes of code at each stage for additional testing. The phrase “Release early, release often” or RERO refers to this approach. By testing code at multiple junctions during development, spotting and correcting becomes easier, resulting in a better optimized final product.
Conclusion
The principles which we have outlined above are just the tip of the iceberg when it comes to software development. Many more exist and simply don’t a name, but their usefulness for creating quality code should not be underestimated.
