Will Artificial Intelligence Take Your Job?

Science fiction writers and futurists have been predicting the dawn of the Artificial Intelligence era for decades. If you predict something for long enough, it is likely to eventually come true, and Artificial Intelligence is starting to live up to its promise. The march of the robots will affect different professions in different ways.

The Robots are Coming

The first jobs that went to the machines were routine manual tasks like workers used to perform on an assembly line.

The next jobs to go are routine cognitive tasks, and these have been disappearing for years now. Much of what system and database administrators used to do falls in this category, as does day-to-day middle management.

Next in line for elimination by computers are unique cognitive tasks. With the ability to handle ambiguous inputs and iterate and learn quickly, AIs will be moving into this area shortly.

Interestingly, the last jobs to be taken over by computers and robots are the trades. Unique manual tasks like fixing the plumbing or repairing a machine requires both high intelligence and manual dexterity. This is the kind of jobs that the DARPA robotics challenge tries to address, and this is going to be the last place where computers and robots will put you out of a job.


I help people and organizations use appropriate information technology to achieve their goals. The above is an extract from this week’s Technology That Fits newsletter. For more, sign up here: http://eepurl.com/0fpvT and follow @techthatfits.

Is Your Office Bad for You? Measure!

The other day, I was working at a customer site and had forgotten my noise canceling headphones (BTW, if you still don’t have a pair, I recommend Parrot Zik 2.0  – they’re awesome).

I could feel my productivity plummet each time other people in the large open office started discussing things, and it’s not just me. There is a lot of research showing that open offices are bad for many people, and since I track my subjective happiness (the “Life Score”), I notice that I’m one of the people not meant for open offices. My coping strategy is avoiding on-site work in open plan offices and failing that, headphones.

Does your office environment negatively affect you? To find out, start regularly writing down how happy you are with your life on a scale from 0 to 10. This gives you data to find out what work environment is best for you.


I’m writing about the Life Score in my upcoming book. For more tips on leading a happy, healthy and meaningful life in IT (and to be notified when the book is out), sign up for The Spiritual Programmer newsletter at http://eepurl.com/3z_0v and follow me on twitter @spiritualprog


Why Big Data gets it Wrong

As a young man, I commanded an anti-aircraft gun platoon. We had one radar unit which tracked enemy aircraft and controlled two 40mm guns.

When I started, our radar and calculation vehicle was all analog with vacuum tubes and rotating spindles. It took hours to start up, but on the other hand kept the crew warm during winter. The radar tracked the aircraft, the analog computer calculated the distance from aircraft to each gun, calculated shell flight time and where the aircraft would be, and then instructed the guns where to turn and how high to elevate.

It was amazing that the whole contraption worked, but it did. Well, almost. When everything was set up, we would release a bright red ballon with a radar reflector, lock onto that and tell the computer to aim straight for the target. Then we looked through the barrel of the gun and had a little box to make small adjustments until the tracking was spot on. After dialing in the guns using the “cheat box”, we could hit our practice targets.

During my time in the air force, our analog computer was digitized. Now everything was carefully calculated by computer, so our beloved cheat box was not considered necessary. And we couldn’t hit a thing.

Too many modern systems are built on the assumption that careful calculation will provide a definite answer. But your input data is very rarely as correct as you think.

If you are using buzzword-compliant systems based on Big Data and Deep Learning, you’re making the mistake the designers of my updated gun system did. By all means let the system calculate and suggest, but let real people make the decisions and provide them with the equivalent of my “cheat box” so they can adjust the system to the real world. That’s the only way to build a system that will meet business needs in the real world.


I help people and organizations use appropriate information technology to achieve their goals. For more tips, sign up for the Technology That Fits newsletter at http://eepurl.com/0fpvT and follow @techthatfits.

More Talk, Less E-mail

“Do you have a moment?” the project manager asked. Looking at his face it was clear that I needed to find a moment. So I got up and followed him into a meeting room.

A developer and a user were in loud disagreement about whether a specific Excel report from the system was correct or not. They each had printouts proving their point – a misformatted report and a correctly formatted one, and the Jira issue had been back and forth dozens of times. Mysteriously, they had argued for 15 minutes based on their respective pieces of paper without bothering to sit together in front of the system to try to reproduce problem.

We opened the system and pulled the report several times and it came out correctly. Probing further, we discovered that the user did not produce the report himself, but received the Excel sheet via email from someone else who “checked” the report before sending it to the user. Unfortunately, the checker opened the report and saved it in his old version of Excel before sending it, thus causing the problem

If you have a dispute about functionality, don’t hide behind email and comments in an issue tracking system. Sit the developer and user in front of a system and have them diagnose the problem together.


I help people and organizations use appropriate information technology to achieve their goals. For more tips, sign up for the Technology That Fits newsletter at http://eepurl.com/0fpvT and follow @techthatfits. 

The Value of Your Time

Do you know what your time is worth? This is important, because you should use this information to guide your life. Let me tell you how.

First, you need to estimate what you make per hour.

  • If you are an employee, divide your yearly salary by the number of hours you work per week x the number of weeks. If you are haunted by the specter of unpaid overtime, remember to use actual worked hours, not what your contract says.
  • If you are a freelance consultant billing by the hour, your time is worth whatever your average billing rate is.
  • If you are a freelance consultant working on fixed price projects, you need to register your time to calculate in order to calculate what you make per hour.

