What exactly are the principles of software development?

Software developers and engineers created or adapted several acronyms and idioms to help them stay focused. Some of these acronyms come from the fields of philosophy or science. Others engineers and project managers coined themselves to guide the software development process. Let’s take a close look at these principles, starting with the principles that developers adapted from other fields.

First off, let’s examine measure twice, cut once.

Measure twice, cut once

This principle originated sometime in the middle ages. Back then, the expression was, “mark seven times and cut once.” This is the version still used in Russia today. Regardless of how many times we measure, the principle remains the same: proper planning methods will yield the best results.  The literal meaning comes to us obviously.  If we have a piece of wood that needs cutting, it’s better to double-check our measurements so we don’t waste wood making mistakes. When applied to the world of software development, we use the term a little more broadly. When we measure twice and cut once in software development, we plan comprehensively, putting together the right team and mapping out our steps in detail. Developing within agile methodology we plan our sprints and prepare for testing.

Occam’s razor

Occam’s razor comes to us from an early medieval English Franciscan friar, William of Occam. The principle that William of Occam espoused was "entities should not be multiplied without necessity.” But what’s with the word “razor?” In philosophy, a razor allows us to eliminate unlikely answers to a problem.  Occam’s razor states that the simplest solution is usually the best solution. We should not try and apply complex answers when a straightforward answer will work as well or better. In software development, we use the principle of Occam’s razor to question adding complexity to a software solution. We can make code function as required by keeping it simple and easy to understand. Straightforward, clear code works better and proves easier to test.

KISS (keep it simple stupid)

This principle was coined in the US Navy in the 1960’s by Kelly Johnson. Johnson coined the acronym to describe how designers of aircraft should work. They should make their designs simple enough that an average mechanic with limited tools could repair the aircraft. KISS directs us to avoid unnecessary complexity, to design with simplicity as a goal. In software development we use the KISS principle to remind us to make our code easy for others to understand and navigate. Testing and debugging simple code will always be better than combing through byzantine structures to find errors. We must create code that shows simplicity and elegance, not code that shows off how dense and knotty our developers can write.

Now let’s take a look at principles created in the software development world

LOD (law of Demeter)

The law of Demeter guides developers to divide classes into independent entities. These entities should not connect with other entities unless they are closely related. The idea is that each class in code should communicate with related classes, but not with those they are not related to. In the original law, this meant “talk to your friends, don’t talk to strangers.” The law was first proposed by Ian Holland in 1987 while he was working at the Demeter Project. Demeter allows developers to keep systems organized and limits the possibility of bugs.

DRY (Don’t repeat yourself)

Andrew Hunt and Dave Thomas stated this principle in 1999 in their book The Pragmatic Programmer. "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." At its core, DRY discourages engineers from repeating code in more than one place. This sort of repetition causes trouble when troubleshooting. 

A good example of DRY on a meta-level is HTML 5’s separation of HTML from CSS. Before HTML 5 CSS code would be embedded in the HTML itself, so every time a heading tag’s style would change, designers would have to comb through all the HTML to make changes. Often they would miss a tag or two, leading to messy designs and incoherent page layouts. When all the styling elements went into the CSS, designers had just one place to look to make the changes.

Avoid premature optimization

Donald Knuth played out this principle as a serious issue for programmers in the 1960’s. He wrote, “The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.”  Developers need to make sure their code functions and proves useful before the team optimizes it. Otherwise, they will waste valuable time and resources on code that might not meet requirements.

YAGNI (You aren’t going to need it)

This principle guides developers to create the code that the team needs at the moment. They should not anticipate extra functions or try to code with a very broad agenda. Instead, the developers should create exactly what the software needs, extending functionality later as necessary.

Big Design Up Front (BDUF)

BDUF asks developers to plan thoroughly before coding. Typical for waterfall method software development, in agile we can also use the principle of BDUF. We can make sure we completely understand the requirements and the needs of the end-users before we begin coding.

SOLID

Solid stands for: 

S  -   SRP (Single responsibility principle)

O -   OCP (Open closed principle)

L  -   LSP (Liskov substitution principle)

I   -   ISP (Interface segregation principle)

D -   DIP (Dependency inversion principle)

Let’s take a brief look at each element of SOLID:

SRP (Single responsibility principle)

SRP calls on developers to ensure that each element of code does one and only one thing. 

Our code should not act as a multi-tool, but rather as specialized tools meant for specific jobs. We should not use a hammer to change a pipe.

OCP (Open Closed principle)

OCP asks developers to finish sprints with the mindset that the code is open to expansion or extension but closed to modification. We do not want to re-invent the wheel with every iteration.

LSP (Liskov substitution principle)

The LSP principle states that code elements in a subclass should behave in the same manner as the elements in the superclass above them. Barbara Liskov described the principle in 1987.

ISP (Interface segregation principle)

ISP leads developers to code interfaces small enough that end users can focus on what they need, leaving out functionality that they don’t.

D -   DIP (Dependency inversion principle)

DIP encourages developers to focus on the interface level, not the implementation. Agile encourages DIP by asking for user stories. If we keep our eyes on what end-users and stakeholders require, we design simple, elegant solutions.

Here at Blocshop, we follow these software development principles to make solutions that work for our customers. If you’d like to see our implementation of these principles in action, please get in touch!