What are the aspects for good software? Find what qualities and considerations you should make for your next software project.
Many teams and companies regularly ask themselves how they can improve the quality of their software development.
The answer to this question encompasses 12 aspects that every team and company should implement. What are these aspects, what to look for in their implementation, and why are they important?
Many teams and companies regularly ask themselves how they can improve the quality of their software development. The answer to this question varies, depending on how things are already being developed.
Even so, there are 12 aspects that every team and every company should implement.
These aspects sound simple in theory at first, but putting them into practice is often more difficult than expected.
Teams and companies can use them as a yardstick to carry out a self-assessment and to question and evaluate the quality of their own software development.
The whole thing was based on the ” Joel Test “, which was developed by Joel Spolsky (the former CEO of StackOverflow).
This test dates back to 2000 and is therefore no longer up-to-date, but the basic idea is still good. So it was time to modernize this test.
1. Is the subject domain understood?
The first aspect is the question of whether the team really understood what it was about from a technical point of view?
In other words, are there domain experts in the team, and is there a common technical understanding and a common technical language?
Can you make sure that everyone involved in the team actually talks to each other instead of bypassing each other?
All of these questions may come as a surprise, but in practice it is actually relatively rare for a team to be set up in such an interdisciplinary manner.
Much more often you come across a pure development team that is isolated from the specialist department and somehow works.
While it is obvious that this may not work well, it is common practice in many cases.
The reason that can't work on the way is because software is designed to solve business problems, not for technology's sake.
Therefore, good software development is not possible without detailed specialist knowledge of the underlying domain.
2. Are professional requirements formulated?
When the technicality has been understood and a common technical understanding and a common technical language have been developed, the second aspect is added: Are the technical requirements “well” formulated and written down?
“Good” here means that the requirements are understandable, target-oriented, compact and complete.
In practice, it is always surprising how little attention is paid to these points – or, what is even worse, how often development is carried out without any technical requirements.
This usually means that you can rely on the developers having memorized what was discussed and interpreted and understood it correctly.
If one does not hold onto the intention of the users, the common thread is missing in the development, there are no acceptance criteria and ultimately what is practically not working is developed on demand.
3. Is development based on streams?
However, all of this is only useful if the work is then carried out in a structured manner – i.e. not, as just mentioned, on demand. For most teams, this means working in sprints, which is not least due to the spread of Scrum.
However, sprints also have numerous disadvantages, in particular with regard to their ability to be planned.
Since the time scope of a sprint is fixed by definition, the scope of the content must be flexible according to the magic triangle (or the devil's square), if in doubt, the development should not be at the expense of quality.
However, this is precisely what is often not the case, as specific stories are usually planned for a sprint.
This becomes a problem at the latest when something unforeseen happens, e.g. critical errors occur that have to be rectified immediately.
Therefore, it is a good idea not to work in sprints but on the basis of continuous streams , similar to Kanban.
This not only brings calm to development, but also enables a high degree of flexibility and excellent predictability.
4. Are technology decisions based on the business requirements?
The fourth aspect concerns technology decisions.
These should only be made when the technical requirements are known. In most cases, however, it happens the other way round, as the technologies to be used are fixed from the start.
It is not evaluated which technologies would be particularly suitable and which could show their strengths particularly well.
This not only applies to programming languages and platforms, but above all to infrastructure, such as databases and message queues.
The server environment is also often set in stone from the start, because it has already been established, for example, that containers and Kubernetes cannot be used.
In a sense, that's okay too, otherwise you run the risk of getting bogged down.
However, it is important to find a balance between the familiar world on the one hand and new approaches on the other.
This also includes weighing the costs and benefits of new technologies against the old ones.
If you come to the result of staying with what you already know, that's fine – but it should be a conscious, explicit decision.
5. Do you strive for the simplest solution?
In this context, it is also noticeable again and again that solutions are thought too complicated.
The fifth aspect, therefore, is to try to always strive for the simplest approach. A good premise is “make simple things simple and complex things possible”.
Most tools tend to fail because of at least one of the two.
A good premise is “make simple things simple and complex things possible”.
Either they are not “simple”, which raises the initial hurdle and thus makes it difficult to get started, or they do not allow complex solutions per se, which is ultimately even worse, since you are technologically maneuvering yourself into a dead end.
Tools that do both are rare.
That is why it is so important to select technologies in a targeted and conscious manner.
6. Are you using versioning and a suitable branch strategy?
The sixth aspect should actually be a matter of course by now, but unfortunately it still isn't: namely the use of modern version management and a suitable branch strategy .
The formulation ultimately contains three requirements, namely first that version management is used at all, second that it is up-to-date (e.g. Git and not Subversion (SVN) or the Team Foundation Server (TFS)), and third, that there is a plan for how the team will handle branches.
The biggest problem in practice is usually the third point. However, this can be solved relatively easily by using a standard method such as ” git flow “.
7. Are bugs fixed before new features are developed?
The seventh aspect concerns quality, which is often saved on in everyday life – which is, however, a serious mistake.
The most common reason for saving is usually time because a higher development speed is desired.
Why is that a mistake? Because it creates a lose-lose situation.
On the one hand, customers lose because the software does not meet the required quality standards.
On the other hand, the team also loses because it is building an unstable foundation.
The procedure is usually excused by the fact that the quality will be taken care of later – but the next two mistakes are made directly.
On the one hand, the wrong assumption is made that more time would be available for quality later, and on the other hand, the also incorrect assumption is made that quality is a feature that can easily be retrofitted later.
Features can actually also be retrofitted in the further course, but this does not apply to quality or only with enormously increased effort and correspondingly high costs.
One way to make a comprehensive contribution to high quality is to fix bugs before developing new features .
This is comparable to the approach of first striving for a stable foundation before building a house on it. Common sense actually dictates this, but in practice it is always different.
One way to make a comprehensive contribution to high quality is to fix bugs before developing new features.
8. Is code reviewed or programmed in pairs?
The eighth aspect concerns quality assurance. When code is being written, that is what the focus is on – the writing itself.
However, code is only written once, but read all the more often by very different people. This means that, in the long term, a team spends far more time reading than writing code – for example with every change, expansion or adaptation.
Readability is so important because it enables a good understanding and a high degree of traceability of the code, but it does not just arise in passing.
Rather, it is very important to ensure that the text is readable in a very targeted and conscious manner.
This can be achieved either through reviews or through pair programming , which is nothing more than a continuous review in real time.
9. Is a CI environment used?
The ninth aspect takes the foregoing one step further by calling for quality assurance to be automated. As a developer or as a reviewer, you should be able to concentrate on the essentials (i.e. the correct implementation of the technical aspects in the code). What shouldn't or at least hardly be the issue is the external form of the code, for example its formatting.
This is also enormously important for the readability and comprehensibility of the code, but unlike the correct implementation of the technical aspects, external factors can be checked automatically as far as possible, for example through the use of a static code analysis such as ESLint .
What also belongs to this is the writing and execution of tests, whereby there are again different test types such as unit, integration, component and UI tests.
The execution of the tests should also be automated, as it not only saves time, but is also less error-prone than testing by hand.
For all of this, you usually use a build server or a CI environment, which can also be used for other things, such as automated license checks of the modules used.
10. Are releases automatically deployed on a regular basis?
The tenth aspect goes one step further: to automated build and deployment .
The CI environment is supplemented by functions for continuous deployment (CD) so that, on the one hand, it can be compiled and built automatically, and on the other hand, it can also be published and distributed automatically.
This avoids the need for manual distribution and installation, which is often slow, cumbersome and error-prone.
Since manual deployments are seldom deployed, every manual deployment becomes a risk. Because the probability is relatively high that something unforeseen happens and the deployment fails.
In comparison, if you deploy automated multiple times a day, the deployment loses its horror.
For obvious reasons, this works particularly well with containers, Docker and Kubernetes , but in principle an automated deployment can also be accomplished with conventional techniques.
11. Are dependencies updated automatically?
The eleventh aspect also relates to automation, namely the automated management of dependencies. The development process usually only refers to what is currently being developed.
Many developers pay close attention to which dependencies they initially enter into, but hardly anyone pays attention to maintaining and updating these dependencies in the long term.
However, this is hugely important as outdated dependencies pose a potential security risk. The question, however, is often who should regularly check all dependencies and update them if necessary?
The simple answer to this question: there are tools like Dependabot and Renovate that can be run in the background as bot and automatically send a pull request if the worst comes to the worst .
When quality assurance is also automated, you know immediately whether the new versions of the dependencies are working and whether you can merge safely or not.
12. Can code be published at any time?
The twelfth and final aspect is that you should always develop as if your software were open source.
In fact, very few teams and companies publish their work as open source , but the corresponding mindset can also be applied to closed source.
This means that code should be tidy, commented and documented, it should adhere to standards and best practices, and it should be easy to compile and execute at any time.
See: 5 Differences: Open Source Vs Closed Source Software
It should simply be noted that it was developed with attention to detail, and the points mentioned above are all part of it.
You should realize that it was or is important to someone how the code was developed, so that you can ultimately be proud of what you create.
The reason for this is simply that you often write open source for other developers as well, and you therefore put a little more effort into writing understandable, neat and comprehensible code – simply because you want to make a good impression on others.
If you apply this setting to any code, the overall result is better code.
Conclusion on Good Software Aspects
Of course, the twelve aspects mentioned are not the only criteria that determine the quality of software development in a team or a company.
But these are twelve criteria that provide a solid foundation.
If one or more aspects are not taken into account, there is a high probability that software development will be damaged in the long term.
A good start is therefore to question how well things are going with your own team or company.
Do you implement all twelve aspects? Eleven? Ten? Which aspects are missing and why? How could you meet their requirements?
Anyone who seriously deals with these questions not only has an assessment in their hands afterwards, but also has a plan on how the status quo can be improved.
