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.