How not to build a castle on a swamp

From time to time, programmers sail into uncharted waters - the business and clients agree to give them some time to build a prototype and evaluate a new technology, or explore ways to get something done. A month or so later, after a software scaffolding is built to show how something can be done, one of the worst examples of corporate insanity happens - almost certainly. Some brilliant mind thinks of a way to save money or deliver earlier by patching up and shipping the prototype.

I have never seen that produce any good - not once. By ‘good’, I mean a better product, delivered faster than if the prototype was thrown away. Yet, no amount of convincing or logic seems to be effective against the promise of earlier delivery. The whole idea of prototyping is to test potential solutions, which means that a lot of them will turn out to be wrong. Prototype code is typically inconsistent, as it reflects experiments and trials, and evolves with gained knowledge. But, as the prototype is not meant for delivery, the changes do not propagate to parts already written unless absolutely necessary - so most prototype code will not be re-factored and re-tested. Prototypes simply contain too much hacks and problematic code to be used as a foundation for production software - so asking me to build something on that reminds me of the Python quote ‘Other kings said I was daft to build a castle on a swamp, but I built it all the same, just to show ‘em. It sank into the swamp’. My only consolation, so far, has been that this insanity also affects others, and is even recorded in The inmates are running the Asylum.

Sometimes, I get away by just agreeing to patch the prototype and then re-write the software properly. But this can backfire badly if the ‘brilliant’ minds find out (and they are typically in power). A recent post Don’t make the demo look done on Creating Passionate Users attacks this problem from a different angle - suggesting to handicap the prototype intentionally. However, this can also backfire - as customers may be unsatisfied with the results.

I think that I finally discovered a good solution - one that does not require any politics, long arguments or smuggling the re-write as ‘work on cleaning features’. I tried it a few months ago and got away with it, without any complaints.

Write the prototype in an obscure language

Do the prototype so that it cannot be shipped. Choose an obscure language or platform. When someone suggests that the prototype should be patched up and shipped - the answer is simple: ‘OK, but it is written in [insert obscure language here], so we need a month to re-write it in [insert production language here], and then ship it’. No arguments, no politics. They all agreed to pay for the prototyping in the first place, so there is no additional cost - just a missed ‘chance to save some money and time’.

I did mine this time in Python and on Linux, because the target platform for the final version was Windows and C#. Don’t take this wrong - it’s not that I do not consider Python/Linux as a production platform (I have delivered Python/Linux software to several other clients, with great success), but Python/Linux combination was completely unusable for production in this case. It would cost clients much more to introduce a new platform than the amount they would ‘save’ by cutting the development instead of proper prototype re-write, as they would have to train their IT staff and support. There are quite a few choices today - Python, Ruby, Groovy, JavaScript. Even if the target platform is one of them, the prototype can be written in some other.

On the beginning, everyone knows that the prototype is not going to be production-quality code, so no one should complain about some ‘obscure’ technology, since the software is not written to be shipped to the market. The prototype will actually be written much faster in a dynamic language then in Java, C# or other similar languages - which will help in convincing stakeholders to approve it.

When our latest prototype was done, there was even no attempt to patch it up - which surprised me. In any case, this was a win/win situation - writing the prototype in Python allowed us to start a web server and open an interactive console to re-wire it and perform live brain-surgery while the server is running. I cannot imagine doing that in Java or C#. In a month, we wrote the functional equivalent of at least 4-5 months of C# code. On the end, the prototype was thrown away, and everything was re-written, discarding half-developed solutions and throwing away ideas that turned out to be wrong.