This number is what an hour is worth to you right now – it is the exchange rate between minutes and dollars. You can use this to guide decisions about how to spend your time and money.

Some decisions are simple math: If it takes you half an hour extra to drive to a cheaper shop, are you saving more than the cost of the 30 minutes? If you save $200 by taking a flight with a connection instead of direct, is it worth the extra travel time?

Other decisions cannot be calculated as easily, but the value of your time can still guide you. Do you think knowing another programming language or technology would get you a better job? How much more would you make, and how many hours would it take to acquire the necessary skill?

Figure out what your time is worth – and act accordingly.


For more tips on leading a happy, healthy and meaningful life in IT, sign up for The Spiritual Programmer newsletter at http://eepurl.com/3z_0v and follow me on twitter @spiritualprog

Do Your Users Trust the System?

Those of us who build IT systems every day can fall into the trap of building systems that assume they know best. These are called “Hard Trust” systems and users easily loose trust in them. Instead, you should build systems based on “Soft Trust” where the user can correct the system. In such systems, the user will forgive errors and still trust the system. 

Trusting the System

The illustration is from the Technology That Fits newsletter where I discuss this issue in more detail. For regular tips on how to use technology for business success, sign up here: http://eepurl.com/0fpvT

Success Factor: Framework Longevity

I just read an interesting article about  Longevity (or Lack Thereof) in JavaScript Frameworks, and Brian Moschel makes the same recommendations I make to my customers.

Mainly: You do not want to pick the tool that’s hot this year.

hot_js_frameworks(picture from blog above)

The reason is that choosing this year’s hot framework is an unnecessary leap of faith that places your project at risk. What happens if you choose wrong? You’ll watch your application fall behind the times, or worse still, completely fail.

You want a framework that has

  1. Been around for a few years
  2. Still being used and improved

That might not be what your developers are dreaming of, but it is the prudent way of deciding. If you are a development manager, you are being paid to provide successful software to the organization, not to boost your developers’ CVs with the latest buzzwords.

You Have Too Many Meetings

At this time of year, many people here in Denmark are returning from their holidays. And like office workers the world over, they come back to a calendar full of meetings.

Many of these are regularly recurring meetings. Interestingly, the world did not end while you were on vacation and did not participate in these. So maybe you don’t need to go at all? Or maybe nobody needs that meeting at all?

The people behind the web-based project management tool Basecamp  have written a free book about how to build web software, and it contains many tips that are generally applicable even if you don’t build web software. It turns out they hate useless meetings as much as I do. In the chapter “Meetings are Toxic,”  they propose that the few absolutely necessary meetings adhere to the following rules:

  • Set a 30 minute timer. When it rings, meeting’s over. Period.
  • Invite as few people as possible.
  • Never have a meeting without a clear agenda.

I encourage you to try it and see how it works for your organization.

And by the way, all regularly scheduled meetings (apart from the Daily Scrum  if you are doing Agile) should be cancelled.


For more tips like this, sign up for The Spiritual Programmer newsletter and follow @spiritualprog on Twitter. 

Matching Your Database to Your Application

I’ve just been troubleshooting an ADF application that ran fine on one environment and not on another. After some searching, I discovered that a script had not been run on one of the environments so the database was different.

That reminded me of a simple database check that I often include in my applications: I simply calculate a hash value of all tables and views with an SQL statement like this:

select sum(
+ ora_hash(column_name)
+ ora_hash(data_type)
+ ora_hash(data_length)
+ ora_hash(data_precision)
+ ora_hash(data_scale)
from   user_tab_columns
where table_name != 'PS_TXN';

I’m explicitly exclusing the PS_TXN table, because ADF might create this table to store application module passivations.

Every time the database changes, I calculate this simple checksum and store it in a constant in my application. At a central place in my application, I can then run the SQL and compare to the constant. If they don’t match, I’ll write a warning to the log. I don’t want the application to fail if my database does not match, but I do want to get a hint to check the database structure.

I place this check in the prepareSession() method in the Impl class for my root application module(s).


If you are working with ADF Development, I encourage you to sign up for my free ADF Mastery newsletter.

Stop Using Color

Many modern applications are using visual representations of data. That has potential to be helpful to the users, allowing them to better spot trends and variations in large data sets. However, the in-house applications I see are mostly using color wrong.

There is a science behind good data visualization, and commercial web-based applications have studied this. That’s why their visualizations look good and help the user. For an example, look at the flight search at www.hipmunk.com.

hipmunk flight

Unfortunately, most applications are built for in-house use and don’t have the benefit of a data visualization professional. The typical developer will simply place a default graph on a page and be done with it. It might look like this.


Image from http://blog.fusioncharts.com/2013/06/bar-charts-or-column-charts/

The color in this graph is superfluous and does not add any value; each data point is placed above its label, so there is no confusion possible. It places a cognitive load on the user, and it actually takes longer to read a gaudy bar diagram like this.

If you have a threshold value, you might decide to show all bars in neutral blue, but mark the salespeople seriously behind quota in red. But by simply ordering the values from high to low (instead of alphabetically by salesperson name), you are already giving the user enough information.

Don’t use color unless it has a meaning.