Top Ten Software Villains

This afternoon, Doug Durham presented the afternoon keynote at the 2018 Heartland Developers Conference. In his presentation, entitled “Be the Hero – Stop Being the Development Villain”, talks about the ways we as developers can sometimes be the villain and contribute to why software often breaks.

But there are other villains in this story, ones that we create or allow to fester over time. Unlike other Top Ten lists, there is no particular order here. If you’re a developer, some of these may not be relevant to you…at least not yet. Given enough time, you will likely encounter all of these.

Rebuild-i-later

Something we run into a lot here at DPL. Someone threw out some software and now the software can’t meet the customer demands.

 

Highly-Coupled System

This probably means the software isn’t very testable. Highly-coupled systems are often the outcome of incoherent design.

 

Unusable Software

Unusable software is an interesting problem. You can do almost everything else correct, but if the software isn’t usable what good is it? Building usable software requires project managers, project owners, user experience experts, and software architects to work together and focus on the customer experience.

 

Rigid Architecture

Software is built on 1s and 0s, but good software is built on Lego blocks that can be swapped out. Don’t make it impossible to extend software; extending software should be just as pleasant as building it the first time.

 

The Untestables

This one probably is linked to Highly-Coupled System. It is not uncommon to eventually make the system completely untestable. This isn’t just bad for quality, it probably means you have design problems too.

 

Rot

Software has a natural tendency to decay if no one is constantly pruning it. The best way to avoid this is with code reviews.

 

Monolith

Building a big monolith can be fun, but it is rarely fun to maintain. Breaking your large system into manageable pieces is essential for long-term happiness.

 

Tech Soup

This is a common problem in the current JavaScript world: it feels like we build systems on a house of cards. First, we add in x module, then y module. Before we know it, we don’t have any idea what modules we are consuming.

 

Scope Creepinator

Scope creep is a real problem on software projects. We all have this desire to add one more feature. It takes a focused project manager to keep us from going crazy.

 

Needless Complexity

As software developers, we often like to add complexity to projects. This is the one I am personally bad at; I can create some good complexity. It takes a lot of discipline to not make this mistake.