I write software for a variety of reasons, to learn something, the challenge, wanting to create value, and just to pay the bills. And sometimes I write software because I’m frustrated with existing tools, or lack of tools.
There was a product I used for many many years, paying for updates and getting some value out of the updates, but also in the hopes that the issues I was experiencing would be fixed. But year after year the items that bothered me were not addressed. I could see them adding more and more features, that didn’t represent value for me. So I wrote my own product, focused on the things that brought value to me.
Does my product work better? Well in some ways yes. It’s a much faster product with features in a few areas that others don’t have, because those are valuable to me. Does my product have bugs? Yes. Are these likely to annoy someone else just as the original annoyed me, quite possibly.
Why is this? Why as developers and producers of value do we let these things happen?
There are many factors. Some of it is inertia, or lack of it. You develop a feature and it requires a lot of energy, and you stop at ‘good enough’. This is a good place to be, someone will get value out of what you have done. However, like everything in the world, as people use what you’ve produced they’ll start to see the cracks. Maybe not right away, but eventually they will become apparent, even perhaps annoying.
Perhaps you don’t even use or understand the product you are producing. That makes it even harder to see the cracks, whether it’s yourself or your testers.
External factors can also play a role. If leadership are putting time constraints on your delivery, or even just communicating a lack of concern for these factors, that can shape how developers and testers work and focus.
And it can be an overall outlook. Perhaps as a developer you don’t see the value in writing your own tests. Perhaps writing the tests themselves is a hard activity.
Is this negative, is this bad? Not always, end users may not be using the product frequently, and getting sufficient value to reduce the impact of any gaps.
But when it has an impact, recognizing the impact is another way to add value. And the best have to mitigate impact is to improve upon the root causes.
Finding that early balance, improving upon your initial testing efforts has significant long term impact. It allows a developer to refactor code with some confidence the results are positive. It identifies expectations, helping to uncover and enforce “tribal knowledge”. It can explore negative areas, what happens when values are not expected?
Beyond testing, focusing on usability itself helps identify issues as well. Maybe something is annoying to do in a product, but the operation is infrequent. Think about what happens if that activity becomes frequent? Would you want to do it? If not it’s a good argument for change. Maybe the operation is hard to find, buried deep in a menu, or a command line operation, or a button no user realizes is a button.
And leadership has to find opportunities to make these activities happen, and the developers have to value these areas as well. Many times leadership tradeoff these activities, and don’t allow for the technical debt to be paid later. They need to recognize when this will have an impact and address it (hopefully before it has an impact).
Developers have to learn to value and recognize these areas as well. The sooner little things are eliminated the sooner they improve the overall value, and learning how to balance the amount of little things with “good enough” is worth the effort.