Thanks to Udi Dahan, for a limited time the popular Advanced Distributed System Design course was available for FREE in light of COVID-19 impact across the globe.
Besides key takeaways on microservices, there was one of the noteworthy points mentioned in the course about software requirements.
The business doesn't really give developers requirements. They have an inventive workaround to achieve something they need done, and it's that that is presented as a requirement.
Role of a software engineer
As we gain more experience as a software engineer and start looking beyond code one striking realisation is that our core responsibility is to solve problems not just write code. Having said that its often easy to overlook this fact in the race to meet sprint commitments and shipping things faster. We need to take a step back and relook at the requirements, collaborate with business analysts or product managers to identify the real business requirements.
Why workaround ?
In a brownfield project the business looks for opportunities to add new features with low development costs. In the process of achieving it there is a tendency to overcome limitations in the product with workarounds rather than enhancing the product.
Cost of workarounds
Workarounds introduces product debt. Yes you read it right, it's not technical debt! Product debt increases complexity in product, making it difficult for software engineers to maintain in the long run.
Workarounds are mostly client specific, eventually hampering the extensibility of the product to build new features.
Real world experience
One of the products I was involved, had a highly configurable workflow management. Few months into the project, we were onboarding a new client. The requirements of workflow management for new client could not be satisfied with the existing implementation. However instead of enhancing the product a clever workaround was found using the configurations. I was analysing a story in backlog later only to find out the additional effort on the dependant feature to work as expected was a result of the workaround introduced weeks earlier.
Like most problems in software engineering it's also a culture problem when the business incentivises effort reduced in short term without considering the impact on the long term.
Conclusion
As software engineers it's our responsibility to not just keep technical debt on check but also the product debt on check.
Top comments (0)