Sunday, November 17, 2013

Having it Both Ways

I've found something else that irks me in I.T. The idea of software development. For a lot of systems, such as management systems (information management systems, student management systems etc.), the applications are simply interfaces to a database. That's it. There's nothing all that complicated about it. I mean sure, I'm being totally blasé about programming but there's a good reason for it.

You see, the interface actually has two purposes.
  1. To provide a way to interact with the system.
  2. To enforce rules not supported by the database.
The problem is that point 1 above seldom gets more than a glance. Why? Because it's expensive... Take my own approach to development for example. I like to develop within the environment that something is going to be used. The problem with this is that you have to go a hell of a lot slower because you're doing a whole bunch of things.
  • You're building relationships with your users (This means dealing with horribly frustratingly boring issues such as dealing with mixed data types in Excel - is it a number or a number represented as a string?).
  • You're seeing what they're doing now and figuring out ways that can be improved (think in terms of an information flow manager. What triggers an event? Who deals with it? How does the next person know to do something with it? etc.).
  • You're trying to do the actual coding while making it future proof. A year or two into it and you're finding you need a complete rewrite because the system has changed so much as you've found more and more requirements. This mostly happens because the client isn't sure what they want initially and as you've built it they've asked it to be customized it to their needs and realised possibilities that didn't even occur to them.
Given the way that most software is built - very little user feedback with a whole lot of guessing as to how the user would like to interact with their system - then a programmer can't claim complexity as they've only really given the complex parts a passing nod. Calling a user in after the system is already built hardly counts...

And databases aren't at all rocket science. I think you could probably teach people relational databases fairly easily using every day language in a day. If you're then able to abstract those concepts into a visual way of designing databases without having all of the syntax, then anyone could build the database (sure, there's some thought to be put into the interface - ERD's for example are bad at showing constraints though are good for an overall picture)...

Which leaves me with a question - why are information management systems seen as complex? The only reason I've really seen for this is being able to charge more than is necessary for software development.

In which case - I'd suggest being a whole lot more picky about an application. Instead of relying on an hour trial of a system before signing off on it, put it into a pilot and get real users using it and listen for comments like "that's stupid" or "but it's just not doing it!" and reset the clock every time a change is required to make it suitable to the business - the pilot's not over until the system does what it needs to do in the way it needs to be done...

No comments:

Post a Comment