Why Object-Orientation Is No Silver Bullet

Many years ago in the software industry recognised that there was a growing crisis in the way that people designed, built, tested and maintained software. This problem was coined the ‘Software Crisis’ (not surprisingly!) and has been with us ever since.

This crisis lead the industry to adopt engineering principles in order to make their software more reliable – a concept that very few working programmers care about.

Here’s the essential modern problem: Software is expensive. Remember that. Yes, you can go and buy sophisticated anti-virus software for GBP 30.00, but if you want to write your own software to tackle the same job it’s going to take time. An awful lot of time. There is nothing easy about writing good or bad software – both are equally as difficult. Bad software is difficult to produce because bad software must still ‘appear’ to work. If it doesn’t then nobody’s going to buy it. Good software is an incredibly difficult thing to do, and I believe that it’s one of the hardest things that a human mind can apply itself to.

The essence of good and bad software implies that there must be right ways of doing things and wrong ways of doing things. This is not generally true of software. Sure, we can talk of IS09k but believe me – and I’ve worked under these regimes – it’s not good. In fact working under military standards is even worse. Unless that is you like signing forms, Microsoft Word, and are a better touch-typist than your bosses PA, of course.

The way software is developed is that a programmer will be asked to write some software. Most programmers have a very limited skill set (very true if you consider all possible ways to deliver a solution) so will choose the one in which they know best. The manager will, in his infinite wisdom, have produced a very detailed specification from which the programmer will develop his software and verify against for functional correctness. (Yeah right!) A few eons down the line the programmer will deliver his solution. Of course, in this context, programmer should often read ‘programmers’ as it is often the case that teams of programmers are needed to produce some of the simplest software about.

I’d like to take a closer look at the manager’s choice of programming environment. I know I said earlier that the programmer chooses, but that’s not really the case. The programmer was employed by the manager for the skill-set he has - specifically to fit an existing business need; it’s an extremely rare thing for a manager to predict future software trends and needs (and in many cases impossible)

It is also the case that any future training courses which will be chosen by the manager will most likely decide the outcome of what the programmer spends at least 1/3 of his working life doing.

So given that the manager has a very big responsibility for the careers of his fledgling programmers, and the even bigger responsibility for the future of his department and most likely the financial success (or otherwise) of the company he works for, how does the manager choose what is a good programming environment, and what is a bad one? I know beer and pizza make for an excellent programming environment but that’s not the environment I’m talking about. I’m talking programming languages, and styles of programming language.

Firstly we need to drop the IDE (Integrated Development Environment.) This is the pretty interface that (potentially) makes programming easier. The IDE has nothing to do with the effectiveness or otherwise of a programming language, the syntax, and the language architecture. So when I talk of languages you must try to imagine looking at them in notepad and divorcing that IDE. IDE’s, as every quiche eater knows, are pure evil ™