Sharing ideas on technologies and life

Product Management: when less is more [4/n]

Fact: a product has a lifecycle, which means that it will, at some point, eventually, be obsolete.

When designing a system, you should naturally check the existing technologies and use them. This way, you can:

focus on what makes your product unique and different

benefits from other people mistakes and successes

avoid ending up with reinventing the wheel

Keep in mind that at some point, and despite your best efforts, your choices will become obsolete. Additionally, the competition will catch up at some point. The less is more philosophy applies here as some of you features, code, etc. will be available on a new language, library, etc. Thus, you can just use them.

Remember when you wanted to create a REST API 5 years ago? a simple XML parser and checker 10 years ago? A web server 15 years ago?

Don’t get me wrong, at some point you have to make decisions, finish your development and ship your product (unfortunately sometime it’s a JFS) but when spend time improving your system or process, you end up gaining time actually. A real-life example based on a real facts:

A feature development takes 5 days

A reviewer spend 1 day checking that it does not affect the rest of the system, and 1/2 reformatting the code.

A tester spends 1/2 for non-regression

The build system takes up to 1 day

3 days, after that the feature is done, the build system fails because of a library version incompatibility. So, you go back to 1 to check it and then start over.

Now, imagine that you have 10 features to develop.

You can guess that 2 and 3 will be repeated for each feature. I let you do the math for how long will it take.

Now, imagine that you can have static analyzer for code coverage, tools for code formatting, automatic testing framework .. A lot of them are actually free, but putting them together will take you 10 days. Someone might say: HELL NO!

Again, I let you do the math.

Now, just imagine that you have all that in place, how many more features could you have done?

Short answer: while spending time on improvement, you actually ended up making room for about 20% more features.

So it’s only logical to always keep room, and most of all, time, for improvements.