Software is a crucial part of our life. Period. We rely on it when paying bills, searching for the perfect birthday gift or even choosing a life partner. Software controls our room temperature, oversees food production and prevents money from being stolen from our credit cards. Of all its properties the most expected one is to be correct. The more depends on the particular item of software, the more important the requirement of correctness becomes. A display glitch in an arcade game may be unpleasant, but a calculation bug in a banking system has a potential to cause real damage to individuals or even entire societies.
How do we ensure the software is correct? In the initial stage this is the developer's job. Whether in the design phase or during the actual coding, the programmer is expected make the best effort to deliver a correct software. This is a noble assumption, but the practice proves that no human is infallible and relying on that promise alone is destined to fail. Over the years, the software industry came up with a number of ideas to ensure the software correctness and software quality in general. The solutions include static code analysis, manual quality assurance, automated tests of different kinds, code reviews etc.
It's fairly safe to assume that in 2023 the vast majority of software engineering teams in the world apply all or most of the mentioned techniques to ensure their software quality. There is a plethora of tooling to choose from, the knowledge is free and widespread and the processes are proven and well estabilished.
The problem
I'm so lucky to work with a bunch of experienced and disciplined professionals. We're really good at following the best practices and adopting latest tech. As human beings we're also not free from the common traits, like the fear of change. After adopting various solutions and processes to ensure the quality of our products, it turns out that there's not much to add to that area to achieve even better results. Apart from the fact that we already use all available options, comes the effect of increasing complexity and cost with every new item to be added.
The feared solution
In a search of new potential ways to improve the quality one idea popped up eventually: Instead of adding things, start removing them. The less items to work on means less complexity. Less complexity translates to more resources we can spend on the remaining quality-assurance practices.
Getting rid of unit-tests or the code review is likely not the best implementation of this idea. Instead, we can try replacing fragments of the actual application code with 3rd party libraries. The front-end ecosystems covers most of the imaginable needs these days. Unless you're dealing with a very unusual problem or requirement there's almost always some solution already available.
This is where the natural resistance to change comes into play. The internal reasoning varies from person to person. The first challenge faced by the change proposer is to convince the rest of the team to accept it.
Social techniques to the rescue
In my personal ranking of skills I classify convincing other people to support my ideas somewhere between art and magic. It requires knowledge, practice and natural talent. How effective the social technique of anchoring effect proved to be is the reason I'm sharing this story.
The anchoring effect belongs to the category of cognitive biases and it leverages the fact that people tend to make their decisions based on the first piece of the information they receive in a given context. That first piece becomes the anchor, hence the name. This makes it much easier to offer anything as a better option if it's presented as an alternative to a very undesired first option.
My proposition was to replace one of the core components with a 3rd party library. The gain was removing the cost of maintaining the component. The catch was that everyone was pretty familiar with it. The trick was to sell the desired change as an option alternative to reimplementing the whole parent module. The effort and risk of re-implementing an entire module makes it unacceptable up front, but it also creates enough contrast to make the smaller task look digestible.
Conclusions
Software development is about human interaction as much as it is about writing code and dealing with tech problems. Building your toolbelt of soft skills is important equally to mastering the latest frameworks.
Top comments (0)