Cloud Hosting

In Clean Architecture, Robert Martin adds some commentary to Kent Becks famous Make it work, make it right, make it fast quote:

First, make it work. You are out of business if it doesnt work.

Then make it right. Refactor the code so that you and others can understand and evolve it as needs change or are better understood.

Then make it fast. Refactor the code for needed performance.

One of my old teams did this so right. Another one did it so, so wrong

I used to work for a company that built a B2B SaaS product. Their old, monolithic, Java-based product was a cash cow, bringing in $15 million annually for eight straight years. They hired a new engineering director who promised to build a next-gen product that would take them even further using the latest tech (at the time, that meant Kubernetes solves all problems). He just needed 30 engineers and permission to do it as a complete rewrite.

The product was an engineering marvel. The director got the 30 engineers he wanted and they built and deployed 162 microservices (picoservices might be a better name) supporting everything from CAN-SPAM to a chatbot with some early NLP features.

There was only one problem: it didnt work.

After two years of development and $27 million spent on R&D, no customers could migrate from the Java monolith to the new system. Pages loaded in minutes. Events were stuck in queues for hours as calls fanned out and validated data.

The director was, unsurprisingly, let go. The project was written off as a total loss. After two years, the company returned to iterating on the Java monolith, a system they still use today.

There was another team I worked for that had a single driving principle: Delight the users. That core principle drove all our decisions, especially when building new features. We took user feedback, implemented it quickly, and shipped it in a few days.

We cared about clean architecture, passing tests, and scalable services. But our primary focus was a working product.

The result of this team was just that: a product that worked. We iterated on a great product, delighted users, and built a profitable system that continues to run ten years later. (You go, SyncTimes!)

Maybe its boring that there wasnt much drama about this project. But Boring is beautiful (credit to Ben "The Hosk" Hosking in Boring is Beautiful in Software Development, worth the read).

Originally posted here:

A tale of two engineering teams. Hi, this is Jacob with this weeks | by Jacob Bennett | The Atomic Engineer | Feb ... - Medium