Or, write software as if you really cannot afford a software crash.

I have been watching numerous space exploration missions with interest and it is amazing the abilities we can give these spacecraft with proper engineering principles. It also made me ask some questions. Why does it seem like the software in those spacecraft runs so flawlessly? What is different in the companies that design these space vehicles compared to a company that runs an online shop?

I have worked for a few companies and each of these companies had at least one big failure, and too many to remember lesser failures, but still failures that impaired functionality. Talk to developers, and despite their best efforts, at some stage, something breaks. I do know that some space missions fail – but compared to failures in the IT industry ‘on earth’, it seems minimal.

What do we need to write software as if we are working for NASA? The good news is we do not need to wait to work for a company that writes software that flies spacecraft to the moon. You do not need to wait until you have the unfortunate opportunity to accidentally blow up a multi-million dollar investment. Neither do you have to wait to accidentally cause someone’s satellite to navigate itself into Mare Serenitatis, leaving a crater that no doubt will be named after you before you start writing good code.

To risk sounding like a home gym advert: “you can start doing this right now no matter where you are, even in the comfort of your own home!”

You do not need a lot, all you need is some discipline, some knowledge of software engineering principles, and a process. The term process is used very broadly in this post and encompasses all the steps needed to create the software from the inception phase to the delivery phase. The process should be very detailed. I will write an article about that at some stage, but it goes further than discussions about waterfall versus agile or what other SDLC you will follow. It should also detail how you break down your tasks, assign time durations to each task, how much details goes into each task. If you are unfamiliar with these processes, I would recommend that you do a lot of research on this topic. You also need strict standards for your codebase, and everyone should feel responsible for the quality of the codebase. Standards for your codebase goes beyond the capitalisation of parameters and on which line your brackets go. In order to keep your codebase scalable, you need to design it in neat layers, and not let someone break the rules of the layers. You need to know how to separate the tasks that your different modules will be doing.

Discipline will drive the process. Not militant discipline. But the kind of discipline that causes you to still add that last unit test on a Friday afternoon even though you don’t want to. When the process gets neglected, it may be due to a lack of discipline, but it can also be due to a lack of manpower, lack of experience, or lack of understanding of the process. If you are understaffed, and shortcuts need to be taken due to time limits, the process is first to suffer. If discipline is not the cause for the process failing, then it can be a lack of manpower. This can be due to recruitment still happening, or for financial reasons. If this is the case, two potential solutions can be to trim down the application being built or move the timeline out. However, letting the product suffer from defects and an ad-hoc design is not the solution. Lack of experience and lack of understanding of the process can be fixed by letting your more senior people mentor newcomers and creating documentation detailing the process.

If discipline is the problem, well then you may have bigger issues at hand. Solving this can be very difficult. There may be a bigger problem in the team or only one bad apple affecting the project. One way to start assessing what the problem can be is to enquire from the team as to why the process is getting neglected. Set up a meeting, take some examples and ask the team. You may be surprised by what you hear. The answers can stretch from laziness(which is bad) to the process is too cumbersome and may need some refactoring(which is good). It is always great to have developers that take ownership of a project and pride in there work. These are the members that will follow the process even on days when they do not feel like it.

It is also very important to invest time in learning some software engineering principles. If you are working in an object-oriented environment, definitely invest time in learning how to create objects and when to use composition over inheritance. I have seen first hand how software developers decide on the fly what classes they need without investigating whether such objects or part thereof already exists in the system, or without thinking twice about designing that object properly. I have done this myself back in the day, because sometimes it just felt intuitive, but without thinking about it properly, you are bound to create a hardly reusable class.

All objects are not created equal.

Then of course – coding. I have found scenario-based thinking very helpful in getting edge cases and different ways the system can be used, or things can go wrong in. Sometimes I just create a written out list of scenarios, each and every scenario you can think of. From there, code the handle all of those scenarios. Chances are you won’t be able to think of each and every scenario, so it makes sense to ask a colleague to help you, or even better, if possible, ask the users you are creating the software for.

These are my thoughts for now regarding this topic, but I have a lot more. It is such a vast topic, you cannot pin it down in a single post. Getting the process right has intrigued me for years now, and I know I still have a lot to learn. But applying everything I have learned in my current job, shows me I am progressing in the right direction, and having said that, all of the things I learned at my current position shows me that there is no single silver bullet to solve the problem of how to write great software, but there certainly are great guidelines.