The golden rule of software engineering
TL:DR
The golden rule: No matter what the question is, the answer can almost always start with “It depends…”
Software is not as precise as you might consider it to be. We write software for other people, not for computers. Writing software for different people leads to different answers to the same questions. We need to take a step back and consider the context that a question is being asked in before making up our mind and choosing a solution.
The golden rule of software engineering
Already mentioned in the TL:DR, but it needs repeating: No matter what the question is, the answer can almost always start with “It depends…”
- How should this feature be implemented? It depends…
- How should this functionality be tested? It depends…
- What language / framework should be used for this piece of code? It depends…
- What architecture would work best for this app? It depends…
- How quickly will this piece of code run? It depends…
It’s gloriously imprecise
This may cause some people some discomfort if your viewpoint is one of software being a very precise field.
The golden rule basically states that nothing is certain. Every question has options, pros / cons, different outcomes that should be considered.
This can be odd, as computers, notoriously, do exactly what you tell them to do.
So how come the answer to any question in software is so fuzzy?
Software is a lot more about people than it is about computers
We write software for other people, rather than for computers.
If writing for computers was the only concern, we could have stayed with assembly.
We didn’t.
We wanted to be more productive as individual writers, writing for our future selves. We wanted to make working together on the same code base easier. We developed all kinds of different ways of communicating ideas and patterns to one another.
When we write code, the primary reader is another human being.
The reader might be the original author of that piece of code, 2 years later, at 11pm on a rainy Tuesday, a cup of coffee slowly going from tepid to cold, as they curse the author under their breath for having written something so impenetrable.
The reader could be the enthusiastic, impressionable, new engineer. Fresh to the big glass and steel office, eating the free chocolate biscuits, no idea of what is or isn’t best practice, just trying to get something that finally works.
The reader could be an experienced senior, sat in a very comfy chair, noise cancelling headphones on, looking through the original author’s code, picking out methods and patterns that we intentionally left for extension, like a trail of breadcrumbs, a gift to a fellow human from the past.
Code is run on computers, but often once it has been compiled down into something that the computer can actually read. Most of the time, the code we are writing is meant to be read by other humans.
It is because software is written for people that the answer to any question can start with “It depends…”. People are diverse and as a result, software is diverse. There are a lots of different ways of doing things, some better or worse depending on the situation
Context is everything
The context in which software is written makes a huge difference to how that software should be written. The same app could be written in all kinds of different ways depending on the context.
Context is the other people who are going to be reading the code we write.
Is it a one person project? A tech-focussed startup? A corporate behemoth?Each of these situations will answer the same question in different ways.
A one person project will probably less concerned with rigorous coding standards and documentation, it’s being written by one person, they have all the context.
A tech-focused startup is probably going to focus on technologies that allow them to iterate and experiment as fast as possible, it doesn’t matter so much if it isn’t the most scalable code, if they can’t iterate they will die long before the need to scale becomes a problem.
The corporate behemoth has had a lot of decisions on technologies already made for them and now it is a case of keeping everything moving. Introducing the new shiny framework doesn’t work because it requires training an entire company.
The difficulty here is that the context shifts, the decisions made in the context of a one person project become problems in a startup. The corners that got cut as a startup never get glued back on to the corporate behemoth.
The answer to some question in the context of a one person project will probably be different to the answer to the same question in the context of a corporate behemoth.
It all depends.
Make up your own mind
In some ways, it would be great if there were a definite set of answers for all software questions. It would remove a lot of the decision making required, which would probably cut down on the number of misunderstandings. If everyone is writing the same things in the exact same way, it’s easier to predict what it will look like.
In other ways, it would make life a lot more difficult, not every problem is the same, the solution that worked in one place might not work in another. If we were in some completely homogeneous world, a lot of the power of tailoring the specific tool to the specific situation would be lost.
We can’t just leave the answer to a question as “It depends” and walk off feeling all smug. We need to follow that statement up with a balanced view that outlines the possibilities. Then make some sort of decision as to which possibility is most appropriate to our context.
There can be answers that are correct the majority of the time, choosing that answer should not be a default, but it probably will be the one that we arrive at after some consideration.
Take the example of choosing a framework for a project. It can be easy to follow the crowd, join the group-think, go with whatever is perceived to be the most popular framework for your type of project.
Let’s say, choosing something like using React for a frontend project.
I’m not saying you shouldn’t choose React for a frontend project. What I am saying is that you should only choose React if you have considered a balanced view of the possibilities and you have landed at React. The types of things to consider here might include:
- Do I know React?
- Do I have time to learn React?
- Are there other people on this project?
- Do they know or want to learn React?
- What are the timeframes for this project?
- Is React an appropriate solution to problem this frontend project is trying to solve?
- What are the alternatives?
- What do I prefer?
The answer to the question “What framework should I use for my frontend project?” can, and should, start with “It depends…”. It should not start and end with “React” because it is perceived as the default thing to write frontend projects in.
I should point out, I enjoy writing React, I think it is a useful tool, but it should be used where it is appropriate.
The method of weighing up the options, considering the context and making up your mind does not just apply to choosing frameworks, it applies to almost everything in software. Questions like:
- Should we write microservices?
- What framework should we use?
- What language should we use?
- How do we represent this concept in code?
- What coding standards should we adopt (if any)?
- Where should this piece of code live?
- How do we test this functionality?
- What database should we use?
- Should we use NoSQL or SQL?
- Should we use choreography or orchestration?
- How should we host our code?
And many many more…
Every one of the answers to these questions should start with “It depends…” and end with a view of the context and people that will be affected by the answer, followed by a decision.
It’s fine to go with the popular default answer.
It isn’t the only answer that exists.
Summary
The golden rule: No matter what the question is, the answer can almost always start with “It depends…”
Comes out of a few features of software:
- We write software for other people, not for computers
- The context in which a piece of software is written, makes a huge difference to the answer to a question
- We need to take a balanced view, consider the possibilities and then make up our mind as to what is the most appropriate answer to a question, rather than answering with whatever is the default response.
About the author
Hi, I’m Doogal, I’m a Tech Lead that has spent a bunch of years learning software engineering from several very talented people. When I started mentoring engineers I found there was a lot of knowledge that I was taking for granted that I think should be passed on. These stories are my way of trying to pay it forward.
I can be found on Facebook, LinkedIn or pokeprice.io.
