Done is better than perfect -

Done is better than perfect

A few days ago, I watched an excellent talk by Erik Meijer called “The hacker way“. In a nutshell, he presented an opposite approach to Agile called Hacker Way which is successfully used by Facebook. The idea is very simple – continuous improvement and iteration. Instead of hours of planning and discussing whether something is possible to implement, just try to prototype this because it will probably take less time than plenty different meetings. And what if you’ll fail? First, you know why but you also got some new knowledge and experience which in this industry is priceless. Going back to Erik’s presentation, when he introduced the above approach he showed some kind of Facebook’s manifesto about that. There was a sentence which gave me food for thought

We have the words “Done is better than perfect” painted on our walls to remind ourselves to always keep shipping.

I started thinking about it and quickly realized that many developers (including me) are trapped inside this “perfect approach”. When new project starts, almost immediately everybody start discussing the architecture, technology, and fancy new thing they are going to use. The typical talk looks like this:


  • Developer A: Ok, so how about the architecture? Is N-layer fine?
  • Developer B: Naaah, we did that last time. How about the microservices? They imply lots of benefits like domain separation, location transparency, independent deploying and much more!
  • Developer A: That’s a great idea! But to make it easier to deploy, we need Docker and something for orchestrating the containers! Also, we need some Discover Service? How about Consul or Eureka?
  • Developer C: Yep we need some of them. Also, remember that we need to use NoSQL since relational databases are not easy to scale!
  • Developer A: Yeeeah, MongoDB or Casandra would be handy. Ohhh, and we’ll use Redis for caching!


And that’s just the beginning. We’ll to make it clear, I don’t claim that all the above stuff is unnecessary and we shouldn’t use that. But it’s very common that we try to create “perfect system” by introducing as many technologies/approaches as possible and then try to make it work for two months instead of focusing on our main job – creating a product for a client. And below you can read two, different stories about a developer who failed just because of that.
It was me.


Story #1 – Recruitment process

Last year I seriously considered changing my job. About June I applied to one of most recognizable companies in Poland. After an interview, I was asked to do some coding task just to verify my coding style and knowledge in general. The task was pretty straightforward – implement Google Calendar. I got one week to do it, and I thought that would be quite easy. Almost immediately I started working on this but soon after some “great idea” popped in my mind. “If they looking for best software developers, I cannot do basic stuff like N-layer architecture. I need something more!”. Yeah, and that’s what I did. Couple weeks before this story I had discovered the CQRS and Event Sourcing and I had fallen in love almost instantly. That was it! CQRS/ES would be my secret weapon to win. The problem was, that I had never introduced that into my project before. So, for almost the entire week I struggled with my code and tried to do as much as possible. The result? When it was time to send the project I finished… my backend architecture. None of the business requirements were even touched. I had neither domain nor frontend app. Well, at least the code compiled. When I sent the link to my GitHub I thought that maybe the would appreciate my approach even though I didn’t complete my task. But soon after the reply came:

(…) I really appreciate your approach which seems to be very interesting and suits the domain, but unfortunately, you didn’t do what I asked for (…)

So basically my secret weapon turned out to became nail into the coffin.


Story #2 – Get noticed 2017

This year I participated again in the Polish programming competition called “Get noticed”. The idea is that each one has to create an open source project and work on it for three months. Besides coding, you also need to blog about that twice a week. Last year I was really lucky to get into final 16 developers, so I thought that in order to win this year I need something special. I wanted to create quite a simple project but with lots of great technologies including Docker, Neo4j, Nancy, Microservices, Aurelia. The problem was that I most of the above technologies I knew only theoretically, so I needed to learn them all and introduce into my project one by one. As you probably expect the result was quite similar to the first story. After three months I ended up with the architecture which wasn’t even completed and none of the business requirements were fulfilled. At this point, I want to present an opposite approach by Piotr Gankiewicz who won Get Noticed 2016. He worked on the project for monitoring .NET Core apps called Warden. Now the reason he won was that he actually finished his job. Not only the code but he also created:

  • NuGet packages
  • simple administration panel for users
  • simple project site with links to the Github and descriptions about the Warden
  • screencast where he walked through Warden’s functionalities

He destroyed everybody simply because only a few participants actually finished their projects, but even though none of them could compare to him because of one reason. He created a complete project which was not just the code. And what Piotr did after he won? He blogged about introducing microservices into Warden.



I hope you see the difference. I think that sometimes we forget why we actually programming. We are not paid to do perfect solutions with ideal architecture and tons of additional libraries. We code because a client wanted to make his idea real. He wants a product, not the architecture. So, if someone asks you to create a very simple web app for grocery store don’t try to make it scalable and available for 1 000 000 users. Don’t try to put everything you’ve just learned because it’s “modern way of doing apps”. Start with some MVP and if the client will need something more, you can easily add the code which will solve the problems. Don’t try to satisfy the requirements that simply don’t exist.

Maybe that’s what defines an experienced developer. Ability to think about code but first of all – about the product. If so, I’m still a noob.

You may also like...