Enjoy Chaos

Software always needs fixing. Always. As soon as the first line of code gets written, you’re already in maintenance mode. You may even call it development, but you’re really doing maintenance. You are always trying to fix something. When you add the second line, you need to make sure the first one still works as intended and the software still solves the problem it was built to solve.

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.

They say that you should be an entrepreneur even when you’re an employee, meaning that having an entrepreneurial state of mind is good for you (and your employer) even when you don’t somehow own the company.

And they are right.

Nonetheless, not all companies recognize that entrepreneurial employees are good for them. Some are afraid of them. Some just think that all they need are plain old nine-to-five card-punching employees and that those entrepreneurs would simply cause more headaches than needed.

It just takes a whole different kind of person to be a vanilla corporate employee than it takes to make a business-owning entrepreneur. Corporate recruiters know and recognize that. It is hard for a corporate employee to make it into full-time business owner, but in some companies it is even harder for an outside entrepreneur to get hired. It isn’t impossible, but it is much harder depending on the company (and position) you consider. Sometimes it just feels like it’s a one-way trip.

I remember once hearing someone saying (or writing, or I could be just making that up) that Bill Gates was able to build a multi-billion company around him, but wouldn’t be able to climb the corporate ladder in a big company like Microsoft. There’s just too much politics that problem-solving business types aren’t interested in. Sometimes I think people like him are able to build such companies exactly because they couldn’t climb the corporate ladder.

Eric Sink says that Git is the C of version control tools in the sense that it “is fast, hard-to-learn and it allows the developer to do things that are probably a bad idea.” Simply put, it is not a tool you should give to an idiot.

That doesn’t mean that you shouldn’t use it, it just means that you must be aware of the danger. Chainsaws are dangerous too, but there are times you do need one. You don’t handle it without the proper security measures. You may not even want to consider getting near a chainsaw, but instead resort to calling a professional when you need one.

But when it comes to version control tools we programmers are the professionals. There is no one else to call.

We shouldn’t be afraid to use the right tools for the job. This is analogous to the fear that people feel about dynamic languages. People think they are just too powerful and can be dangerous in the wrong hands. But it turns out that this isn’t really a valid point: almost anything can be dangerous in the wrong hands. The point is that you shouldn’t have idiots working with you. If you don’t trust your team to use a powerful tool because it would be too dangerous for them, you shouldn’t design a safer, more limited tool. You should get rid of the team itself. If your team is already able to shoot themselves in the foot with a handgun, you shouldn’t buy them a shotgun. You should find yourself another team.

Idiots always find a way to be idiots, even if you design all the safeguards that you can think of into their tools. This is just what they are. Our tools should be designed to make the awesomeness of awesome developers shine, not to hide the suckyness of the mediocre ones.

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.

No, you don’t need to read the title again, you are not mistaken. It really is a T instead of a D (or R, depending on where you come from). BTUF is the acronym for Big Testing Up Front. BTUF is basically what happens when people try to write all conceivable tests before starting to code. With the rise of Test-Driven Development this is an obviously ascending waterfall practice.

Testing is also designing. When you write the tests before the production code in good TDD style, what you essentially do is to design how the code will look from the outside. Sometimes it may be hard to resist the temptation to design everything before writing a single line of code, specially for those used to waterfall thinking. For those who can’t help doing it, here is some news from yesterday’s paper: it doesn’t work. Even though everybody minimally informed has already heard it, this message never gets said enough.

It doesn’t work because designing is infinitely better and easier when we can have fast feedback. Software development can easily be a high feedback activity. Architects need to wait for the construction team to finish the piece and film writers sometimes need to wait years for the shooting to finish, but programmers can just compile their programs. Giving up this feedback on purpose is not the smartest thing to do. Writing all tests for a piece of code before starting the code itself is no different than drawing rectangles and arrows describing it in full detail before trying to make the whole think work. The risk of over-engineering is the same because the code isn’t there to scream in agony.

The key to avoid BTUF is writing the tests that you can come up with before writing the code to make them green, but making sure not to think too much. You can wait to start writing the code after all tests are in place, but you don’t need and neither want to.

TDD has shown us that design isn’t made only of diagrams. In fact, we are designing all the time we are developing software. TDD is only one of many design techniques: one that uses tests. It may be a better tool than arrows and rectangles in some situations, but is still just an approach for design. BTUF is, therefore, just an special case of BDUF where tests are used to determine the design completely before writing a single line of code.

Enjoy Chaos is the English companion for the Portuguese blog Mergulhando no Caos. Sometimes you just feel that something sounds betters in English and this is why this blog got started. Some translations for my old texts will probably pop here from time to time, but I do intend to write some exclusive content for this blog. Sometimes the inspiration muse whispers in English and I don’t want to lose those opportunities.

Here I intend to talk about pretty much everything that interests, entertains and amuses me on the technology arena. I am a programmer and you should expect to find many articles here about my software development endeavours, but I will occasionally write about hardware and gadgets too.