Written by:

Aran Vink

Software engineering: balancing what you make and how you make it

What is our Itility view on the software engineering discipline? We’ve decided to put that into words using 3 statements given by software consultants Nick, Aran, and Thom. Their views on topics such as best software practices, CI/CD, DevOps, and consistent documentation define our opinion on the art of software engineering. Do you agree with them?

Nick van der Veeken: "As a software engineer, your main contribution to the project is not the code that you write.”

Your main task is to shape the way that the software is designed, built, and tested, such that all subsystems work well together, and, eventually, run smoothly in production. This requires a bird’s-eye view across the boundaries of the different phases of a project and a critical attitude towards the processes, architecture, organization, and technology that eventually all have an impact on the quality of the software that is produced. Of course, you will spend considerable time coding. That is the core of software engineering. However, that time will be unproductive if you do not spend enough time knowledge sharing, setting the standards for design and documentation, and optimizing the toolchain that is used for CI/CD.

Aran Vink: “As a software engineer, the real testing takes place in production.”

When I say the real testing takes place in production, I do not mean to state that the code shouldn’t be properly tested upfront. It goes without saying that a strong test automation should be conducted. However, automating these tests can take up a lot of time and money, so it is important to initially determine the criticality of your application. You simply can’t spend unlimited resources on every application/code writing test automation. So, it is important to balance customer cost with customer value, and timebox – with your project team and customer – how much time we agree is feasible to spend on automated testing, and how much time we will allow for ‘real life testing’ and quick fixes while in production.

In practice, automated tests can filter out many bugs, but the most complex situations emerge in the wild; when the code runs in production. Consequently, if you are striving for a high-quality application, you should make sure that you can quickly react to errors when your code runs in production. That’s why a DevOps approach is essential. Through constant monitoring and logging of incoming data, unexpected behaviors can be spotted early on and the team can act on these before they become a real problem. DevOps allows for short development and test cycles, making your applications flexible for change and improvement. In other words: if your way of working is agile and you are prepared for rapid change cycles, testing in production can be an agreed optimal way to go.

software statements blogfoto

Thom Koomen: “As a software engineer, your job is to make yourself redundant.”

This means that the work you deliver should have such quality that future work is either automated away or transferable to a colleague at any time. Of course, it sounds controversial to work in a way that could potentially leave you without any work, but this also means your employer and/or customer can be flexible in using your skills in different projects and solutions. Any sudden need for your expertise in another project, any shifting in priorities (which moves current work to the backlog), or even any sudden leave/absence, should not prevent a colleague from picking up where you left off.

What does this mean for your daily activities? Besides communicating and documenting the decisions you make, the software you deliver should be thoughtfully and understandably designed and crafted. It should be clearly written and documented, it should have consistent style, formatting and syntax, and it should be properly structured and versioned. In short: this means writing well documented and easily readable code. The better you become at being redundant, the more valuable you become to your employer, or your customer.

So how does this come together?

Looking at the statements, we can distinguish two essential elements of software engineering: what you make and how you make it. On the one hand you want to build a reliable application with a modern architecture and on the other hand you want an effective design process and a streamlined software production toolchain. While often a tangible outcome (what you make) will be requested, both elements are of equal importance. Without the right foundation (how you make it), you won’t be able to achieve the desired outcome.

Curious about the work of software engineer at Itility? Have a look at my previous blog.