Product Development cycle

At the beginning I thought that only small companies had dead locks on the development cycle but after going through several companies, big and smalls, commercial and academical, I see that the problem is everywhere. It is a simple problem and most of the time with a simple solution, but very hard to change peoples’ minds about it. Big companies have big inertia but also have many people that can actually change things. On the other hand, small companies can easily make huge changes, but only if the owner wants to, what does not happens all the time.

The kind of dead lock I’m talking about is of those products that were born to be “just a hack” and become an important part of the company’s income or life cycle. It also happens when a team develop a solution when a particular technology was not available and they have to make it by their selves and it ends up being much worse than the current standard solution, but have to keep running. You can think of other scenarios but the end is the same, will you change it as is ? Create a new one from scratch ? Adapt it slowly to new technologies ? It may sound correct to choose the later, but some times it’s not that simple. It’s the big ball of mud!

Every company or group have it’s own set of tools and weird products, that’s pretty normal. The probem begins when one of those ugly duckling starts to make money. The investors easily think that it’s 100% profit once the product is up and running. Most of the time they do accept some portion of maintenance, but that cannot be more than 10% to 15%. So, why spend money on it when you can do other things ? Cool things you haven’t done yet, use the money you got from that product to build new tools, new products that will get as many money as you had with the first one! That’s where the dead lock begins.

On nature, economics and other dynamic realms the growth process is most of the time a log-lag-die process. It means that you have a stalled phase, where you spend as much money as you earn, or even more. Then, when it’s stable, the money you earn from it grows in a logarithmic scale, even if you put a linear or even constant effort to maintain it. It’s the havens of te investors!

After that, the product saturates and no matter how much effort you put on it, it’ll not grow any more. Also, it’s worse, if you stop putting effort on it, it’ll die, and worse, some times, very fast! There are many outcomes but for the sake of space I’ll only say two:

scenario #1:
– the log phase let people so happy that the team increase also exponentially. More than one person for the same purpose, based on the concept that “someone always have to be there, in case of failure”, and believe me, for ugly ducklings, there will always be a failure.

– log becomes lag, effort needs to be bigger, but it just don’t grow as “expected”. The team is huge, people are working 200% of their times but they can only explain 50% o their work and the other 150% come from context switch, wrong assignments, hacks on top of hacks, and other things.

– the product now is obsolete and the code is crap after crap. The seductive idea of re-writing from scratch is now on everyone’s head. The investors don’t like it but the product is paying the bills so the team decide to keep a 10% of maintenance and plan a whole new product, with everything they really wanted but couldn’t implement because o lack of time, incompatibility and the amount f hackish code they would have to change.

– sooner, rather than later, they figured out that the 10% they kept on maintenance is unrealistic given the amount of bugs so they decide to keep only to the serious blocking bugs. Interface bugs are discarded, work arounds are being written as comments to “solved bugs”. Months after they have decided to create a new product nothing is defined yet.

– the lag phase is dropping out, the product began to decrease profit. The investors are pressing the team but no one code on the old platform far too long and the amount of quirks they had to do on their 10% of bug fixes is so high that no one can fix anything anymore. Th only rational decision is to close the feature submission and start developing the new product. Funny but true, the new product will be more stable than the old one but will have half the features due to the shortage of time.

– while they develop the new tool, the profit is dropping, the team is reduced, the number of features is reduced even more. Many things that were calculated during the planning phase have to be re-think because of so many reductions, but the time to develop wasn’t counting on it. The project is delayed.

– After all delays, the final product is released, year later, with lots of hard coded stuff, half the features, a new fancy layout half as stable as the former and at that time dozens of other companies already have their own solutions, and your is just another on the market.

scenario #2:
– product is in log phase, money falling form sky. Instead of double your team you decide to spend some of that money defining the bottleneck of your application and rebuilding each component from scratch. As it’s only a component, it’s requirements and feature list are very limited and the development cycle is far simpler. Each new “undercover” release you do prolongs your log phase as more people can join without killing the servers.

– when the back end is ok you can spend time renewing the front end (if you have money you can do both at the same time, but beware, it’s not that simple).New visual features brings more users, what brings more money, what also prolongs your log phase.

– eventually your product will enter the lag phase, the world is not endless and new stuff show up all the time, you cannot expect your product will be top of the pops forever. But at that time, your product is fairly stable and usable and the amount of maintenance is almost zero, so all the money is profit and when the product dies, it just dies peacefully, using little hardware requirement, in heaven. If you do it well, you can also have a fan club and keep yor product running for the nostalgic.

– the lag phase yields clear money, your team can work on other products, projects, whatever they (and you) want to, things will continue to work if you leave them alone.

conclusions:

1st: Companies should never think of huge gains on software industry. This is less common today but still there are companies around that think if you cannot get the money straight away you shouldn’t even start.

2nd: one team develop one project at a time, even for small companies. You better develop one good product than 10 pieces of crap.

3rd: mature products can only pay a few other teams, this is where the profit comes. You should rely on profit from mature products and not for log-phase products, as that money is for paying the post-development of the product itself, and if you don’t use it that way, you’re very likely to end up with an ugly swan.

4th: all programs should be treated as production. few programs, no matter how simple and stupid they are will run much longer than you’d expect. There’s no thing such as “a quick hack”, specially on environments with the “keep it working” policy.

5th: don’t be afraid to refactor. You don’t have to follow XP since the beginning to be able to refactor your code, you can do it any time with any code.

Last, but not least, never be afraid to learn and to show people you were wrong. Better be wrong and learn than to be wrong and hide.

For further reference and a complete analysis, consider reading the Big Ball of Mud.