Do it

The other day I watched Ricardo Baeza’s talk and at one point he gives some advice that has served him well in his career, such as “don’t make plans, don’t project yourselves… if I had imagined what I was going to do with my life I wouldn’t be here right now… because when you project yourself you do it onto something smaller, because you think that way you’ll make it. Because you don’t dare set yourself a very big goal, because what happens if I don’t reach that goal, will I be frustrated? No”.

He also advises being flexible, reinventing yourself. Accepting that mistakes are often not mistakes at all, just a lack of information, or decisions made with the information you had at the time.

But the advice Ricardo Baeza considers most important is: “don’t think about what you have to do, do it!”. How much time have we wasted thinking about what we have to do, about how to do it, when we could have spent all that time doing what we were supposed to?

Do it

When you build software, “do it” means delivering the product, or service, on the date you committed to. As the saying goes: Ship It. Deliver the damn application!

In the words of Jeff Attwood: “Version 1 Sucks, But Ship It Anyway”.

Every project is plagued with difficulties:

• The schedule was too aggressive and too short. We need more time!
• We ran into unforeseen technical problems that forced us to make compromises we are not comfortable with.
• We had the wrong design, and need to change it in the middle of development.
• Our team experienced internal friction between its members that we didn’t anticipate.
• The best programmers leave the team because they found a better-paying offer.
• The customers didn’t answer our requests for information in time.
• The infrastructure people and the development people weren’t communicating properly.
• The vendors’ response time wasn’t what they originally promised.
• We used a technology that was discontinued halfway through the project.

The problems number in the thousands. The email record leaves a trail of hundreds of messages a day, and several gigabytes of discussions, clarifications, documents, screens, reports, hundreds of revisions to the Gantt chart, a long list of bugs and fixes.

“At the end of the development cycle, you end up with software that is a pale shadow of the shining, glorious monument to software engineering that you envisioned when you started.”

And the temptation to throw in the towel, as Attwood says, is great, and asking for more time to finish what is missing is the biggest mistake you could make, because real developers ship!

There are many mistakes you still know nothing about, but how are you going to face them if you haven’t shipped the software yet? It is not the best product, you may even consider it the worst service you have ever delivered, but sometimes worse is better.

A piece of software, a service that is used, that is delivered, that has been released to its users, is better than one that suffers its umpteenth rescheduling in order to deliver a “quality product”.

All of this because of a milestone my team and I reached, precisely today. It is a service that went into operation on the date we committed to. We delivered it, we did it. There are still things missing, we have our list of bugs and pending items, we will keep working for months, but the essentials are there.

We shipped it! The users are already using it, the service is live. We delivered, we did it, a working system. We made it, and it feels good :smile: