Modern software engineering

Margaret Hamilton built the Apollo flight control system aka the first software ever built. They didn’t have stack Overflow in the 1960s to look up for answers for the bugs they found. Yet, they built in redundancies to make sure the core functionalities of the program would work properly, despite the failure of other components. In fact, Neil Armstrong landed on the moon despite computers reporting 1200 & 1201 alarms, because the systems rebooted the core functionalities (David Farley, 2022). The first software engineer in the world, used a modular approach with a high emphasis on exploring "how a system may fail". According to a survey carried out by the McKinsey group together with Oxford University in 2012, 17% of large software engineering projects (that had budgets over 15 million USD) went horribly wrong (Stanford, 2022). What went wrong?

During 2022, I was often told, rather reminded that “Software will never be free of bugs”. I was reading 1000 pages of books related to software architecture, modern software engineering and so on, just to find out, to what extent a bug should be acceptable and how to avoid them. This led me to an interesting yet simple definition of what "Engineering" was. "Stuff that works" is what engineering is according to Glenn Vanderburg. Applying this definition of software engineering, we can define software engineering as a process that develops software (stuff) that works. Within this context, we can define a "bug" as something that makes the software not work. It may be a simple bug on the FE or something serious at the BE, that affects the functionality of the system. Regardless of the technical complexity of the bug, if it affected the value for the client, that bug should be considered as critical, because it affects the value generated per dollar spent by the client. Therefore, it is crucial that the organizations implement proper quality assurance mechanisms to maintain the quality of the code using continual testing and modern quality checking solutions such as SonarCube.

Besides the quality, changes may have to be incorporated into the software as the technologies and trends evolve rapidly. In a dynamic industry, a waterfall approach to development, where the requirements get finalized at the very beginning will not work, even if you have the best BA in your team. In order to develop "working" (that matches the customer expectations) software, companies should aim for building high performance teams with high stability and throughput. The teams should be stable to have a low number of defects at a point in the process when a change is introduced, and should recover fast from such a failure. Next, the teams should be built to reduce the time taken for a change to be converted to a working chunk of code in the software. In addition, the changes needed should be rapidly introduced, rather than waiting until the end of the project to integrate all the changes in one go. These practices facilitate faster feedback and continuous delivery, which is core principles of the Agile development process.

To summarize, the aim of the software is to build software that works and deliver value. In order to do that, organizations should have proper QA and agile teams with,

• High stability with low change failure rates and recovery failure time
• High throughput with low lead times and higher frequency.

By doing so, we may reduce the number of bugs in the software that we develop, and also improve the value given by our services.