Have you ever noticed that making code beautiful isn’t that hard once you know what it is supposed to do? When the problem is well defined, there is very little difficulty in changing the solution to be more elegant. Take the problem of sorting, for instance. There are all sorts of elegant solutions built over many years for sorting just because the problem is pretty simple and well understood. But try entering into the realm of business apps instead and you’ll see a lot of ugly code.
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.
0 Responses to “Code doesn’t matter”