If we take a closer look, we’ll see that even the first line gets written to fix something: the fact that you don’t have anything to show to the customer or to experiment with yet. You write the first line to fix that problem. Being the good dedicated programmer that you are, you know that people don’t really have the slightest idea of what they need until they see something that they certainly don’t need. That is just the first thing that needs fixing and it’s all downhill from there. If you keep fixing stuff that is “broken” in your software, you will always have something to show or deliver when needed. Namely, that previous version without the fix that is admittedly broken for some definition of broken, but is also done for some other definition of done.

So the way to build something is to start with the most simple user need and move forward from there. The user cannot sign up for an account? Fix that! There is no a way to enter data? Fix that! Your website doesn’t talk to that related one that most of your users use? Fix that!

Repeat until you have a fairly usable solution and you’ll have successfully fixed a piece of software into existence. The goal here is not to cowboy code your way out of everything, but to have something working that can be shown to anyone interested at any given time. When you have something to fix, you have something to show, you have something to help people figure out what they don’t want.

Business apps programmers can’t make their code beautiful because most of the time they don’t really know what to build. Sure they need to study a lot about coding and master the latest coding techniques, but they don’t stand a chance if they don’t know what they’re building.

The real and hard work in software development is figuring out what the hell the customer needs, not programming the computer to solve it. If you want to use an waterfallish word, the hard work is figuring out the requirements. In fact the whole Agile thing is about getting the needs right. That’s why we strive to deliver early. That’s why we work iteratively. That’s why we value working software. After all, software is not working software unless the requirements are right.

By the way, working software is an interesting topic in itself. You can try to understand the customer needs using schematics, diagrams, use case documents or even with a cardboard poster hanging in the development team room.

Or you could use good old working software…

When the software is minimally ready — when it is at least working — customers can see what is does and ask for changes where needed. They can’t do that with use cases because they can’t see use cases working. It can even be worse: they can look at the schematics (that don’t work either) and think that it will work in a different way than what the team really meant.

Plain old software can be seen as a requirement gathering tool too. We fortunately are writing computer software, not building schematics. We don’t need to wait for the building to get done, we can run a compiler and our programs are ready to run. Civil engineers cannot tear their buildings apart and start all over again, so they invest a lot of time in getting the specs right before they start building. Programmers can destroy their buildings and rebuild them again as easily as saying make clean && make. Instead of wasting our time with dead documents, we can work with the real living thing. That’s why they call it software, exactly because it’s pretty easy to change. Not taking advantage from this flexibility is just dumb.

The logic goes pretty much like that. Code doesn’t matter because the most valuable work is the requirements work. Requirements work is really about figuring out customer needs. Figuring out customer needs is much easier when you have working software to show them. Working software needs code. Thus, code matters.

Well, code alone doesn’t actually matter, but it is your most valuable tool for understanding requirements.