Yes, there hasn't been a new article from me in quite some time. Even though I have been busy writing, I simply haven't been able to complete the articles I've been busy with. Individually they had merit, but the subjects were so inter-twined, that they were in fact a single article. So here it is, collectively reworked and condensed into one article.

How to get IT horribly wrong.
In my experience, there are three very easy ways to get IT wrong.

1. Politics
   The worst enemy of IT, is politics. I've personally witnessed well designed, written and tested software, perfect for the task at hand, being rejected and remain unused, due to politics.

   One example that comes to mind, was the creation of a peace of software, that would enable a particular call-center to function in the order of 45% more efficiently than it did at the time.

   The software was rejected, because the call-center manager feared losing his budget for more personnel. But even worse than that, was the one person that did use the software, pointing out the incredible mis-management of other departments in the company. That person was drummed out of the company. Leaving the incompetent and lazy managers, to enjoy their little empires while costing the company millions per day in lost production.

2. Incompetence
   I am amazed at how many uneducated, unskilled people, worm their way into top IT positions. What makes it worse, is that these people manage to get into what is supposed to be top technical positions.

   The best example of this, in my personal experience, happened in and around June of 2007.

   I was asked to draw up a few questions of what I would expect someone in my position to know. So I created three code samples, with rather obvious syntactical and logic errors. Then, in order to make sure I wasn't smoking my own socks, I handed the examples to two of my "co-workers".

   The results were shocking. I was amazed to learn that even though the posts we were occupying called for C and C++ skills, neither of these "co-workers" had any training, formal or otherwise, in either of these languages. The fact that both of them have been working on the project 3 or more years longer than myself, only confirmed that they should never have been hired in the first place.

   The one good thing that came out of this, was that I finally understood why C functions spanning more than a thousand lines of code, was so common in the code produced by these “developers”.

   Yes, you read that right. C functions, 1000+ lines long. The most infamous one spanned 1997 lines. The only way this happens, is through gross incompetence or an intentional joke, but there were too many of these to be considered a joke.

   This kind of incompetence, leads to micro-management of developers. To the extent where Project Managers will require developers to gain signed authorization for compiling code on a test machine. This is not a joke, I have worked in environments like this.

3. Documentation
   This is my pet peeve. Yes, I'm all for Documentation. Note, that I state Documentation, NOT BUREAUCRACY.

   In all my career, I've had the pleasure of working in two environments where the systems were actually documented. Getting up to speed in these environment took almost no time at all, allowing me to become productive in a matter of hours as apposed to days or even weeks.

   But there is one thing I have not found in a single environment. Something I honestly consider obvious and needed in every IT department, regardless of size.

   Documented Business Process.

   Anyone writing code is “teaching” an electronic device to administrate and facilitate a process. If you are writing code for a business, that code can be directly mapped to a business process.

   This is where the coders spend 60% of their time. Figuring out what the hell it is, that is actually suppose to happen. Rather than some half backed, poorly worded e-mail, word document or (gawd forbid) a “bug” report.

   If there is one thing I would love to hammer into every management body out there, it is the documentation of their business processes. Without it, they themselves don't know what is supposed to happen or when. How (in the name of all that is good and holy) do you expect me (a person that doesn't know your business process) to create working code, quickly, efficiently and without a mountain of bugs. When you (the manager) can't explain your own damn business process to me. You might as well try to build a house without a building plan. Sure you can do it, but don't come crying to me when it falls apart.

   Nobody! Not a single company, organization, individual or government. Has enough of a budget to neglect documenting their own processes. If the person responsible for administering a business or portion thereof, can not sit down and create a document explaining the processes they are responsible for - in plain, common language. That person is incapable of holding down the position they are employed in.

   But even that is not enough. The documentation has to be easily available. Anyone from anywhere within the organization should be able to locate and use that documentation.

   There is nothing more wasteful, than having your developers running around doing requirement gathering, while they should be writing and testing code.

   This is the main reason Project Managers think more developers equate to more production. This fallacy is perpetuated by the bureaucracy generated due to lack of proper Business Process Documentation.

   In environments where the business process documentation is non-existent, you'll find there are one or two people keeping the system alive, purely because they are walking around with the documentation stored in their heads. These people need to be forced to put that documentation where others can get to it without effort. Refusal to do this warrants dismissal of that person, as they are deliberately endangering the company/organization by making themselves in-disposable.

   One more thing, just in case any of you start touting “but that's the annalist's job”. In 14 years of working with analists (note: ANALists) I've concluded, that they serve only one purpose:

   “Fool the user into thinking, that someone is listening to them.”

To summarize the above:

1. Politics will kill any software, regardless of how well it's been written, tested, documented etc, etc, etc.
2. Incompetence will generate exactly the kind of software you do not want.
3. You either have proper, clear documentation, or chaos. There is no happy compromise in this regard.

How to get IT right.
This is even simpler than getting it wrong, all you have to do is apply the inverse of getting it wrong.

1. Politics
   Don't get involved in it. Do not tolerate it. Do not compromise with it. Do not practice it. If you find yourself in politically infested waters, do yourself the favor of finding other employment. Leave the politics to those who seek employment for the sake of a salary at the end of the month. You know the kind. If they use half the time spent covering their own asses, to actually get the job done, there would be no need for them to cover their asses.
2. Competence
   Yes, competent IT personnel are difficult to find and expensive. But employing two experienced individuals, that know what they are doing, will see you getting things done faster, better and cheaper, than employing ten others. They also tend to stick around much longer.

   Take note, that no amount of “paper” can give you a true reflection of competence. The only reliable indicators you have are living, contactable, human references. Even then, it's ridiculously easy to get it wrong.

   Your best bet is to present candidates with a test. There are many articles regarding recruitment of knowledge workers. Go read them.

   There is one key factor regarding competence, that will save you, your company and your budget. If at all possible, make sure your Project Manager is at least as technically sound as his lead developer. In fact, your Project Manager should be able to take over from any of his developers, at any given point in time. Finding people, that are both competent Project Managers and competent Software Engineers, is almost as difficult as bathing a cat. Difficult, but not impossible.

   Using a Project Manager lacking substantial technical knowledge and experience, equates to hiring a first year medical student to do a double bypass on the president. You'll find the assistants doing everything, while he frets about, asking silly questions and making ridiculous demands. They are also very susceptible to politics.

   Personally, I find the best results are achieved when your Lead Architect is also the Project Manager.

3. Documentation
   Is not an optional extra. It's a requirement. Part of your testing should include a completely clue-less individual, reading the documentation and walking away completely clued-up. Anything less means the documentation is incomprehensible, unobtainable or non-existent.

   Here you need a rather special breed of person. The kind that is capable of understanding the technicalities of software development, while being able to explain, in idiot-speak, what it does and why.

In Summary:
Hire intelligent, self motivated, self educated, responsible and goal oriented individuals, who hate politics and shoot politicians on site.