Monthly Archives: January 2014

Technical Debt

As a system grows, it accumulates technical debt – improvements and cleanup that your really ought to get around to doing. However, no-one ever budgets time for this kind of refactoring and cleanup.

The consequence is that any major change opens a Pandora’s box of interrelated problems. I’m involved in a project where we thought we could simply make a minor change to all 2768 tables, but due various historical design decisions over the year and their complex interdependencies, the simple solution only works for 514 of them.

Complexity increases exponentially – the cost of cleaning up after 2 years is 4 times the cost of cleaning up after 1 year. If you don’t plan regular code maintenance, you are pushing an ever-growing snowball of cost in front of you.

January diet for IT departments

January is almost over, which means that most people have already given up their New Year’s resolution to become leaner in 2014.

However, your IT organization should become leaner – in January as in every other month. The application of “Lean” methodologies in IT (Lean IT) is well understood, but most organizations still have a lot of waste to eliminate.

When working as a consultant, I get to experience the provisioning process of various organizations. In one organization, I was handed a laptop and a paper slip with my account and password and could start working within 10 minutes. In another organization, it took three visits over two days to various departments before I could start.

Which one is your organization most like? If you are like the second, what simple improvement could you make to eliminate a bit of waste?



Unwarrented Programmer Power

I’ve recently been involved with helping a customer decide on their strategic IT development direction for the next decade.

It never ceases to amaze me how much power programmers have. A decision that will affect the whole organization for years and years ends up being determined by which tool the developers like best.

And which tool do they like best? The one where you get to write a lot of code. No wizards, no assistance, very little framework support and an ocean of handwritten, error-prone code.

If you let programmers choose development direction, you will incur unnecessary development costs that can run into millions over the lifetime of a system. Don’t allow programmers to set your IT strategy to whatever framework is hot this month. Decide on a process and make a strategic choice.

The Sorcerer’s Apprentice

The first issue of my ADF Mastery newsletter has just been published (sign up here if you missed it). In this issue, I discuss Oracle ADF skill levels.

If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.

Gerald Weinberg, Weinberg’s Second Law

Too many programmers simply Google for a code snippet that seems like it might solve the problem at hand, and use it without understanding the implications. These programmers are like Mickey as the Sorcerer’s Apprentice in Fantasia – he manages to enchant the broom to get him water, but he doesn’t know what he is doing. So of course he can’t stop the broom again.

If you are a programmer, you need to build up an understanding of the technology you use. Otherwise, you will never build quality software.


Dont Glass and Drive

A Google Glass user was just charged with ‘driving with a monitor visible in violation of California Vehicle Code 27602.’ While the judge dismissed the case because it could not be proven that the Glass was on while the motorist was driving, he did state that activating Google Glass while driving is illegal according to the above section of the California Vehicle code.

Maybe that’s why Google is also into self-driving cars…


Disruptive doctors

In Copenhagen, our medical system has just been changed. Now, if you get sick or injured (non-life-threatening) outside normal hours for your own doctor, you call a nurse who will advise you. Before, you were always (sometimes after a long wait) connected with a doctor.

The system did not work as advertised and users experienced long wait times.

It now transpires that some doctors were actively sabotaging the system, placing nuisance calls to the new medical assistance line.

If you are using telecommunication or IT to change procedures, consider who will be negatively impacted by the new system. Try to get them on board, and be prepared for a few diehards actively trying to sabotage the system.

Big Data? Start with Right Data

I’m wearing a Nike Fuelband – one of those fitness/activity tracker gizmos. Nike is offering both a website and an app showing my daily activity. As a customer, I am expecting these two to contain the same data. After all, my bank balance is the same in my mobile banking app, in an ATM or in a web browser.

Unfortunately, Nike does not have a proper infrastructure behind their gadget, so the numbers do not match up. Their support people are pedaling furiously trying to keep everything in sync, but the customer experience remains questionable.

Your users expect a single, consistent view of their interactions with you – email, twitter, phone, in person. Can you deliver that? If not, focus on integrating your data into a single customer view before piling on even more “big data.”

Some thinking required

The tech press is full of the latest gizmos from the Consumer Electronics Show, held, appropriately, in Las Vegas.

Looking at the reports, I’m overwhelmed by a feeling of solutions looking for problems. I mean, it’s clever to have a smart bed sheet that can measure how many times you toss and turn during a night, but does it really fill a need?

Much more inspiring was the story in Wired where the magazine commissioned a design company to actually think about the use case for wearable computers.

tech companies fail to understand … the difference between glasses so cool you want them even if you don’t have bad eyesight and, well, Google Glass

They came up with a beautiful watch/glass combo that is actually useful. I hope someone will build it. Apple, the ball is in your court.


Winning the game by changing it

There was an interesting article and graph on Business Insider on how Apple has beaten the Microsoft monopoly.

In 2008, 28% of Windows users had an Apple product. In 2013, that number was up to 70%. Seven out of every ten Windows users have an Apple product today. Apple could not beat the incumbent monopolist in the operating system game, so they changed the game. And now Apple is worth around 500 billion and Microsoft at 300 billion is trying to keep up.

If you are faced with a hopeless obstacle, look for ways to circumvent it. IT people tend to have very linear minds, but there are always options to change the game. Make sure you have someone on your team who can generate creative ideas.

When is “Good Enough” not enough?

There has been a persistent trend over the last decade towards “good enough” technology. Remember the Flip video camera back in 2007? Everybody in the industry was laughing at a product with one button and no fancy features. But with one-button simplicity and YouTube upload, it met an need and captured 13% of the camcorder market.

Big enterprise software vendors like Oracle has effectively abandoned the low end of the market to “good enough” open source solutions. These might not have the clustering, failover and manageability features of commercial software, but are good enough for most users.

But maybe the pendulum has reached the furthest end of “good enough”. One of the most-hyped home IT products of 2013 was the Nest “intelligent” thermostat. It seems that corner-cutting in the engineering behind it causes it to sometimes turn peoples apartments and houses into saunas.

Sometimes, “good enough” is not enough. Do you have a clear picture of which of your IT systems can be “good enough” and which ones have to be excellently engineered?