General Musing

A day ago I read PHP: A fractal of bad design, and it made me sit down and think about writing this entry, of which the kernel has been gestating for quite a long time.

I see this a lot; pro’s ranting about an aspect of our ‘craft’ that has gone totally pear-shaped; programmers complaining about the languages or the quality of code they are asked to fix and/or maintain, systems administrators that just can not believe the insanity that is brought down on them because of either laziness of the in-house personnel or management-made bylaws.

Cryptographic specialists (even mildly spoken ones like Bruce Schneier), hackers nee security specialists, software designers… the whole palette of people that actually are proficient in their work gripe and complain.

The outages in service, security issues, privacy issues, performance issues, safety hazards with SCADA… we are accepting third-world standards here.

I could blame the hardware (‘it is all off-the shelf commodity stuff they are using nowadays’), but that would not be correct; the stock hardware now is more reliable than a lot of specialized iron from 20 years ago.

I could blame the programming languages (‘if you use tools as an analogy, then Perl is like a pair of pliers designed by H.R. Giger’), but, even though the languages make up for a goodly chunk of problems, it is not correct; whilst not elegant or correct or proper, most issues arising from the use of a specific programming language can be fixed by taking a bit of time and duct-taping on other software that takes care of these specific problems (heck, that is actually what is going on all the time).

I could blame the emerging economies’ developers (‘Indian and Chinese developers make such bad quality software’), but that would not be proper and it would actually be very incorrect; nobody pays them to take time and study to learn the correct ways. They do not have the luxury of our educational and social security, so they need to earn money right off the bat. And on top of that they get paid ridiculously low wages. If you want to work with Asian devs, make part of the assignment that they study and finish courses. Or teach them yourself.

I could blame the consumers or end-users (‘software has become a commodity product; a disposable item’), and while that may have some merit, analogous to the consumer buying Fairtrade goods or ecologically friendly items, it is not the main cause of the problems. The consumer does just that: consume.

So… who can we blame?

Well, how about the guys making the decisions, for one?

In my opinion, it is the management that needs to scratch behind it’s collective ear about the current state of IT.

First, they know something about theoretically nicely crafted project management schemes (like SCRUM, Agile, Six Sigma), and think that if you just follow all that nicely, you eventually get somewhere. The reason these project management methods are popular is because it allows everyone to just shout ‘hut hut’ and be off and ‘do something’.
Planning for the current crop of managers means ‘resource planning’, ‘deadlines’ and ‘deliverables’. The latter being no more than ‘Functional Specifications’ ‘Technical Design’ and ‘Data Model’.

Let me take these things apart:

An FS nowadays is a least-effort product because neither the ‘customer’ (sometimes an internal department), nor the ‘supplier’ wants to do a lot of work on it; it is not ‘something you can see being worked on’ (oh yeah, I get back to this one later), it becomes a totally obsolete and forgotten document the moment it is ‘delivered’, unless legal actions ensue at a later stage.

The TD is writing down what the customer says it must be (‘we support framework X on O.S. Y using hardware Z’). That is in no way a technical design. A technical design should always start out with full freedom of choice and be made to really solve all issues arising from the FS. Then, and only then, you can add restraints one by one and carefully take care of all artefacts of these restraints.

The DM is something that keeps amazing me; for some reason it is almost always like a mapping of a relational database. Why? I guess it is because companies like Oracle or the ubiquitous MySQL screwed the minds of people into thinking that ‘Entity Relation Diagrams’ are the only way to look at data. This also makes for one of the most common performance problems; all that following relations and extra tables.
I have seen queries that completely kill all possible caching just because the design was hellbent on using relations in a database. Here is a newsflash for those developers/software designers: sometimes it is computationally cheaper to do the bookkeeping yourself and let the data-model be nothing more than a key-value store.
But the managers can read ERD’s and they look more interesting than: id->Blob

Second, they need to see that something is worked on (told you I would get back to it). This makes for really weird constructions. A good software design starts at the O.S. level, builds up from that and since most of the work is (hopefully) done ‘underwater’ it would stand to reason that you would build solid foundations, then add the plumbing and finally do the decorating and window-dressing.
Not so with the current ICT managers… they want you to hang up some curtains quite soon, so you need to add a scaffolding for a window and then kind of build the house around the curtains (after all, as soon as the curtains hang, you need to spend an inordinate amount of time hanging them ‘just right’, because the ‘customer’ can not wait until you are done with the rest of the house).
This is because they do not understand ICT, but still want to act as if they are ‘managing IT’. The only thing they actually manage is to ‘not being fired’.

A good software design, whether it is a website, SCADA or communications, has the interface (the curtains, the GUI, the Look ’n Feel) separated from the engine; the thing that makes it work.

That is a requirement managers really should add to every requirement document: if you remove the interface, will it still work. If the answer is along the lines of ‘but the AJAX call…’ or ‘the widget does…’, go start forming a lynch-mob, because the person giving that answer is just trying to cover up his murder.

Finally (I could add lots more, but this is enough to get the idea across), an ICT manager needs to be proficient in ICT. That is kind of obvious, you might say.
Well, it is obvious that this should be so, but it seldom is.
A lot of ICT policy is rather because some of the engineers, admins, coders take an interest in matters above and beyond the call of duty, rather than an ICT manager becoming interested and making a point out of doing something.

Take for instance my previous entry on SPF, DKIM and DMARC; you will see that mostly the admins understand why this is a good thing and maybe they will implement it. Or an ICT manager read that blog, but then, because he is out of his depth, asks an overworked admin who tells him that is a load of bullcrap, so they won’t implement it. But very seldom will you see an ICT manager understanding the issue at hand, take time to see what the impact is in his company and then start taking appropriate actions.

In my 15+ years that I managed IT-departments, both small and quite large, I have made it a point to always manage at least one (usually not too important) server and contribute to the companies codebase once in a while.

Not because I wanted to show off my 1337 m@d skillz, but because I needed to know what the health of my department was, how external items influenced workflow and also to be able to understand my techs (and not to be hoodwinked by nonsense) and make them understand that my decisions came from real knowledge and experience, and not a 2-week management technique course with a shiny certificate at the end.

Concluding

My take on what is wrong with ICT is that management has lost the skills to manage ICT, obviously with the exception of you, who are reading this article (the fact that you even made it to this disclaimer qualifies you more than you might think).

To remedy that, I would say that ICT managers need to write at least one useful program every 6 months and administrate at least one system (it can be a workstation for all I care, as long as the thinking process involves planning and encountering the issues).

There is even an underlying scientifically proven principle to my method; people need to ‘internalize’ experiences to really incorporate them into thought-processes. Otherwise they build up analogies and models inside their head that are nothing but ‘cargo cult management’.

It is time to kick out the phlogiston in ICT management and get some real fire going on again.

This article is a guest written article, and was originally posted here.

Image source: Some rights reserved by Sebastian Fritzon