Perfect product vs progressive releases

Even for the perfect product strategy you still need to iterate, you just iterate in secret. Taking Apple as an example of the perfect product strategy, and the first iphone as that product. They were iterating and testing that product for years inside of Apple, in secret, before releasing it to the public.

The difference between the strategies is therefore not how you build, because you always build iteratively. Instead it is how you gather feedback on each iteration: secretly and in-house, or publicly from a shipping product.

Building in secret risks having a competitor swoop in before you and corner the market. Building in public risks having competitors show up because they are interested in your market. Both strategies carry competitive risk. The determining factor is not the user base, it is the presence of competitors. If there are already competitors in the market, you’re better off working in public and trying to build awareness for your product. If there are no competitors yet because you’ve discovered a new market, it may be sensible to work in secret.

Finally, a product is more than a collection of features. Again taking Apple as an example, what makes them wildly profitable is not that their products have more features or have those features first, because they usually have less features and ship them later, but that they put more effort in executing well on the features they do have. If you execute really well you can win market share even when competitors already have all your features and more. Especially in the enterprise and small business space there is an enormous amount of terrible software with a gazillion features, and you can often win customers by building a subset but doing it better.

Going to expand on the comment about the Lean Startup.

As others have stated every successful piece of technology will have been iterated and improved on; it’s quite a good indicator of success. If additional investment is being in the product then it’s considered valuable.

Any software system that hasn’t been iterated on it probably has been around forever or it is not good and people are making do with it until something else comes along.

The book called Lean Startup is about iterating the business just like technology; the lessons it teaches apply equally well to software as it does to business. At it’s heart it demonstrates the value in being able to change quickly to market forces. This is exactly what software needs to do; some of the software industry has recognized that reuse isn’t the golden fleece of development; it’s the ability to replace, to adapt, to pivot. The book is interesting, it’s a business book shaped by software practices.

Perfection.

Now, that is an interesting concept.

What if the question changed; what if we consider iteration as a process of continuous improvement then the question might have been, is perfection in software an achievable goal?

The answer to that is probably no; however, it does raise questions about what aspects of the software should we believe perfection is achievable? Just because it’s not a possible concept doesn’t mean it’s not useful one. Domain Driven Design is a software engineering approach that brings business and development together. It introduces the concept of a Core Domain, the value the software has to the business customers; the reason why you are developing the software and not buying it. Domain Driven Design doesn’t advocate perfection but it does recommend the opposite, good enough, for other domains needed by the software. For example, if the software schedules meetings then should it perfect the code that sends emails or the code that resolves conflicts in peoples schedules.

The point is software should not be considered a whole but the sum of it’s parts. Optimizing each part does not optimise the whole. Perfection is not achievable, but if it were, it should only be achieved in the core parts of the system. The decision to release should be based on the quality of those core parts.

There is another book that might help called Release It; haven’t read it, but heard it is good.

Finally, the business model is important to this discussion. That dictates how money is made. Think of Windows and all the blue screens of death that happened for probably a decade. Poor quality. The partnership with Intel and the partnership with hardware vendors producing drivers, plus the pre-installation of Windows on home computers, and also the relationship with the gaming industry. Business model made a lot of money from software of questionable quality.

Hope that added to the discussion. Happy coding.

No, you can’t compromise perfection and have it still be perfection.

But in almost all cases the only possible approach is iterative releases.

The reason is you simply don’t know what you want until you have it. Getting market feed back is part of the process