Software over crap!
Lets begin this post with a rant: I really really hate it if people try to turn agile principles against the customer. The mission: Mask laziness by gaming the system.
The sort of situations I talk about look like this:
A: »Do we have to refactor this code? It’s really ugly and may or may not break somewhere in the future.«
Variant 1:
B: »Don’t bother with this, the Product Owner didn’t say anything about quality.«
Variant 2:
B: »Let’s ask the PO! PO, what is better quality worth to you? Prioritize! You can have more features or quality for the ones we already implemented.«
Oh yeah? It’s unfair and plain nonsense. Don’t get me wrong here: There are cases where bargaining over different qualities of service (QoS) has its right and is essential. But most of the time it hasn’t and isn’t. Especially if the code implemented is brand-new.
In all agile methodologies I know you promise the PO to deliver a baseline of quality from the start. It should be clear that »just getting things done« in guerilla combat mode is not enough. As a member of an agile team I implicitely promise to do things like e.g.:
- Planning the architecture
- Weighing my options
- Communicate
- Deliver the best code I can
- Test it
- …
without asking the customer every time: »What is it worth to you?«. Cope with it: If you don’t consider this activities as included and mandatory a priori you are not an exceptional doer churning out code like the Chuck Norris of development. You are just lazy.
From the perspective of the customer this behavior looks like an eternal loop of terror:
- Deliver crap.
- Whine over how you need a whole full-time month to remove technical debt.
- GOTO 1
The Manifesto for Software Craftmanship explicitely addresses this by postulating to commit to the following principles:
As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:
- Not only working software, but also well-crafted software
- Not only responding to change, but also steadily adding value
- Not only individuals and interactions, but also a community of professionals
- Not only customer collaboration,but also productive partnerships
That is, in pursuit of the items on the left we have found the items on the right to be indispensable.
© 2009, the undersigned. this statement may be freely copied in any form, but only in its entirety through this notice.
Bravo. Software should be seen as a craft. Get over it: Every time we deliver crappy code and apologize with »I had no time to plan!«, »The PO didn’t want quality!«, »You wanted results: you got it!«, we already lost the cooperative game. Why? Because of two things:
- What the PO asks you to do is to implement her ideas as simple as possible (YAGNI, KISS) but not simpler. What this minimal effort looks like is up to you and can only be judged by you. The PO can’t know this!
- If there really is a trade-off between time and quality we should have presented the PO the options beforehand. If she doesn’t seem to care: just don’t commit to it! It’s all about nuts-in-advance versus whining-after.
FTW: Yes I’m an craftsman, too.
If you are interested in more views on the topic be sure to check out this InfoQ article.

(All comments are moderated before they appear on the site.)