Broken Software
I sometimes hear the agile manifesto being criticized for focusing on “just working software”. It’s said that working software is not enough, that we need to reach further. I agree that we need change, but not in the wording.
If your definition of working software is “if it compiles, ship it”, then the manifesto’s words won’t seem like they change much. For you, the manifesto sounds like business as usual.
Twelve years after first reading it, the agile manifesto still doesn’t sound like business as usual to my ears.
Here’s the thing. I really like software. Really. I always have, ever since I used my first computers as a small kid. I guess computers and software filled a spot for me.
I don’t like all software. I like software that does its job and is a pleasure to use. I’m on a continuous quest to find more software like that, but many of the apps I try suck.
It’s not working software if it doesn’t work for me. Then it’s broken software.
As a user, I’m not content with software that works in the sense that “all functions are there, but that’s about it”. If it does the job, but is a pain to use, I don’t think of it as working software. I may even come to hate it, because now I know that the software could have worked, but its creators didn’t care enough to make it lovely to use.
When developers lack a passion for the user, the result can never be working software. Instead, we get broken software. Broken software is not working software.
For me, the problem is not the expression “working software”. That makes perfect sense. The problem is that some software makers still have a broken definition of what working means.
Comments
Hi there, Great post, I see your point completely. I also criticized the "Working software" bit of the manifesto in my post (http://contextdrivenagility.com/2012/03/29/working-software-isnt-enough-agile-principle-7/) but I've had more time to think about it since then... My biggest problem with this statement is the implication that the primary measure of success is productivity. We have product teams, and product owners. We do product development. All of this can imply that everything of value that can be done by a software company involves producing a greater volume of software. Software that exists is expensive, it has carrying costs. It has to be maintained. If we moved the focus to delighting users and producing business value then we might realize what is needed instead of product owners are problem owners, or hypothesis owners. Who's trying to work out what software /not/ to build in this agile environment? Who's deleting wasteful code that doesn't work but still exists. What about low-value legacy features that reduce an organization's ability to be effective. The team's well being is also vitally important to a business' success. Is someone ensuring that a sustainable pace is being achieved? How do we know our workforce is happy, learning and growing? These are all important and not encompassed in "working software". While I agree with your post about what "working software" means and that many who criticize the wording are missing this distinction, I also think working software might not always be the best primary measure of success. Thanks for the thoughtful post. :-)