leyton.org

I’d like to say that I’m no longer surprised by the need of so many IT professionals to re-invent a perfectly good wheel, but, well, I’d be lying. I am continually and utterly taken aback by the need by many in Information Technology to prefer to re-invent solutions to a well-known problem.

Years ago, when I was a student I recall sitting in an Object Orientation lecture, and the lecturer pointed out that one of the big advantages of OO, and the class libraries included or available, was that “much better programmers than yourselves have already solved these problems“. This particular lecturer was certainly brusk at times, and I recall having my self-esteem somewhat buffeted by this statement, but I look back on some of his words and advice now with a much greater appreciation. I probably now share the cynicism he was famous for.

It’s the same with infrastructure solutions. The example that comes up most in my experience is ticketing and request systems. For the non-IT readers of my blog, this is a system that takes an e-mailed or completed web form and pops it into a queue. The ‘tickets’ are then able to be tracked, handed about, and managed. It makes for much better processes, especially in support environments where you’ve lots of people perhaps needing to be involved, or where you need to enable things to continue when staff are out of the office. The alternative is usually e-mail, and that is an atrocious tool for keeping track of tasks and projects.

Suffice it to say it’s a problem that is quite common-place in organisations of all sizes. Big companies need to manage the customer experience, and ensure they’re doing it cost-effectively. So when you phone up your electricity company, your call is being logged and tracked and audited. If you e-mail your ISP, you almost certainly get added to a system. You may even get an automated reply with ticket details.

Because it’s a common-place problem, it’s been solved by lots of different companies, who offer their products for purchase, and there are plenty of open-source solutions if your budget is tight, or your requirements are (perhaps) more specialised. Big names like Remedy have large solutions that can be customised in a multitude of ways. In the open-source world, Best Practical offer RT, which is comparable in many ways. There are plenty of others, but these are great examples that I just happen to have used myself.

But on a scary number of occasions in my career so far, I’ve hit situations where clients have felt some driving need to implement their own solution to this particular problem (even when the organisation may already have a largely suitable system in place). Often, for reasons I’m still not too clear on, it frequently involves me. At this point I usually make it quite clear that there are existing solutions (sometimes already in use at the organisation). The problem is the staff involved often latch on to a specific problem/feature-gap and point at it (it is otherwise functionally complete) and it’s abject failure, before continuing with the dubious logic that “we therefore need to build our own solution“. Thus re-inventing a perfectly good wheel, and (cynic that I am) probably doing a half-baked job at the basic stuff that the existing solutions already do extremely well.

What seems to get overlooked is that existing solutions are often highly customisable, and – if well chosen – can almost certainly be extended to add this feature (which, in my experience, is usually a quite minor one). The developers of the published solutions know that they can’t offer all things to all people, so frequently design it with configurability in mind.

But the really big argument against ‘doing it yourself’ is cost. Rejecting something that is likely to be 95% appropriate, and putting together an in-house solution takes developers a long time to even get that 95% functionality you might already have, for free. Most likely your in-house solution will only ever offer core functionality, so adding further functionality takes yet more time and money.

Is the 5% difference (or whatever it is) really so important that it’s worth putting in serious time to solve the entire problem again, just so you get your new feature? Are you really sure you can’t do it with a bit of focused integration/customisation time?

Of course there’s the ‘business advantage’ argument. Many organisations can get a competitive advantage by implementing their own solution to particular problems. That’s innovation and good business practice, where appropriate. I’m focusing my comment on generic business process issues, rather than business critical systems: Trade capture/entry, transaction processing, order management. Core functions in many businesses. Of course, there are generic solutions out there, but they’re not going to always be appropriate for the business model, or the established practice. When there’s a discernible advantage to your business to ‘roll your own’, go for it. With my encouragement.

We of course no longer design our own computers, operating systems, network devices, programming languages and so forth – Apple, Microsoft, Sun, Cisco, and countless gifted developers have solved all of these problems so well for us already, that we all now make use of the tools they provide us without thinking (Unless you’re Google of course)

So why not more so with internal systems? Why the need in so many IT departments, when faced with generic problems, to feel they have no other choice but to re-invent the wheel?

Please, put the keyboard down, and think, before you start developing. Much better developers than you have probably already solved most of what you need to do, and provided a framework for you to extend their system in useful ways. It’s just a case of doing your homework first, and properly understanding the real costs in doing it all over again.

Postscript

This post has provoked a number of interesting offline discussions, and I’ve a few more thoughts on similar IT issues/attitudes that I hope to be posting here shortly. In the meantime, my friend Matt pointed me at an excellent post on developers and complexity, as well as giving an excellent analogy to the problem I’m describing:

this round wheel [off the shelf product] doesn’t let me park on an incline with the handbrake off [specific requirement] so I am going to create a new square wheel that does [inhouse solution] but I seem to be getting a really bumpy ride and it’s impossible to steer [wonder why it was round in the first place]

I’m pleased to publish an article I have been working on for the last few weeks. It is, in essence, an overview of version control, but I start from the premise that it is badly misunderstood by a large number of technology practitioners. Because it is badly misunderstood, I strive to address the “justifications” I have heard as to why version control has not been used, and why those arguments are largely incorrect.

I make no apologies for being perhaps a little aggressive in some of my arguments: I honestly feel that version/source control is as vital a part of the software development cycle as hiring good developers, making good backups, and delivering the requirements to the business. But many people, including senior employees, can put everything at risk when a version control solution is either ignored, not adopted, or – just as badly – not enforced.

Version control is not, and never has been a panacea. To the initiated, my arguments may well seem something of a statement of the obvious. But I’d simply ask that you conduct a straw pole of technologists in your organisation or social circle. How many of them, from programmers to system administrators to managers, are enthusiastic towards version control? If it’s more than twenty percent, I’d be surprised.

So my article provides arguments for and justifications towards version control. It will hopefully be a useful resource for both the casual reader as well as a help to any proponent of source control inside an organisation, struggling against the sort of apathy or hostility I have frequently encountered.

I look forward to any feedback of course. A big thanks are due to friends who helped with comments on the article.

A printable PDF version is available at the base of the article.

Read the rest of this entry »