Psychology

I’m no expert in the field of psychology although personal experience and exposure to many projects in several types of industry lead me to believe that the biggest problem in developing information systems is – us.

Chasing your own tail

When I started as a programmer many years ago computer usage was extremely expensive. We had to thoroughly desk-check everything we did since the turnaround for a compilation or a test was several hours (and that’s not a typo!) and it also meant that we were diligent in documenting our code. The introduction to on-line programming offered greater productivity, however my colleagues and I soon found ourselves creating more mistakes and chasing our own tails trying to fix them. Tidy code turned to patchy code and left a legacy for anyone modifying the code at a later date. This became an important lesson in what was to follow. Anecdotal evidence indicates that the lower the price of the software tools and the easier it is to create something that (nearly) works has degraded the quality of computer programs.

Just keep digging

Prototypes were designed to be thrown away but in reality people will not often do this – they just keep going and the result is one big mess. The same thing is true of data modelling. Once something has been placed on the data model people are reluctant to change it and try to make new information fit into an incorrect model – it’s almost like they are trying to keep the model happy (and it’s similar with gantt charts). There is also a sense that people want to be ‘tidy’ and similar things are given a generic name so they can be placed in one neat little box, however this is simplistic rather than simple and causes all kinds of problems in the development cycle.

Opinions overrule facts

Information Engineering anyone? – fat chance. The original idea was to measure and prove the information you were analysing, however it has become very noticeable that a commonly held simplistic view will override any attempt to create a verifiable model. I once witnessed an Information Engineering consultant that worked for a highly reputed consultancy try and explain to a group of analysts that an ‘address’ was a composite attribute type and not an entity. Her logic was bullet-proof but it just didn’t suit their view of things and so they simply ignored her. There appeared to be almost no attempt to try and understand what they were being taught. I’ve seen this many times since and I can only assume that something else is going on when people reject provable concepts – and in the above instance from a highly reputed source.

Back to front

Relating to a common view of the world. This issue is better explained with an example. When interviewing, say, an Account Manager of a bank in order to ascertain information about the business processes and data, there is a pretty good chance the explanation will be from the customer’s viewpoint. It all gets written down and the process defined and a data model produced. The work gets signed off and taken forward into design and development – unfortunately for the programmers. The simple truth is that a business process has no idea what a customer actually is since it is a term that only works in any given context. At this point someone has drawn a box on the data model, written the words Customer Type on it and walked away. Every aspect of the analysis has viewed the process from the outside-in rather than from the viewpoint of the process. In reality the (so-called) customer account is a fairly complex piece of logic, with ‘liable parties’, ‘signees’ and various addresses for specific purposes. This outside-in view of the world may be useful to obtain an overview of the business for making strategic decisions but it makes a real mess of database design and causes huge problems in the programming. The common view is that the customer is opening a bank account. No, they’re not. They think they are but they are (provably) not. The bank is opening an account that the customer is given permission to use. Just semantics? No – the semantics are fundamental to understanding what is really happening. Crediting the customers bank account? Nope. When the customer puts money in ‘their’ account then the account is being debited as far as the bank is concerned, and it is seen on the bank’s balance sheet as a liability as they owe the money to the customer (and loans made to a customer are recorded as an asset). The bank creates the account and the bank decides when to close the account – the bank owns the account and the customer is simply given permission to use it and accept the liability for it.

Defending your honour

Well, not exactly, but we are all defensive to some degree and some people and some cultures are more defensive than others. If you see a sign on the big boss’ door reading “We operate a no-blame culture” then you’re probably in trouble since there’s a good chance it means the opposite, and if you’re niaive enough to admit a mistake you’ll either be passed-up for promotion or fired – best to keep quiet. Just about everything I have done in IT takes at least three iterations to get a workable result, whether it’s writing a report, compiling a computer program or whatever. It would be a healthy start to any project to get all those involved – users, analysts, programmers etc. into one room and say “Look, you’re going to screw up. Get over it and get on with it. Don’t complain that the programmer or analyst has come back several times and appears to be asking the same questions. There’s a reason for it. You may not understand the reason but it doesn’t matter and frankly, my dear, I just don’t give a damn.” (or something to that effect)