Working Software

The Agile Manifesto says that working software is the primary measure of progress. What does that mean?

In fact, the Manifesto mentions working software at least three times, and refers to “early and continuous delivery of valuable software” as the way to attain our highest priority, satisfying the customer.

There have been some recent threads on Twitter touching on this subject. For my purposes here, I want to touch on two themes:

1. What exactly is “working software”?
2. Is working software really the best measure of progress.

TL;DR:

1. It depends on where you stand.
2. Yes, as far as I know, it is.

What Exactly is “Working Software”?

I decline to answer “exactly”, almost always, and certainly in this case. But there are some things I can say that are close to true. But it does depend on where you stand.

In general, we mean software which does what it was intended to do, reliably, with all the good properties we had in mind when we set out to get it. One might say it is “fit to purpose”. The thing is, the purpose changes as we look at the software from different angles.

End User

To the end user, working software helps them accomplish the job, whatever it is. The software doesn’t break, it is easy to use, it doesn’t get in the way. Quality, as always, is what you like.

Management

To the management of a company building software, working software is ideally in the hands of those users above. When the software is in development before release, as a measure of progress, working software is an incomplete but fully operational product. The only thing holding it back from being placed in the hands of users should be the absence of a few features that are important enough to wait for. Those features should be less valuable than all the features already built in.

Development Team

To the team developing the software, working software is the integrated, tested, fully operational version of the product that the team has most recently built. Most recently ideally means “a few minutes ago”, but depending on team skills might mean “as of last Friday” or “as built last night”. More immediate is always better.

Developer, Pair, Mob

Whether you’re developing solo, in pairs, or in a mob, working software means software that is integrated, tested, fully operational, as of a few minutes ago, or as of no more than a few minutes in the future.

Management

The difference here is little more than chronological chunking. Management may only want to ask “how’s progress” monthly. When we report on that monthly cycle, we can wave our hands, say things like “80% done with 90% of functionality designed”, or we can say “Here it is. Here’s the manual”. If we’re really good we might also say “Here are the reports from the three test users at ABC Corp, DEF Corp, and GHI Corp”.

Working software is real. It works. It can be tested. It can be verified. Questions about whether it does X are readily answered with “Yes” or “No”. The less ambiguity there is in our answers—our true answers—the closer to “working software” we are.

Team

During a development cycle, many teams have torn the software apart, broken a few things, left bits lying around the floor. These teams are advised to reassemble the software, back into an operational tested verifiable real product, no less frequently than a week or two. And this is far from ideal.

The teams who are really good at this stuff have a growing, improving version of the software, entirely fit to give to users, all the time. Day by day, hour by hour, even minute by minute, it gets better. Sam and Janet release their new feature at 10:45. The product is better now than it was at 9:30 when Jo and Dave released their feature. Each increment is working, fully ready to be handed to users if we wanted to, and it would be better than whatever they were handed a few minutes before.

Developers

The best development style we know today, whether working solo, in pairs, or in a mob, is to pick a very small thing that the system doesn’t as yet do, verify that it doesn’t do it, then make it do that thing, verifying again, and keeping the code at or above our standard of internal quality.

How small should that thing be? Tiny. Smaller than that. No, smaller still.

For me, if I work for more than 20 minutes without a verified working new step, I am almost certainly in trouble. Now, often I go ahead and work for an hour or more, and finally get back to working software. If I were more wise, my code would shout “stand back” and revert every 20 or 30 minutes.¹

Software development, my colleagues and I generally find, goes best when we make very small, tested, verified steps from working, quickly through not working, and back to working.

This is not easy to do. It requires practice to build up skill. You can see my attempts in the over 100 articles that now make up my Codea development of the arcade games of Asteroids and Space Invaders. In those articles, you’ll see that I almost always manage to get a visible slice of a feature within the two hours I allot for programming and writing the article. At my best², you’ll see me get things done in a few minutes.

At my worst, you’ll see me confused, depressed, questioning my existence. You’ll see me revert a whole morning’s work. Then you’ll see me do it again, this time in smaller steps, more nearly working at every moment in time.

And you know what’s best? There are a couple of people out there somewhere who actually read those articles and try the game. There’s nothing better than hearing from them about what works for them, and what isn’t there yet. Software, getting better and better but always working (or nearly so), in the hands of users. Sweet.

Bottom Line

Working software is best when it’s in the hands of its users. Along the way in its creation, we may show it to management monthly, weekly, or on demand. Within the team, we keep it working, and improving, day by day, hour by hour, minute by minute. Working sofware, all the time.

There may be a better measure of progress, but if there is, I don’t know what it is.