Product Management: Practice lazy start

On occasions I get a question like this from developers.

Shouldn't we do this the right way the first time?  What do you say to writing purpose-built code instead of extending existing implementation?

My response to the question is almost always no.  That's because of two things are true when building a brand new feature:

1. No one knows whether feature will stick.
2. We are building the feature based on our best guesses.

Despite the best intention, no one knows whether the new feature will become popular.  There are a lot of factors that determine the feature success.  Some are within the product management and engineering team's control.  But as much as PMs hate to admit, there are a lot of luck involved in hitting the right market with the right feature at the right time.  Having the functionality alone is not enough.  The feature should be adopted by large enough user base to make the continued development economical.  And no one knows whether your feature has the magic combination at the right time.

In face of this uncertainty, only logical thing to do is to take incremental steps.  What you want to do is to make the minimum investment possible to test the feature idea.  If you see some promising signs, then you up the ante to take on a bit more risk.  At each step, you are finding a bit more about how users are reacting to the feature, and get that much more information about what kind of feature will become a hit.

So it makes a little sense to trying to get it right the first time.  It's like saying "hey, I know we just sat down at this poker table, but I have a good feeling. Let's bet all we plan to bet after seeing the flop."

But there are other reasons to be weary of up-front investment.  That's because up-front investment usually means writing more code. The more code developer writes, the bigger code that needs to be maintained, the more likely we'll end up with specialized functions.  Instead of reusing the existing routines to piece together the feature, developers now starts anticipating problem in the future and starts solving them.

This is bad because it is not only highly likely wasted effort, but it also increases the complexity of code, hence increasing the technical debt by introducing likely dead code.

So whenever you hear of future-proofing, architecting the right design, getting it right the first time when feature is getting implemented, be skeptical.  Make sure everyone in the team understands the high likelihood of failure, and calibrate everyone's expectation so that no one over-invests in the initial feature launch.

Practice lazy start.  Solve the problem when you have to.  Until then, test the feature idea fast by reusing the existing building blocks.

Some argue sloth is an essential quality for a good developer.
It encourages code reuse instead of rewrite.
Of course copy-paste does not count.
Source: http://dilbert.com/strips/comic/2008-03-04/