Monthly Archives: August 2015

The End of the All-Powerful DBA

The Ashley Madison security breach has again turned IT security (and the lack thereof) into front page news. Nobody in IT should be surprised that hacker attacks like this one is possible – after all, the Ashley Madison CTO managed to easily hack into a competitor’s website.

The problem all unsecure sites share is the all-powerful DBA, and that role needs to be reconsidered. You can take two different approaches:

  • Enforcement
  • Trust but verify

Both of these approaches need to involve an IT security officer whose job is security and only that. The security officer should be a person not involved in database or system administration and should not share an office with the DBAs. The security officer belongs in your compliance organization and is more akin to an auditor.

If your data is truly sensitive, you should decide to enforce security (and accept a cost in lost productivity). With this approach, you place hard restrictions on what users can do. This includes securing that the DBA can’t read sensitive data and can’t grant access. Only the security officer can grant access and you ensure that nobody has both DBA and security officer roles.

If you focus more on productivity than absolute security, you can decide to trust but verify. You don’t place hard restrictions on your data, but monitor who accesses data. In this approach, the DBA can still read data, but not change the logging level or delete logs, and the security officer read these logs.

The problem is that most organizations follow a trust paradigm without the verify, and that is the way to Edward Snowden, the U.S.Office of Personnel Management and Ashley Madison. If you want to be secure, the all-powerful DBA has to go.

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: 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 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 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 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 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:

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.