Hara-Kiri from Engineering (Best?) Practices :: Future.works 2020

Last Wednesday, on the 29th of April, I gave my first “virtual”/”remote” talk of my life. It is definitely very different from speaking in front of a “live audience” but taking in consideration the current situation (i.e. covid-19) it was pretty much following the saying “the art of the possible”. Congrats to Future.works for organising a tech week and proving that it is possible to share knowledge and to foster a sense of community even in a less positive moment of the human kind.

The conference had fabulous speakers as you can see by yourself in the event’s agenda.

My talk was called “Hara-Kiri from Engineering (Best?) Practices and you can see the intro/abstract here. The subject is around engineering practices that although are considered best practices, they also have pitfalls that you should watch-out for.

Here are the key take-aways from the talk:

  • Tech Debt shouldn’t pile up nor be fully paid. It should be managed;
  • Bus Factor should never be 1 but shouldn’t be huge too. It should be in the sweet spot;
  • Squads are a great concept but are a challenge in broad/deep architectures. The Squads’ depth is key for success;
  • It’s easy to get lost in resiliency, availability, and scalability work. Your systems should be dimensioned for your near future reality;
  • Code coverage is a great metric to keep track of. You can have 100% code coverage and still have bugs in your code;
  • Being Agile is not about (blindly) following a process. Agility is the ability to quickly gather and act upon feedback;
  • It’s easy to fall into the trap of adopting complex, oversized approaches. You should favor simple and elegant solutions with your near future in mind;
  • It’s easy to find “flaws” in others’ solutions (you find what you look for). Using existing solutions (e.g. open source, SaaS) accelerates time to market;
  • Loosely coupled services are great to scale but not brilliant to start with. Make sure you know the effort and cost of using them right off the bat;
  • Adopting a new coding language shouldn’t be a light-hearted decision. Usually architecture solves problems not coding languages;
  • Remember that the code you write today is legacy tomorrow. “Legacy” is usually what pays our salaries;
  • Pull/Merge Requests are great guardrails but it adds a step on your flow. It enables feedback and knowledge sharing if taken seriously;
  • It is normal to be risk averse and avoid deploying code on certain occasions. You should strive to deploy at any moment, ideally multiple times a day.

If you are interesting in seeing the slides you can see them here.

And last but not least here is the video if you would like to watch the talk:

See you soon!