Saturday, 23 November 2013

How to kill (softly) a software project

1. Monolith.
Keep the whole code base as a one big stack. That way after few years no one will know how it exactly works. You can always try to hire more and more highly skilled developers to work on it (if you have enough money and there are still such people on the market), but most of their time will be spend on solving problems that were purely created by such design. Simply speaking, 80% of your money will go into preserving the current "state of art", not into new business features.
There is another problem, driven by complexity - dependency war, when feature A uses library L in a version v1, but module C used by feature B needs L v2. This is the case when you have a good dependency management system - otherwise they can go silently into your prod but later will need endless time to debug them.

2. Closed stack, NIH.
There should be an enormous effort to add a new Open Source library. Three levels of managers that have no dev-clue should agree. A procedure to get a new CPAN module should be such a pain in the ass that no one would like to do it again. Forget about cloned images, maven/sbt/capistrano/perlbrew/setuptools/gradle or system packaging for easier distribution on your servers. That way your money will be spend on rediscovering wheels again and again. This seems to be a common approach in many big companies with "secure programming" and "not invented here" paradigms. It is a quick way to kill any innovation like newer templates, better JSON handlers or just day to day improvements.

3. Always stay with the same database. Do not try to evaluate new versions, forget about all these crappy no-sql approaches. Who cares what Redis could be better than Memcache, that Mongo could do a better job that MySQL, that Cassandra could be better than your oldy-goody shared disk? Enough is enough.

Oh, crap. What is wrong with so many companies?

No comments: