Title: Once more unto the breach?

[This article is based upon a reply I made to Professor John McDermid's article entitled "Skills Shortage or Productivity Gap?" in the March 2001 edition of the BCS Computer magazine].

I have just finished one project for my last client - a large investment bank - where the technical difficulties in designing and coding the product were the least of the problems. I picked up some code designed and written by someone who had just left. The design was incorrect even to the point of allowing questionably poor business practice whilst the implementation was so poorly executed that it crashed immediately when any of about 85% of its functionality was used. The remaining 15% was just poor in terms of coding for maintainability and performance (does this split have something to do with the 80/20 - or 90/10, depending on who you ask - Pareto rule?).

I spent the first month or so working out what on earth was going wrong with it all. My initial task was ostensibly to write a set of unit tests for this product. At first I assumed I had misunderstood the product in question due to so many crashes but when it became clear that I had not misunderstood the product and was using it correctly, the full horror began to dawn on me. Guess which implementation wasn't reviewed until I started looking at it? I asked where the reviews where, I was told "You're it!".

The initial high-level design was carried out using a CASE tool that unfortunately had rather poor support for the UML the design was modelled in. In fact, the support offered by this particular CASE tool for the process of drawing anything was awkward, cumbersome and frequently just plain wrong. In fact, it got to such a state that developers simply uninstalled the CASE tool from the computer and used a beefed-up COTS drawing package called Visio. Whilst not providing all the support in terms of managed archives etc. that the design required, at least the developers could draw something and get a design document together.

To do a full build of this particular product took something like almost three hours on the fastest machines available. After two weeks of having my initial PC crashing to a blue screen (oops - given away the OS!) almost every time I did something - in fact, it got to the point where all I had to do was right-click with the mouse over the background and it would go blue-screen - I was eventually allowed to replace it. Needless to say, I lost countless hours as did the PC support team who valiantly attempted to revive the PC - but in the end it was just a goner. So: two weeks downtime on a project six weeks away from completion because the management view was that I "just wanted a new toy". Oddly enough, the management team had much better spec PCs than the developers with which to type their emails and Word documents - they must have been typing at some speed to warrant such high-powered machines! My replacement PC came which was, it must be said, faster than the old PC. I was having teething troubles with yet another CASE tool I had installed on my PC and when I finally spoke to the tech support person at the company and detailed the specification of my PC, the reply came back "Yep. My PC here is almost as bad a spec as yours." The difference was, I'd just received the latest approved version of PC. We couldn't get anything better on the grounds that it cost too much. Yet I wonder how much money they actually wasted for each of the developers waiting for compilation and linking? To make matters worse, the build dependencies were of a classic spaghetti pattern such that modifying a file in one area could - and often did - result in at last half the application being re-compiled and re-linked. Developers did request time from the management to sort out this mess but it was refused.

Although individual developers have been known to have a negative contribution to a project, the role managerial competence plays in the success or otherwise of a product needs to be examined. In fact, I would go so far as to suggest that managerial competence has by far the more damaging capability. An individual developer may have a "negative contribution" to the project. This will be picked up by other members of the team (and I mean will - the hapless developer may well suffer from the other team members too!). However, once this negative contribution has been found, providing the project has been partitioned into relatively autonomous sections of work, the damage will be limited and can be re-couped by the other more capable team members. Not so with managerial incompetence. This will run through the whole project and cause a lot of ill-feeling among the better staff who can see where the project is going wrong (and that their advice is being ignored which is also, unfortunately, often the case) as well as the danger of allowing the not so experienced managers the opportunity of "learning" poor management practice.

How about training up some of the developers? Training can be useful - but only for those who have been educated first! Taking yet another lesson from the software project under discussion, some members of another team were sent on a one-week course to program in a fairly low-level general purpose language (oh, alright then - as you've probably guessed it already - C++). After that they were let loose by project managers on production code! The projects started crashing all over the place and exceptions were being thrown like there was no tomorrow. Suddenly, the product could not be built from the software archive either! All hands on deck as the experienced C++ programmers were dragged away from their projects to fire-fight. Such is the effect of training without education - and such also is the effect of managerial incompetence.

I was offered the chance to stay on this project for another year but using my professional judgement I declined. Why? Simply because as a professional I offered good, sound advice on how to overcome all these problems but like a lone voice crying out in the wilderness I was unheeded.

The project I described above is unfortunately not a fictitious one. Working at that company was a real education for me - I never realised there could be so many poor practices under one roof and no desire whatsoever to change. So, is there really a skills shortage or is there simply a productivity gap? I suspect the latter.

Now the time has come to look for another company to work at. I must say that I feel disheartened at the current poor state of the UK computing industry. It's not really the level of individual developers or the current state of software tools/operating systems that I find depressing. It's the whole way software projects seem to be run. If only the managers could stop trying to manage the software project, concentrate on administration and leave the software to the senior developers I think a lot more would get done.

As it stands, I am at a point where I should be looking for new clients but I find myself asking whether I should bother. Do I really want to go through the whole thing again and again like some scene from Dante's Inferno?

P.S. the last I heard of that company was that they still could not build their own software and that the good people had all but left.