Design to last

Looking back at my career, the projects that have had the most impact are the projects that were not rewritten. It is unfortunately very common for projects to land and then 6 months, 1 or 2 years later to have it rewritten.

Exponential impact

Successful tech projects have this property that the growth curve is not linear but exponential. This leads to some non intuitive way to optimize for their success. Here's an example of two projects I've worked on.

Weekly npm downloads of two projects I've worked on

Work as an investment

In most jobs, if you do X amount of work, you generate Y amount of impact instantly. If you want to generate 2Y amount of impact, you need to do 2X amount of work. As soon as you stop working on the job, you stop generating impact.

With those kind of exponential growth projects, it doesn't work like this. At the beginning of the project, you are "investing" X amount of work into setting up the project. Then based on how well you did there, the project is going to generate an increasing amount of impact over time.

This is very similar to compound interest for personal money management. You invest initially and then you have to wait 20-30 years later to see real return on investment.

Difficult impact estimation

A big challenge with those kind of projects is that when you are working on it at the beginning, the absolute amount of value generated is small. So if you are judged based on a X work -> Y impact formula, you are going to have a tough time selling your work.

Trying to map your impact using the exponential formula is not easy either. Nothing can be exponential for ever, in reality it looks more like a S curve that flattens at some point. The challenge is that it's extremely difficult to predict when that flattening is going to happen to estimate the total impact generated.

Until the curve flattens, it's not possible to determine whether the current exponential growth will flatten at a low number or an extremely big one

The two strategies I've seen and done myself are:

  • Keep working on the project during the exponential growth. This way as time goes, you'll get more and more reward as the absolute impact of the project is getting higher.
  • Leave the project but use its successful aura to help get your next [job, team, project] and help getting credibility when talking to people.

Example of failure

When I worked on open sourcing React Native, I knew that having up to date API documentation was really important. I built a system that automatically generates the documentation based on the actual source code.

Unfortunately, this system, while it solved the problem, was complex to maintain and the value proposition was not clearly communicated. I don't know the history but someone removed this entire system, likely being praised for improving the codebase and maintenance.

And now, many years later, a similar system is being introduced again. Since the project is now much bigger, it is going to be significantly more difficult to achieve than the original version I built.

If you liked this article, you might be interested in my Twitter feed as well.
 
 

Related Posts

  • May 10, 2012 Generic Image Processing With Climb – 5th ELS (1)
    ELS Presentation | A Generic and Dynamic Approach to Image Processing | Chaining Operators & Component Trees | Property-based dispatch in functional languages Laurent Senta had the opportunity to go to the 5th European Lisp Symposium to present Climb, the project I've been […]
  • October 12, 2011 Intercept and alter <script> include (2)
    For a project, I want to transparently be able to intercept all the included javascript files, edit the AST and eval it. This way I can manipulate all the code of an application just by inserting a custom script. Hook the <script> tag insertion. Download the Javascript file […]
  • August 27, 2011 Start a technical blog, it’s worth it! (4)
    Lately, I've been advocating to all my student friends to start a blog. Here's an article with the most common questions answered :) What are the benefits? Being known as an expert. The majority of my blog posts are about advanced Javascript topics. As a result, I'm being tagged as […]
  • April 5, 2012 Climb – Property-based dispatch in functional languages (2)
    ELS Presentation | A Generic and Dynamic Approach to Image Processing | Chaining Operators & Component Trees | Property-based dispatch in functional languages This is the third (and last) presentation about my work on Climb at the LRDE. During the first one I tackled genericity […]
  • July 5, 2011 Climb – Chaining Operators & Component Trees (3)
    ELS Presentation | A Generic and Dynamic Approach to Image Processing | Chaining Operators & Component Trees | Property-based dispatch in functional languages During the last 6 months as part of the LRDE (EPITA Research & Development Lab), I've been working on Climb, a Common […]