A journey to good software

Like many other developers, I took my first steps into software development without knowing exactly what I was getting into. The first small test projects I did missed the mark with aplomb – they were completely unusable and unstable. But all these problems seemed solvable with some better code, so I thought I knew what I had to do: build programmes and features that people need and like to use. Only on the way did I slowly realise that simply writing code would probably not be enough. This journey continues to this day. My view of software development has changed profoundly several times since. I would like to share the crucial insights and changes of mind I had and give you an idea of what the world of software development is like.

From the waterfall to the sea

My first two steps in software development were a ‘Hello World’ and a calculator based on a long-outdated technology called Windows Forms – a technology that allowed you to write programs for Windows desktop PCs. In case you’re wondering, ‘Hello World’ is a small programme that displays the text ‘Hello World!’. It’s usually the first thing you build when you learn a programming language to understand how it works.

My ‘Hello World’ wasn’t pretty, and the calculator was unwieldy – but they were my first programmes and I assumed that practice would be all it took to write good programmes.

About three years later, after I had finished my vocational training, I was working on a programme for a machine control system and was concerned with programming features and how to get the programme from our computers to the customers’ computers. The process for all my tasks up to this point had always been the same: we started by defining exactly what we wanted to achieve with the development process, then we drew up a plan on how to get there and then we started programming. This process is called the waterfall model.

The waterfall model may seem sensible and charmingly simple at first glance – you have a precise definition of what you want to achieve, you’ve planned the journey to get there in detail and then you just follow the path you’ve set out for yourself. The problem with this approach is that it doesn’t line up well with the nature of our world or with the nature of software development. The world is constantly changing at an ever-faster rate, resulting in demands, priorities and goals changing as well. Software development, for its part, is a creative process that requires finding solutions to problems that only become apparent along the way.

In short: I spent a long time developing major features, rarely finished on schedule and in the end the result was rarely what was really needed. This was frustrating for me as well as the users, meaning I was nowhere near my goal either.

In this situation I learned the first important element for developing good software: agility.

