40 years ago, Fred Brooks told us in his book The Mythical Man-Month why full outsourcing couldn’t work. Since outsourcing was rare and difficult back then, nobody took note. Today, advances in communications and technology make outsourcing much easier. That doesn’t mean it will work.
The reason is that IT work is not uniform. There are some easy tasks (rapidly getting automated) and some hard tasks that take expertise and judgment. And most organizations are outsourcing their work to regions where IT professionals haven’t had the time yet to develop expertise and judgment.
In a mature IT market, a wide range of skills exists, from basic to very advanced. As you need more advanced skills, the cost goes up, because there are fewer IT professionals with the requisite number of years of learning and experience.
In a new IT market, you can get basic competency cheaper. But because most IT professionals in these markets are relatively inexperienced, advanced skills are very rare, very expensive, and might not even exist.
The outsourcing fallacy is to think that you can move an entire, complex IT operation offshore. You can save money on moving simple tasks to regions with lots of competent but inexperienced IT people. But advanced skills won’t be available. So unless you can very cleanly separate simple tasks from advanced tasks, the communication overhead necessary to ensure that the right people get the right task will eat up any saving.
Think you can save money by outsourcing? Maybe you can. But many IT organizations have found they couldn’t. Get in touch if you need help figuring out the right level of outsourcing for your tasks and your organization.
Medicins Sans Frontieres have an annual collection here in Denmark, and I was one of the volunteers going house-to-house to collect donations.
I experienced quite a few people who didn’t have cash but still wanted to contribute. This is in alignment with recent surveys who show 21 percent of Europeans rarely use cash.
However, the belief that the cashless society will be a boon is utter techno-arrogance. It takes the average user approx 5 seconds to drop a few coins into my collection jar, and 10 seconds to fold a bank note and insert it. But nobody managed to complete an SMS transfer or mobile payment in less than 30 seconds.
It might be in the interest of shops, banks, and the tax collector to get rid of cash. But does it justify wasting 4,000 years of time globally every day? Consider the total cost to everyone in money, time and effort before you add technology to a process.
Developers hate it when pesky users raise bug reports against their wonderful creations. I’m a developer myself and have sometimes found myself mystified why a specific piece of code didn’t work in a specific case.
But don’t ever let developers tell the users that the code works fine, and the problem must be with the user.
I communicate with a lot of people and have been using Contactually to keep a central record of all my contacts. One nice feature of this tool is that it can use IMAP to connect to my mailbox to include the emails I’ve sent in the overview. For some reason, this IMAP functionality stopped working, and after some back-and-forth with support, I was told that the problem was with my password.
This is a rather disingenuous excuse, as the software already gives me an error if I enter an invalid password. It reminds me of the Beavis and Butthead episode called “Customers Suck“, where the two idiots don’t want to serve customers and can’t even be bothered to come up with a good excuse.
However, the poor customer service employee had no choice but to pass this lame attempt at blame-shifting to me. I had to cancel the service.
Make sure you are not allowing your developers to shrink their responsibilities and ruin your reputation with customers internal and external.
In a famous Monty Python sketch, John Cleese tries to return a dead parrot to the shopkeeper where he bought it. However, the shopkeeper is impervious to reason and claims the clearly dead parrot is still alive.
I just had a “dead parrot” moment with iTunes support. Their support used to be excellent, but the humans have now been replaced by imbecilic chatbots. This is a serious miscalculation.
What really annoys customers is when they are not listened to, and not listening is the one core competency of today’s chatbots. Being served platitudes about “we understand you are unhappy” doesn’t make me happier…
If you are considering chatbots for some aspect of your operation, make sure to offer an option for the customer to give feedback. Apple doesn’t, and Tim Cook probably thinks their support is brilliant. It isn’t.
Historians have described the period following the collapse of the Western Roman Empire (400 to 1400 AD) as the “Dark Ages.” Existing knowledge was lost and society regressed to a more primitive organization and technology.
In IT, we do not learn from history. We routinely throw away existing knowledge to start over, constantly emerging from each dark age only to enter a new one.
I was just reminded of this unfortunate tendency when I opened The Economist on my iPad. I used to read the magazine in traditional form on dead trees (aka paper) but moved to their iPad app to get my magazine on the publication date and not two days later. Their first iPad app reproduced the magazine layout with several narrow columns of text, re-using centuries of typographical knowledge. But in the new version, the clueless digital natives have decided to make the text one wide column with the lines way too close together, which makes it much harder to read.
Next time you get the bright idea to change something that has worked well (a page layout, a business process, or an IT framework), reflect on whether the change will really make it easier for the system to fulfill its promise.
Part of the supposedly unbreakable Amazon cloud was down, and the world didn’t end.
What did happen was that a swarm of the best operations people in the world rapidly descended on the problem, diagnosed and fixed it. You can be sure the issue had top management attention, because Amazon’s brand, reputation, and business rides on their infrastructure.
With all due respect to your infrastructure and operations team, they are unlikely to have the manpower, specialization, and training that Amazon cloud engineering has. If the same issue had hit your own in-house data center, it would have taken you much longer to find and fix it.
It is drummed into every aspiring developer that duplicating code is bad, and re-use is good. Seen from the organization hiring the developer, that is true. But seen from a developer under pressure to meet a deadline, it makes perfect sense to write his own code, even if the same functionality has been implemented before.
If you want to promote re-use across teams in your organization, you need to do three things:
Document all services with examples. For REST web services, you can use a tool like Swagger.
Implement the policy that old versions of services are not retired until nobody is calling them
Enforce a policy of calling services instead of writing them over.
This is an excerpt from the monthly Technology That Fits newsletter. Sign up here.
Moving your software to a cloud vendor has always been an act of faith. You believe the vendor will honor their promises, fulfil the SLA and stay in business.
That’s why many are choosing the big names like Amazon, Microsoft and Google.
Oracle wants to extend its brand into Cloud computing as well, but they are not even on Gartner’s radar, and with their recent decision to double the cost of running Oracle on Amazon, they are not endearing themselves to customers.
No matter which cloud vendor you choose, make sure that you establish an exit strategy in advance. You need to be able to keep your systems running even if your cloud vendor suddenly folds. That means that you need to establish a procedure to continually transfer data from your cloud to a third part (or back to yourself). Don’t get stuck in the cloud.
In my popular “Everything that’s wrong with IT” presentation, I use various technical gadgets as examples of the traps we tend to fall into when developing IT.
My favorite example of too much technology for technology’s sake has been my internet-connected socks. Unfortunately, these RFID-equipped wonder socks were discontinued after I started making fun of them. But I think I’ve just found a new favorite: A bluetooth-equipped hair brush.
This brush is so advanced that it can’t even be called a brush – it is a “hair coach.”
On a recent site visit, I went to the printer room to dispose securely of a draft of my confidential report. As expected, there was a container for confidential papers. As expected, it was locked. Unfortunately, the lock was only put through the bracket on the lid, not the container itself.
If I wanted to, I could have rummaged through all the departments’ confidential papers.
Much security is like this: Locked, but not secure. The organization suffers from all the impediments of spotwise strict security while overall security is still lacking.
The only way to build a secure IT infrastructure is to have someone regularly verify the security, including everything from the padlocks to the installation of vendor patches. This can be an internal compliance team or an external service – as long as the verification is not done by the people responsible for implementation.