Hacking versus doing things ‘correctly’

Although in mainstream media hacking is considered as something bad, something criminals would do, hacking has really nothing to do with bad things. Hacking in software is about building a bazaar instead of building a cathedral (Raymond, 1999). Hacking is central to the idea of agile programming and the free software movement.

While building a cathedral is about planning things properly, the bazaar way is the shacky way of hacking things together. Being able to build something cheaply, quickly. The it-just-works approach.

Others counter this notion of hacking it together as something being unstable. In the long run, they argue, hacking will be more expensive. But think about it… how often have you worked on something great, something really complex, something you’ve tried to release perfectly, and a) how often have you succeeded in actually releasing something and b) how much better has it become through this careful process of discussing, planning and crafting - doing it the right way?

Think about all those buildings that went through this process of planning, calculating, drawing, and finally fixating in concrete, that had to be torn down after just a few decades in operation. In software terms decades are years.

Should you really worry about hacking something together when that something just runs for a few years, maybe never really succesfully (be realistic)? And then consider that the longer it takes to build something the less likely it is that you’re going to finish it (Fried & Heinemeier Hanson, 2010). If you’d had hacked it together you’d be able to release that something, test it… quite cheaply. Go hack. It’s allright. Better than releasing nothing.

Ps. if you’re really worried about the stability of some of your hacks, why don’t you make sure you test those automatically?
Ps2. yes, today I argued for exactly the opposite.