Agile is an initiative founded by a small group of experienced software developers more than 20 years ago, when they published the Agile Manifesto, which has since conquered the world of software development with its no-frills, goal-oriented and flexible principles. The Agile Manifesto consists of four principles that put cooperation, flexibility and working software at the heart of software development (see https://agilemanifesto.org/). Probably the best-known agile approach today is Scrum.

It was developed by two of the authors of the Agile Manifesto and is still maintained by them today. Scrum is a lightweight framework that defines responsibilities, events and artefacts for development in small teams. This should enable the team to develop useful software in a step-by-step process that is ready for use at any time. Requirements and implementation are regularly compared with each other in the expectation that there will be misunderstandings, obstacles, priority changes and changes in objectives. So while the waterfall model sees software development as a leap from the top of a huge waterfall that you can plan, Scrum sees it as a journey across a vast sea during which you have to correct your course on a regular basis. This makes Scrum a much better fit for a constantly changing world and has become the de facto standard for modern software development.

From first-person perspective to invented characters and short stories

This switch meant that I started writing features that are better suited and I constantly improved my understanding of technical problems. However, the resulting programme was still unwieldy, and the features were difficult to find and understand. In other words, the code still didn’t do exactly what I wanted it to. I also didn’t understand a lot of the techniques and concepts that my colleagues were using. That prompted me to start studying computer science, expecting to find answers there. At around the same time, a new department was set up in my company to deal specifically with the development of the UI (user interface), which I then took the logical step of joining. After all, it was a matter of learning how to get to my destination. Up to this point, I had built UIs following the approach of what might you want to do in this software?

This is where I learned about two more important elements that help to develop good software:

usability engineering and requirements engineering.

To write good programmes for users, you have to understand who those users are and what the programme is supposed to help them with. This seems straightforward at first, but in reality, it is often quite difficult. This is because there usually isn’t just one user and you often don’t know them personally, let alone are you in a position to repeatedly and incessantly pester them with questions about what they want the software to do and what they would like. The discipline that deals with this problem is called usability engineering. This involves techniques and methods that help you understand who the users are and what they want.

One technique from the realm of usability engineering that is particularly helpful is called personas. A persona is a description of a typical but fictitious user with a name, age, picture, personality traits, knowledge, interests and desires. This sort of persona helps to put yourself in the position of the user and thus to question your own approach to the solution or to discuss it with colleagues. When in doubt, be prepared to follow the mantra of ‘kill your darlings’, since just because you like a solution doesn’t mean it’s a good one for the user of the programme.

User stories are a very helpful technique from the field of requirements engineering. They are short descriptions of requirements according to the formula, ‘as a [customer], I want [action] to [add value]’, which are usually specified by acceptance criteria. When filling in the placeholders, it’s important to make it clear who wants something, what this person wants and what the benefit will be if this wish is fulfilled. The acceptance criteria should make the requirement concrete and make the implementation of the requirement measurable.

User stories enable you to quickly record requirements in small, manageable units with all the essential information. As a result, they also fit in extremely well with agile development, as their small scope and low effort promote flexibility.

Usability engineering and requirements engineering offer a variety of great tools for developing good software. The crucial thing is to choose a suitable tool for the challenge at hand. When choosing your tool, there should always be a healthy ratio of effort to benefit.

From the soldering iron to the production line

A few years passed. During this time, I had learned to put myself in the shoes of the user, to extract requirements from their wishes and to design usable software based on them. The goal seemed within reach but was never attainable in practice. Although I now theoretically understood how to create ‘good software that people like to use’, the decision was never made to invest the necessary effort in practical terms. There were too many other areas to work on, too many urgent tasks and human errors always cost time. By this point, I had completed my degree in computer science, as well as a degree in economics. I wanted to understand why people decide not to opt for good software and whether anything can be done about it. My curiosity for something new drove me to look for another company that might make different decisions, and I ended up in a completely different field with a completely different mentality. The company was much smaller and, as always, there was a lot to do.

This is where I learned about more important elements that help to develop good software: automation, quality control and DevOps.

There is never a shortage of new tasks in software development, but always a shortage of time. Repeated tasks can lead to losing critical time needed to actually continue developing the software, which is why you should check whether a time-consuming, regular task can be automated with a reasonable amount of effort. Depending on the complexity of the task, automation can range from a simple shell script to a fully developed CI/CD. CI stands for continuous integration and refers to the automation of software deployment processes. CD, on the other hand, stands for continuous delivery and refers to the automation of processes for delivering software.

Errors also steal valuable time in the software development process. The best thing would be not to make any errors at all, but that’s impossible. Instead, you should do the second best thing and avoid them. When you run into the errors that are going to happen no matter what, do the third best thing and reduce their impact.

One way to avoid errors is through automation and standardisation. This ranges from automating the assembly of the software to using standard components and frameworks, established architectures, patterns and principles.

The best way to reduce the impact of errors is to find them early. Common methods for uncovering them are unit tests, integration tests, system tests, test automation, static code analyses and code reviews. A rule of thumb for calculating the cost of mistakes is that an error becomes ten times more expensive with each stage it travels towards the customer. Finding the error during the development process costs a few seconds. However, if the error can jump through the unit test, integration test, code review, system test stages and make it all the way to the customer, then those few seconds can turn into several days of work because the error has to be reported, documented, reproduced and fixed. This ends up with several people being involved, not to mention the damage to your reputation it causes in the customer’s eyes.

Communication and networking between development and operations also helps create a structure to avoid errors and to find them early on. This is where the role of DevOps has emerged in recent years, which acts as the link between these two worlds and promotes cooperation between them.

Automation, standardisation and DevOps allow you to save time, avoid errors and detect errors early. Repeatedly performing numerous manual steps or designing components yourself can cost valuable time that can be invested in the development of the software.

Even though a soldering iron is a flexible tool that can be used in a number of different ways, it still has the disadvantage that it is operated by a human being who can make mistakes. A production line, on the other hand, is not flexible at all, but has the advantage that it rarely makes any mistakes once it is up and running. You should always opt for the choice that saves you time and reduces the number of potential errors.

Conclusion

It should come as little surprise to you that there is no ‘golden hammer’ for writing good programmes. The ‘golden hammer’ describes a phenomenon in software development where a developer tries to solve every problem with the same, familiar tool, even though the problem might require a different tool. It is often summarised as, ‘if the only tool you have is a hammer, it is tempting to treat everything as if it were a nail.’

One process model, one programming language and one technology is rarely the answer to all the problems you will encounter. To write good programmes, you need to be able to analyse problems and have the right tools to solve different kinds of problems in your toolbox (or at least know where to find the right tools). Fortunately, the software development community is full of people who are more than willing to help and have lively discussions, so you are rarely alone when you have a problem. It doesn’t matter whether you find the right tool on Stack Overflow (an Internet forum where software developers can ask questions and others can answer them), GitHub (an Internet platform where you can post source code) or on a blog, whether you find it during your studies, in a book or by listening to a podcast, or whether you find it at a conference, a meet-up or simply with a work colleague. The important thing is to go looking for it and ask around in the first place. Understanding that a tool does not fit a problem and looking for a more suitable one is a sign of professionalism and is the difference between simply tinkering and actually developing.

You will find more exciting topics from the adesso world in our latest blog posts.