IT Dependencies

Lately at a customer I got introduced to an application written by an employee which should be replaced. There were some special features that have been implemented for the exact needs of the company. After a while I began to wonder why they want to replace it. I thought by myself: "What could be better than an application written exactly for their needs by a person who is actually in that company for a long time now?"

Finally at the end of the meeting after the others left, I asked the project manager at the company what the real reason is that they want to replace that program. The answer was: They want to get rid of dependency of that piece of individual software development and dependency of a particular person. They want to use a standard software.

While this sounds quite reasonable, I want to clear-up potential misunderstandings:

1. Even betting on the biggest companies and their products does not save you from the risk of software being discontinued or services shutting down.
   For example here is a list of software products discontinued by Microsoft. And this does not seem to be a complete list because from the first look I already miss the Visual Basic Classic which is also dead (and I have A LOT of experience with that which will be dead know-how in a few years).
    
2. Even the largest company-group sends you individuals that do the work and guess what: In most bigger IT projects (even when using standard-software) you usually end up with an individually customized piece of software and often with several project specific extensions. And who knows best your system? - The one who has done it! Change the person and the person needs time to analyse and get into it.
    
3. As time goes by most companies, when they start to buy external know-how or services, they begin to loose control. To reduce dependency you would need the source code, the know-how and the access. One effect of extreme outsourcing often comes with loosing your privacy and security.

So by switching to a standard product it is not very likely that you are reducing dependency. Often you save internal IT manpower for other things but you trade it for dependency or for privacy. Paying a developer for permanently being ready for implementing your business needs may not be the cheapest solution but you get flexibility and often reduce communication flows.

For many very tiny companies it might be perfectly ok, accepting the dependency from external services when they don't have to bother about their server-backup etc then. And so privacy is also traded (e.g. free web service for providing your personal data).

It is a matter of your values, your priorities, your time and budget etc. if you better have a server in-house or use some online-service in the web.

So what can you do?

• Be aware of your values
• Be aware of your business focus
• Be aware of your (human) resources
• Remove resolvable dependencies
  which means: Prefer forward-looking software products and plattform-agnostic open-source software over more limited alternatives.
• Distribute work and risk (e.g. have an external partner helping you but also have an internal administrator/developer who can do the work).

Related posts:  Priceless Developers, Surveillance, Privacy (NSA, PRISM, ...) and encryption, The truth about software.

Priceless Developers

When I get contacted by headhunters they are usually searching either for a developer or for a consultant and there is an interesting observation which I do see confirmed when I read forums or talk to friends:

Companies are willing to pay much more for a consultant than for a developer.

I am both - developer and consultant - and I can tell you: The best consultant cannot solve the issues that have been introduced by bad programming and software design mistakes. In a software company the whole business depends on the quality of the software released to the customers.

Only in very rare cases in my consultant role I have access to the source code of the base products in use at the customer. My daily job includes customizing bricks of software and tying them together. Of course this often means writing code on my own to make everything work together. So I am dealing a lot with APIs of software products.

During implementation of projects the vast majority of time goes into dealing with bugs, unfinished features and bad software design (or a software design that simply does not fit the needs)! And is pretty irrelevant which software product I am thinking of, it's the same everywhere. It would be better if I could focus on the customer needs and on building solutions instead.

There are people who have the opinion that most problems are just organisational problems or can be solved on the organizational level. I do not really agree with this. Of course, in most companies there is room for improving the organisation, but a software flaw should not be the reason for implementing workarounds on the organisational level.

Software vendors and their customers depend on stable, secure - good quality software. Those, who are building the software, often are poorly paid. Most of my ex-class-mates stopped the programming work completely in the meantime. In the same time I do not know any software vendor having enough good quality programmers. Instead bug lists are only getting longer over time. Really strange.

Related post: IT Dependencies.