What goes wrong with software?

My friend Emre Tüzüner posted the following video on Linkedin recently.  It is “Uncle” Bob Martin talking to the Yale School of Management. If you have attended NI Week or the CLA summits lately you may have heard of Uncle Bob and the SOLID principles.  I thought it was a really good video so I will share it here and highlight a few things I found interesting.

It is about 1.5 hours long. It is worth the investment if you are a programmer, or if you lead a team of programmers.  I think it is especially important for those who lead software teams to understand the ideas in this presentation. These leaders are often not programmers themselves, and therefore not good at judging code quality. When they are under time pressure it can be tempting to rush and accept poor quality code.

I don’t want to steal all of Uncle Bob’s thunder, but here are a few points he made that I found very interesting.

Why is Software Quality such an issue?

As Uncle Bob points out the number of programmers doubles every 5 years. That means that at any point in time half of the programmers have under 5 years experience. Inexperience combined with time pressure leads to poor code.  Poor code makes it difficult to make changes and updates which slows us down and make us more likely to introduce bugs.  Ultimately poor code leads to cost and schedule overruns.

Go Slow to Go Fast

You don’t go fast by writing crap code quickly.

Uncle Bob uses a great example to illustrate why it is important to be slow and methodical.  Imagine getting emergency open heart surgery.  The surgeon certainly has a deadline and is under time pressure.  Would you want a surgeon who rushed about hysterically as quickly as he could, with his sole goal being getting done with the surgery as quickly as possible?  Or would you want a surgeon who was very calm, cool and collected, and methodically followed the prescribed procedure?  Often when under time pressure we are tempted to behave like the first surgeon.

What can go wrong?

Uncle Bob lays a few commonly encountered issues with software quality

• Rigidity – you set out to make a small change and you must now modify massive amounts of other code.
• Fragility – a fix in one area breaks other completely unrelated areas.
• Non-reusability – a module can’t be reused without reusing a bunch of other unrelated pieces of code.

The common thread of these is coupling and dependencies

The bulk of software design is managing dependencies.

SOLID

 Uncle Bob then goes on to present the SOLID Principles and how they can solve the above problems.  If you want to know more about that you will have to watch the video.

Takeaways

• Inexperienced software developers are just a fact of life.  It is something we have to learn how to deal with.  That is why having an onboarding process and getting new hires professionally trained is crucial. If you are looking for resources on that checkout the LabVIEW Center of Excellence.
• The best way to write software is slow and methodical.  That is why here at SAS we emphasize have a repeatable process that you follow when developing software. It helps us to slow down and make sure we don’t miss any steps. We also advocate for using VI scripting and Continuous Integration to help automate as much of the repetitive tasks as possible.
• Using the SOLID principles as a guideline when writing code can help avoid a lot of problems with coupling and dependencies. At SAS we advocate for learning as much about software design as possible. There is no need to reinvent the wheel. There is so much information already out there. It’s just a matter of doing your research.

If you would like some help applying the SOLID principles to your project, we would love to discuss how we can help you. Set up a FREE 1 hour consultation here.