Consulting Engineers

For the last couple of years I've lived at the bottom of Syndenham Hill (on the Kent side). At the top is the place to where the Crystal Palace was moved after the Great Exhibition. The Palace and the park built around it had many water features and for this and other reasons water towers were erected to give sufficient head of pressure, something otherwise hard to achieve at the top of the biggest hill for miles around. Big park, lots of features, huge towers. 

The engineer who built these towers proved to be mentally unsound and the towers structurally unsound, so Brunel was brought in to rebuild them (which might happen again). The story goes that he was at first most reluctant to pass judgement on the work of another engineer, however bonkers. Gentlemen didn't do that to one another. 

This was in 1855, when engineering as a profession was young and about twenty years before the Tay Bridge disaster firmly fixed in people's heads the idea that one engineer won't do. Much as even accountancy firms themselves have to get an accountant in to audit their books, on a big enough job engineering firms get one another in to check they've got their sums right. This the work of Consulting Engineers. 

In the IT world we bandy the word "consultant" around with a certain amount of levity. In the US a consultant doesn't really seem much different from what in the UK we call a contractor: in everything but name a temporary employee. In the UK there is a slight difference, which a contractor once expressed to me (a consultant) in this way: contractors don't have to write reports.

More generally contractors build the system they way they are told to, consultants have an opinion about how the system should be built. This distinction is not lost on the tax authorities.

Anyway, what with all this talk of "craftsmanship" there's been about the place recently thoughts naturally turns towards the more mature disciplines. A significant aspect of those, in many cases, is that it's awfully hard to get certified to practice. 

That's in part so that individuals can bear some liability if the job goes tits-up because the certifying bodies certainly will. This is as imperfect as any human institution, but at least they try. Another aspect of this is genuine consultancy. If you, you personally, are going to bear liability for it all going pear-shaped then maybe you sould spread some of the blame load by getting someone else in. 

Notice that in the medical field, if you aren't sure of a diagnosis then you can ask for a second opinion. If your doctor isn't sure, they'll go and get one by themselves.

This seems not to happen much in the IT field. Perhaps another symptom of our immaturity? When was the last time you worked on a project where the prime contractor brought in a competitor to check that they'd "got their sums right"?

Have we had our Tay Bridge yet? Maybe. In some domains, avionics, for instance, you do hear of multiple independent implementations. That's not quite what I mean, though. 

Why don't IT companies running projects (of a certain size or complexity) routinely get the competition in to express an opinion? Why don't clients demand this as part of their risk mitigation strategy? What is it going to take for folks to bring a genuinely professional standard of conduct to IT?

Update: it's two days later and no-one has thrown down the gauntlet. I was expecting some bright individual to come back at me with a "you work for a consultancy, so you tell us why this doesn't happen" But no-one seems to be biting....

More Real Engineering

Via 37 Signals this delicious quote, one of several on this page:

If a major project is truly innovative, you cannot possibly know its exact cost and its exact schedule at the beginning. And if in fact you do know the exact cost and the exact schedule, chances are that the technology is obsolete.

As the discussion on 37S suggests, the word "obsolete" is rather strong. But then, the chap quoted here was Director of the Lunar Module Programme at Grumman. Working on Apollo probably gave you a rather different idea of what was obsolete from that of the average person. Or even the average engineer.

But the essence of the quote is absolutely right. And this is a crucial difference between manufacturing and creative engineering. Which of these things you think software development most resembles will have a big impact on what you think a plan looks like, and what sort of things you think are reasonable estimates to use to build that plan. That's not to say that in the case of innovation all bets are off: the Apollo Programme did meet JFK's deadline for putting a man on the moon and returning him to Earth (just).

But the next time you are starting a development project, getting set for iteration zero, or the inception phase, or whatever you call it, think about which parts of the project are innovative, and which are business-as-usual. Hint: using RoR to render SQL conversations over HTTP this time round instead of J2EE is not innovation. That's just no longer attempting to do you job with one hand tied behind your back. Second hint: the innovative bits are the ones that the business sponsors are really exited about and that the architect (don't pretend you don't have one) thinks are going to be "interesting" and that the project manager has to have a stiff drink before contemplating.

There are better ways to deal with the uncertainty that comes along with the huge promise of innovation, and, well... less good ones. You owe it to yourself (and your business sponsor) to figure out which aspects of the project you should be doing which way. Oh, and if the answer is mostly business-as-usual you owe it to the business to ask why the project is being done at all.