Report: Adopting Lean Development Principles

During the previous two months, the engineering team had to re-evaluate a lot its priorities, we had so much to do, and all of it was important, but we needed to deliver some faster than other.

Having mostly worked on the new version of the Digital Assembly Line, we were looking to first stabilize our stack and have all the services sit in their place perfectly, and then start taking on features one by one.

However, as the month of July has arrived, we decided that this was no longer the way we are going to proceed.

Initially, we were building something like this:

A typical Microservices architecture that we’ll event-source as to guarantee a clean way of keeping all parties in sync.

However, we had to build so many things we do not need immediately just to stabilize the whole thing, which in fact has made delivering what we are actually in need of right now to be delayed.

Lean Development

The new of version of the Digital Assembly Line is critical to our business success, so we had to deliver as soon as possible.

The Principles of the Lean Development Methodology are quite simple, and they revolve around building quality stable products, and delivering them fast while doing so as an integrated team, and they sum up to this list:

1- Eliminate Waste ( )
2- Build Quality In (
✔️ )
3- Create Knowledge (
️️✔️ )
4- Defer Commitment (
❌ )
5- Deliver Fast ( ~ )
6- Respect People (
️️️️️️️️✔️ )
7- Optimize the Whole (
✔️ )

Those principles are somewhat universal to the Agile Methodologies, and we’ve been using some of them such as giving a great care to code quality during our reviews, or such as Pair Programming or such as providing meaningful bigger scope refactors to fix bugs instead of hot and dirty fixes.

However, I believe that our desire to build a stable and quality product has blinded us towards the reality of what we need, and when we need it. So what ended up happening, is that we reserved developers for projects like metrics and a fully dedicated business logic service, which somewhat affected our ability to deliver fast. We would have maintained a good pace and delivered our fancy architecture that works well! However we would have delivered a whole bunch of feature that no one would need, yet. How UN-AGILE and WATERFALL-ISH

Decisions: Going fully LEAN

As soon as we’ve realized what we are doing, we decided to first ship a small BETA that comes with only the requested features, and deprecate the rest temporarily until needed.

So we’ve frozen the development of the metrics service, the emailing service and the business logic service, and we have decided to use the simple combination of an authentication service, a frontend app and a RESTful backend API.

Other than deprecating the unnecessary, we also knew that our current data model would dramatically change as we go.

So in order to guarantee that our data model changes will not cause us big and painful migrations in the future, we decided to disguise all of our relationships as many-to-many relationships while (almost) maintaining the cardinals, so that a one to many relationship remains almost the same except that the relations are established through a join table, in an effort to separate data from relations, until we are 100% sure of them.

Since we use Sequelize, we have written the following little helper to acheive this:

const joinAsHasMany = (modelA: Model, modelB: Model, { through }: {  through: string }): Model => {
  const joinModel = sequelize.define(through, {})
  modelA.belongsToMany(modelB, {
   through: joinModel,
   as: pluralize(
  modelB.belongsToMany(modelA, {
   through: joinModel,
  return joinModel

And we use it like the following:

joinAsHasMany(PostModel, CommentModel, 'CommentsToPosts')


1- Eliminate Waste ( ✔️ )
2- Build Quality In ( ✔️ )
3- Create Knowledge ( ️️✔️ )
4- Defer Commitment (✔️)
5- Deliver Fast ( ✔️ )
6- Respect People ( ️️️️️️️️✔️ )
7- Optimize the Whole ( ✔️ )

Now, with our newly complete principles’ list that we actively try to adhere by, not only we’ll work hard to satisfy clients, but actually they’ll be so, and in time.

Like what you read? Give Hamza Ouaghad a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.