Welcome back to my continuing Back to Basics series. This time I’ll be covering Working Software: Agile Manifesto Value #2. If this is your first look at the Back to Basics posts, or want a general overview of the Agile Manifesto and its principles, please check this post.

Working Software: Just As Simple As It Sounds

In Agile, we value working software. That sounds like a no-brainer, right?  Who doesn’t value working software? Taken out of context, this doesn’t really tell us much. So lets contextualize it. If we value working software, then we infer that we do not value software that doesn’t work. Taken to its logical conclusion, software is only valuable once it works, or in other words, once it can be used.

Now to the layperson, you might be tempted to take that to mean that software is only valuable once every single feature is complete. After all, how can you use software that’s not complete?  Let’s examine that. Take your favorite piece of software. For our example, let take a word processor like Microsoft Word.  Microsoft Word has loads and loads of features, some you might not even know existed (for example, Word can convert a table to a graph without any external software. Who needs Excel?). How many of those features do you actually use when you’re writing a document? Could Word be valuable, even if all you could do is type words, or type words and print? Sure it could, that’s why Notepad exists.

So what is “Non-Working” Software? Well, that’s a little bit harder of a concept. After all, code will generally run when executed, and a database exists once you create it, right? Here’s the “Tree Falling in the Forest” question for that: If a database exists, but nothing is connected to it, is it really working? What is more valuable, one table connected to an input form, or 100 tables connected to each other and nothing else?  All this is not even getting into testing, ensuring that your “working software” actually works like you think it should.

Comprehensive Documentation

Beyond the context I talked about above, the Agile Manifesto contextualizes this value in contrast to “Comprehensive Documentation”.  Let’s examine why.

It’s important to remember that the Agile Manifesto was not created in a bubble. At first, software projects were treated like every other kind of project: write out all the requirements into “Comprehensive Documentation”, and then complete each stage of creation as a discreet step, for example design then develop then test. There was only one problem with this. It didn’t work. Development took so much time to match the features, and when it couldn’t the documentation needed to be updated. Testing got pushed so far out, there was no time to actually develop fixes for bugs. Even if you did complete all the features you documented, there’s no guarantee what you created is useful, since you took a year to finish everything. The world can change in a blink of an eye, and while you were away building all that comprehensive documentation, Google came by and already did it faster and better.

Projects do not need to be documented up front. Some projects don’t need more documentation then commented code and a list of user stories. Agile says its always better to create what you need now than what you think you need someday, and that includes documentation.

Summing It Up

With Agile, we value something tangible that works, as opposed to a theory that might work. Even if your “working software” doesn’t end up being the real solution, the sooner you find out, the better.  Anything that is not real is still imagination, and its really hard to use imaginary software.

Like what I’m saying? Don’t like it at all? Leave me a (working) comment below!