So far this year I have been to see several clients to review their approach to information systems. Almost all have struggled with the in-house development of software – in many cases a lot of effort has been put into developing in-house software, and although it must have sounded like a good idea at the time, they have come to regret it eventually.
In my humble opinion (and I haven’t really researched this one too much yet) there are usually several factors that end up ensuring that it all turns to tears:
- It’s far too hard for internal software development staff to say “no” to any request for assistance from other areas within the business (and IT people are usually there to help, so they don’t like disappointing people).
- Our natural optimism operates to say that to do the development work required will be much easier than it ever actually is. Eventually, we learn.
- Developing software is really, really interesting. Documenting it and writing down what you did isn’t so easy – and besides, there’s always a new project to get to.
- My final factor as to why an in-house development approach ends up giving corporate heartburn is that few organisations can afford to provide the real tools that are needed, and support the large development staff necessary to allow people to bounce ideas off each other. The natural evolutionary progression of this is that few good tools are available to the development staff – ergo, staff leave to go to more prosperous waters (and since it was never documented, it’s time to cue the violin music for all that investment that sails into the sunset).
For my clients, I often say to have a Bex and a good lie down before you embark on an internal software development project. And if it still sounds like a good idea tomorrow morning, then you should see your GP (because those symptoms are still persisting).
It’s not that all in-house software development goes to hell in a handbasket, but it is awfully difficult to do internal software development well on any large scale, and to have the discipline and the methodologies available is often beyond the capacity of a lot of my clients here. If you ever do think about writing substantial amounts of bespoke software, be sure to recognise the risks that come with that approach.
I am beginning to wonder if you aren’t better off adapting sometimes an open-source solution that does 80% of what you need for a small commitment of work (and my presentation on Tuesday night, again, talked about some of the issues you might come across there).
Hmm. I suggest I’ll need to write an article on this topic one of these days. Although, maybe I just did that.
