How Smart Engineers Create Bad Software
You ever wonder how a room full of what appears to be smart engineers manage to build software that doesn’t work? Given more time and money, it appears to only get worse or no better. It doesn’t make that much sense does it? As someone who writes software it’s hard to see how bugs that bring whole systems down seem never to be fixed. Or how 5 bugs get fixed but 10 more appear in their place.
So how is it that smart engineers create bad software?
- Too much time. (over engineered)
- Lack of correct development environment.
- Unclear overarching design.
- Siloed groups.
- Principal engineers that are not leaders.
- Obsession with perfect testing.
- Overkill of computer science.
There’s are just my opinion and observations after watching all sorts of teams and people build, or try to build and deliver software products.
Too much time.
This one isn’t that obvious at first. You would think that a team given a unlimited or huge time horizon in which to deliver a piece of software, could produce the perfect product. Quite the opposite appears to be true. We are humans after all, with no pressure of a deadline, most teams/people fall prey to getting nothing done…. or too much done…. or not the right thing done.
There is something about a deadline that focuses the mind, gives clarity and reality to technology choice and time spend developing features. That is not a bad thing. Given too much time there are usually a few outcomes. Over engineering a system is one. At the end of two years, some behemoth is delivered, like the Kraken from depths of the sea. It’s unleashed in all it’s terrible glory with no hope of return to a more stable, simple, and workable past.
Also, too much time is spend on trivial things in the beginning, things that have little to no benefit of being robust or perfect, and the items at the end of the project are rushed, slammed together, and lack the attention needed.
Lack of correct development environment
This topic also seems like a small item, but makes a big difference in the end. If developers and engineers are developing on their machines and have no way to design and test their code in a production like environment that acts and responds how it will in the wild, the project is doomed.
Inevitably the important small differences in environments will mean code constantly being wrong and errors and bugs arising in production at the worst times. If the environments are that much different, it may even cause different design patterns to occur! What a nightmare! It’s just a fact of life, the farther away development and production are from each other, the more bugs and problems you’re going to have.
Unclear overarching design/architecture
The next pitfall is a more obvious one. This rings true in all parts of life, and software development is no exception. Getting bogged down in architecture is a problem, but having no plans or big picture will only lead to lost wandering for engineers looking for the way.
The larger the problem and code-base, the more important some sort of specs and dependency charts being available to everyone is. Goal setting is important, something to aim towards. Having even a few sentences to guide the development of some feature will put at least some bounding box around the problems and expected outcomes or solutions.
Being unclear about how code fits into and interacts with its’ world will only lead to a spaghetti mess that doesn’t solve anything, or do anything well in particular. The code produced will be as unclear as the architecture was/is.
Silo-ed groups.
This is another obvious problem that has been hounding businesses forever. Apparently it’s just to irresistible for companies to pass up. Here’s how it works.
Give 5 different groups of engineers directions to build 5 parts of a larger system. Then decide that everything will be ok when it’s all brought together. What could possibly go wrong? This sounds so silly but it happens all the time.
If your going to have silos at least build a tunnel between them. Software is intricate and the small details matter, different design approaches taken by separate teams will end up requiring complex middlewear or other approaches for what should be puzzle pieces.
Principal engineers that are not leaders
This one might not be so obvious as the last two, but is probably more important. A great leader can overcome huge obstacles, leading a team to victory…. or defeat. The principal engineer of a group has that power.
They set the tone. If they only care about themselves, that they are the smartest, have the best ideas, and can do no wrong, then the software will suck.
On the other hand, if they are pragmatic, leading others to solve problems and sharing their valuable experiences, this all will inevitably lead to success. Nothing will kill innovation and team problem solving more then a jerk at the top who is more concerned they appear as the smart one who alone knows how to write good code.
Obsession with perfect testing
I can hear the moans and groans, the nashing of teeth already. This is a classic case of putting the effort inthe wrong spot. Of course testing is important and critical to the success of good software. It brings clarity, consistency, and confidence.
But, the obsession with testing that causes more time to be spent writing tests then the actual software itself is just silly. Give engineers the latitude to test what needs to be tested, and to leave the rest to chance. If they wrote the software they will know the critical components vs the fluff.
The only people who preach 100% test coverage are those who make a living by it.
Overkill of computer science
Yes. I said it. It doesnt really matter if all the time was put into creating the perfect class inheritance instances. That code reuse was made perfect. The rise of functional programming should tell us that things change.
A good dose of every kind of computer science and theory is healthy. An overdose of engineers obsessed with theory, leaving reality for the fools is a bad idea. How many times have I overheard a group of engineers argue how to “correctly” do a thing, and accomplish nothing but a waste of time, disunity, bad feelings and eye rolls from the near by product manager.
The Conclusion
What did you think of my list? While I’m sure there are dissenting thoughts, I would assume the ring of truth stuck a cord for a few of the points. Want to write better software? Be pragmatic, be kind, creative, flexible, willing to change. Focus on what matters, be clear, concise.