Agile Zone is brought to you in partnership with:

In the course of his 30-year career, David Bernstein has trained more than 6,000 developers at hundreds of companies on how to improve their software design and construction. His company, Techniques of Design (http://www.techniquesofdesign.com), provides customized training, coaching and consulting to software developers and development teams around the world, enabling them to master essential practices, including Agile, Scrum, XP, test-driven development, design patterns and related techniques, for building high-quality software more rapidly. David is a DZone MVB and is not an employee of DZone and has posted 18 posts at DZone. You can read more from them at their website. View Full User Profile

Compromises on Quality

03.13.2013
| 2433 views |
  • submit to reddit
Far too often I hear managers say, “Just get it out the door.” I understand the perspective. We work in a world of constraints and the business needs to survive.

Management often says this but really mean “I look to my developers to tell me what critical things must be there in order for the business to derive benefit.” If we are being asked to deliver something with such low quality that the customer or the team will pay for it later then we must help management understand the cost of their decisions.

We are not looking for perfect code. Building software is a series of compromises and the developers who are writing it are the best informed to make the wisest decisions on which compromises to make.

We all want to be proud of our work but we also realize that being a perfectionist is often not desirable and we must find a middle ground. Sometimes we have to ship code with serious flaws but we should be aware when we do and make a case for cleaning it up later as good for the business’s ongoing investment in their software assets.

Published at DZone with permission of David Bernstein, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)