Top Ten Software Villains
| September 6, 2018 | in
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.
Something we run into a lot here at DPL. Someone threw out some software and now the software can’t meet the customer demands.
This probably means the software isn’t very testable. Highly-coupled systems are often the outcome of incoherent design.
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.
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.
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.
Software has a natural tendency to decay if no one is constantly pruning it. The best way to avoid this is with code reviews.
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.
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.
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.