Gojko Adzic

Three more guys walked through the door yesterday. The first proudly wore a Microsoft lapel pin. ‘This is something new‘, I thought, ‘maybe we’ll get lucky this time‘. Two hours later, I said to my colleagues: ‘I can’t do this any more… we are just wasting time‘.

We want to hire a few more people, and some new agency is flooding us with Microsoft certified contractors. We are not looking specifically for certifications, but somehow nine out of ten cats show off with MCSD.NET. A couple of them attached MCSD.NET to their name, in the first line of the CV, as if it was their biggest achievement to date. After the interviews, that thought seems very close to the truth. Continue Reading »

Here is the latest version of ‘Getting Fit With .Net‘, an introductory guide to testing .Net applications with Fit/FitNesse. Version 0.2 is updated to cover Fit.Net release 1.1, and contains a new chapter on writing better test scripts.

If you are using FitNesse for testing .Net code, you might find this patch useful – it contains several additions to basic FitNesse code which enabled us to write tests for a large .Net project quicker. Continue Reading »

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. Continue Reading »