2024 Public Training Schedule
December 9 – 12, 2024 – Agile Analysis and Design Patterns – Half-Day Sessions
2025 Public Training Schedule
January 14 – 17, 2025 – Agile Analysis and Design Patterns – Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- June 30, 2010 ( 2 comments )
- Rants
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.
{2 Comments }
Previous Post: « Who is Our Customer?
Next Post: Do You Believe in Coding Standards? »
Hi David,
Excellent post! This conflict seems to arise frequently in almost all software development organizations. I wrote a post along similar lines back in January http://ow.ly/25xAy
You may want to use the values exercise I outline in the post as a way to help communicate the cost of “Just getting it out the door”.
Let me know if you have any luck!
Hi Todd,
Thank you for the comment. I really like your post and I agree. Isn’t it odd how we put quality decisions in the hands of our customers? Since they are ultimately paying for the work they should have a say in some of the tradeoffs we face but, at the same time, they need to understand the impact of these decisions.
I don’t think home builders tell their clients that if they remove some of the support beams in a house they can finish construction sooner and lower the cost. I don’t want to have that kind of conversation with my clients. But in agile we want our clients to constantly check in with us and adjust their priorities. This is natural and is part of the discovery process of developing software.
I encourage my clients to change their priorities of what they want built but not how we build it. I always build with quality but only address the requirements at hand. This does not mean I’m a perfectionist when building software.
To me quality is like building codes for a home builder. I follow certain practices to ensure that what I’m building is robust. I reject the notion that quality takes longer or is unnecessary. The kind of quality standards I follow actually speed things up and definitely helps build software that does what it is supposed to. This is what I show developers and teams how to do in the training, coaching and consulting I offer.
David.