Minimum Effective Dose in Software Engineering
The guy that almost slapped Arnold Schwarzenegger
It was a lazy Saturday when I was sitting outside, reading Tim Feriss’s “4 Hour Body” (I ate too much ice cream at the time and gained quite a few pounds, it’s a great book for handling the issue). Quite in the beginning of the book I came across a very simple, yet important principle called Minimum Effective Dose (MED).
Although originally from pharmacology, the term was used by a rather angry (and funny) gentleman named Arthur Jones. He once grubbed Arnold Schwarzenegger by the shirt and threatened him to shut up, that is according to his protege Dr. Ellington Darden, PhD.
Arthur was an inventor in the field of Sports Science and Training and believed Schwarzenegger’s school of thought was wrong. He believed that in order to reach optimal results there is no reason to train more than once or twice per week, as opposed to Arnold’s protocols, which mostly involved 6 day workouts.
Minimum Effective Dose simply means “The smallest dose that will produce the desired outcome”.
The premise is quite simple — there is no point in exhausting any more resources than necessary to accomplish a task. For example, if you want to boil water then there is no need to heat it to more than 100 degrees celsius, 100 is just enough.
MED & Software
Although MED originated in the field of Pharmacology, I could immediately notice many similarities to the world of software, especially since developers tend to over-engineer a lot (it’s fun!).
In my mind, a more effective approach for developers would be adapting a more business oriented mindset. Whenever you are given a task try to understand how does it affect the business? If you don’t understand that, insist on getting a clarification from the PM / Team Leader. Otherwise, you might end up spending a lot of time over-engineering and adding a really small amount of value to the business.
Then, when confronted with the following question, “How much depth should I approach this development problem with?”, you should try to measure the impact on the business of each possible “implementation” plan. That way, you will have a rough understanding of the trade-offs.
Once you have understood the trade-offs, try to converge to the optimal implementation that achieves the exact business goal in mind. That solution is akin to the Minimum Effective Dose for that particular problem. Now let’s look at a few common examples where we might apply this philosophy.
Refactoring
You are in flow, coding away at a recent task that was estimated as medium, let’s say no more than 4 work days. You come across an old code that is not optimal for the new feature and will require an adjustment. Now you have two choices:
- Put a ‘band aid’ other the problem and avoid the big refactor
- You come up with a better design and refactor the entire component, it’ll take you another four days
Which option is better? Well, judging by the MED philosophy it is obvious that option #1 is better and in my mind it generally is.
Now hold your horses, I’m not saying to not ever do a big refactoring task. I am saying however that such tasks should not be done ‘by the way’ but rather should be done deliberately in case the business demands such a refactor in order to support upcoming features, improve system stability, resolve a development bottleneck and it fits the project schedule.
Testing
Testing is basically a tool for risk mitigation and risk management. Having a good test suite and CI helps the business move faster without breaking things. So obviously testing is important, but what is that so-called optimal test suite?
Let’s take for example a microservices based architecture which has a lot of business logic. Is it wise to write unit tests for each and every class or are we better of investing in Component Tests? There is no definitive answer and it is very dependent on the particular case. But once again, the guiding thought is What is the MED? If we can mitigate 90% of the risk by writing component tests and some E2E tests then great, we don’t need to invest any more time in testing than necessary.
Take Home Message
Whenever you try to figure out the optimal level of complexity of a given task ask yourself first — what business goal am I trying to achieve and hence what is the Minimal Effective Dose of development / testing / engineering / monitoring that is needed?
I firmly believe that adopting such an approach will make you and your organisation much more productive and a higher percentage of your work will actually affect the business positively.
