on meta

Baking software

The hardest question I’ve never been able to answer to people who doesn’t write software but is part of the craft of writing software:

How is software developed?

This question unveils from closed questions which generally generate a lot of debate, such as:

  • Why will this take so long? (What? More than a month?)
  • How come this only takes an hour? (The exact same button took 2 weeks…)
  • Why do you think this is technical improvement important? (This doesn’t have any value to me.)
  • What is and why should I let you clean up technical debt?
  • Why is your hourly rate so high?

Those questions always come more often and frequently because they are less open-ended and in the heat of the moment, seem more appropriate, intuitive.

We basically press some keys for a period of time, adding some letters in a dark screen and something flourishes.

As someone who is more of a scientist than a politician, whenever I hear closed questions as above, I go one step back and think:

What is the root of the problem on those questions? The root for those is obviously the fact that you don’t see the code that displays the button. So unless you have the knowledge to make the button, you can’t have much clue about how much time it will take.

You can see a building being constructed, brick after brick. You know that behind that project exists a group of engineers and architects. They make a project and then follow its implementation. As soon as the building is finished, the engineers and architects need to do no more extra work, they move on, all posterior work is maintenance. Maintenance is done in a way that makes the building last the effects of time, gravity and nature. Very visual.

I’ve seen countless times the comparisons of Software Development with Civil Engineering, but with Software having big maintenance costs because the building is never really done. So, the need for “proper Software Engineering” is there. We learn this at University.

In our field, it’s very common to see people quit. My university class started with over 50 people, only 10 made it to the end in only 4 years. Of the 10, not many became Developers, perhaps 2 or 3. I think most of Civil Engineers generally end up creating buildings.

Not to forget the interesting fact is that there are many people who write good software with no Computer Science background. Would you live on the 99th floor of a 100-floor building projected by someone without a Diploma?

So, I don’t think it has anything to do with with Civil Engineering. Sorry. Almost all the concepts that Software Engineering tried to copy from Architecture or Civil Engineering are at best viewed as bad ideas nowadays: Waterfall model(project with big upfront planning), design patterns…

So I propose something else.

Writing software is more like cooking.

Do you cook? If so, you usually have to think what you want to cook for the birthday party of your friend. Let’s say you decide in a cake after a bit of thought. (the scope and expected outcome and looks of a feature)

You find that in your house you have the needed ingredients: flour, sugar, baking powder, chocolate powder, water.

Then the needed tools: a kitchen, oven, bowl. Should I mention that all those tools have to be clean?

So, in order to make a tasty cake, you need to make sure that everything is clean. In software, the same applies. Sometimes the kitchen is just so messed up that you can’t even see the ingredients. You need time to clean up things and maybe it wasn’t even you that left this mess – But it could also be you. Maybe you had to take the baked cake to your friend’s birthday party, it had more priority, you couldn’t skip his birthday right? (Deadlines).

So what about trying to bake it faster because you’ve wasted precious time cleaning the oven?

You know that the time is short, and you need to bake it at 350 degrees for 35 minutes. Your common sense doesn’t even raise the thought of baking it at 1000 degrees for 10 minutes in order to finish faster because you know you won’t get anything remotely looking like a cake. Same applies to software. Adding more people to a project or trying to do everything faster because of pressure will never work.

Also, the kind of cake you want is special. It’s still a cake, and while it’s baking, you remember you friend likes strawberry a lot. In order for your great friend to see that you remember this. You add it while it’s baking as decoration.

The time passes and the cake is finally baked. Now you can barely recognize the strawberries as it was in the top of the cake and think it’s a better idea to just remove it and accept that it’ll only be a chocolate cake.

Now you package it, so when driving to your friend’s house you make sure it’ll still like a cake when it arrives. You make sure it fits nicely in a part of your car that

He tells you how good it is and that you are great cooker and you celebrate with him his party.

Then you go back home and clean your kitchen so the next time you need desperately to cook a cake for another party, your kitchen has to look brand new.

You have to make sure everything is clean, see how much detail there is to the process of making the cake and how everything can go wrong in each step. We deal with this complexity daily, always baking a new cake which sometimes we barely know the recipe or have the right ingredients. This is exactly how a feature is developed.

To make the most remarkable cake we need a very clean kitchen, a great recipe, select the ingredients with carefully with love. Taking to your friend’s party burnt or turkey + chocolate cakes isn’t a great idea, perhaps it’s better to not make the cake at all.

Wrapping up

In software, we don’t have the recipe for the kind of cake we want to make. We make the recipe by trying many times to get different parts of the cake right and if the ingredients are expired, missing or the kitchen is dirty, it gets harder and harder.

In the very end, your friend only tastes the cake. All the ingredients, recipe, tidiness of the kitchen isn’t considered, but without all this carefully thought process, it wouldn’t be a cake.

There’s a great documentary(in Netflix!) called Jiro dreams of sushi. It’s about a Sushiman, a very famous and simple Japanese dish who is over 80 years old and still work on making the best sushi ever. His sushi is very expensive, over $300 for a seat. At first, this looks like an exaggeration, as the documentary progresses, you see how much effort and money is spent on getting the best fish, the right preparation, the best people(most of them quit)… that the price looks cheap and the thoughtfulness put into it could take a man to the moon.

Writing software is the same.

Remember the questions?

  • Why will this take so long? (What? More than a month?)
  • How come this only takes an hour? (The exact same button took 2 weeks…)
  • Why do you think this is technical improvement important? (This doesn’t have any value to me.)
  • What is and why should I let you clean up technical debt?
  • Why is your hourly rate so high?

And the more open, bigger question How is software developed?

The open, bigger question is partially answered, probably as good as you could without grasping software well. But the closed, more direct questions aren’t worth the time spent trying to answer them because the tiny and complex details of each of the steps are useless for the end product.

Generally, all you want is the cake, the byproduct. A competent programmer should be able to give rough estimations(which are estimations, not promises) or ask for time to see how much cleaning up is needed in order to bake the cake you want. Instead of letting your emotions flow high when hearing that something is going to take more than a month or needs continuous, infinite improvement… trust the programmer and accept reality. Maybe it’s worth to clean up the kitchen if you don’t have an idea of a different cake that could be made with the ingredients available.

People who can manage projects in a great manner are more rare and scarce than the software developers. They are the ones who really push the business, humanity, kitchen – everything forward. Not to mention they are a real pleasure to work with!

A half-baked cake is as bad as no cake in the mouth of the customer. It takes zero effort to not make a cake and it takes zero dollars to buy zero cakes. Pick your cakes carefully.