“Yeah, we know we have technical debt. We have added a dedicated epic in our backlog for quality related items and will pick as soon as we have some bandwidth from business deliverables” — A typical reaction to poor software quality question
Postponing quality is not technical debt, its irresponsible software development.
Be it the lack of automated testing, code maintainability issues or team’s inability to continuously integrate and deliver. Do it later attitude just makes things worse.
But, our focus is delivery right now, we will improve quality later Focusing on timely delivery must not be an excuse for writing substandard code and lack of automated tests. Postponing quality compromises the customer’s right to timely delivery, as it allows potential bugs to be discovered later on, ultimately doing a disservice to the investment made.
But, we inherited this legacy codebase Garbage tends to attract more garbage. Don’t let the legacy of the past define the future of software development efforts. Follow the “Boy scout rule”. Clean as you go.
But, we just started this as a PoC for this new platform/technology evaluation Why shouldn’t a technical evaluation involve how quality will be handled? Any evaluation without consideration on adherence to good design principles and quality assurance is incomplete. While its understandable to acquire short term technical debt to validate assumptions faster, its important to pay back the debt before its grows out of hand.
But, our business wants us to focus on development first Code and test quality is an integral aspect of software development. It should not be seen as a separate activity. If business asks to quick delivery, they also have the right to know the risk involved due to bad quality and its impact in future. Maintaining that trasparency is team’s responsibility.
Do the right thing. Build your software with quality as a pre-requisite.
Some book references to get started