Monthly Archives: March 2016

Flexible Security

The apartment where I stayed in Venice has an impressive lock on the front door with four large steel pins going into the door frame.


The most interesting detail of this lock, however, is that you can decide how much security you want. If you just close the door, the latch will catch and the door cannot be opened without the key. If you turn the key once, the pins will extend a little bit into the frame, adding security. If you give the key another twist, the pins extend further, until the maximum security setting of four key turns. You can trade convenience for security, depending on how you perceive the threat of burglary while you are gone.

Most organizations have only one security setting in their IT systems. They implement a firewall to protect from outside threats and leave it at that. However, many threats come from inside. Analysis of the most serious security breaches in the last two years show that most are initiated by hackers using social engineering to convince insiders to break good security practice.

True security comes from a layered and flexible defense, not just one piece of networking kit. Can you give the key an extra turn in your organization?

Java and the Future of Forms

Another week, another Java-related Security Alert. Oracle is calling this one CVE-2016-0636, and it comes with a CVSS risk score of 9.3, which means bad. Just visiting a malicious web site can give an attacker control of your machine.

Since Oracle Forms depends on Java, this means that all your client machines need this patch. If you are running an unsupported version of Oracle Forms, you have an unpleasant choice:

  1. Either you dare to let your clients run auto update, risking that one morning your Forms application is dead
  2. Or you don’t apply security patches automatically (or at all), leaving you open to attack

Fortunately, there is an easy solution: Upgrade.

I’m talking more about the future of Forms in this week’s Oracle Tool Watch newsletter.

Inbox Zero

My IT class was staring at me in shock and I couldn’t figure out why. Then I noticed their eyes sliding between me and the projector on the wall behind me. I turned and noticed that the projector was now showing my Gmail account, because I had just used Gmail to send a code sample to the class.

“What?” I asked.

“You have twenty-three thousand unread emails,” stammered a participant.

Getting to Zero

My Gmail account serves as a backup – I forward all the mail from my various accounts to it as an archive. So I don’t read the mails in my Gmail account, leading to a build-up of many thousands that seemed unread to Google.

My real email inbox is empty at the end of the day. Yours should be, too.

The reason your inbox should be empty is that any kind of unfinished business occupies part of your attention. If your inbox is full of new things you haven’t read, things you haven’t decided what to do about, and things you are just keeping because you’ll work on them later, your brain will keep thinking about your inbox, and you will be compulsively checking it several times an hour to make sure you’re not missing anything.

There is more about Inbox Zero in this week’s Spiritual Programmer newsletter. Sign up here:

Concrete is Dead

On some of the blogs I read, the topic of Java’s imminent demise regularly pops up. Various internet pundits will regularly argue along the lines of a recent blog post: “Java EE is dead. Stop using it”. Others will weigh in, referring to the immense lead Java has in job postings and code used in real-life enterprise applications.

I don’t want to join that discussion. But I want to make you think about what that discussion says about our profession.

You do not see civil engineers starting blog wars with posts like “Concrete is Dead. Stop Using it”, and advocating carbon fibre for all construction. The reason is that civil engineers are engineers. They have a body of knowledge, accepted standards, examinations and accreditations, and they slowly accumulate knowledge and advance their profession.

In IT, we have been talking about software engineering for the 30 years I’ve been in the business. But we are even further from being an engineers profession than we were 30 years ago. For mysterious reasons, we regularly throw away the knowledge our users and customers have paid dearly for us to accumulate, and start all over.

Next time somebody comes up with a bright new idea, framework, or design principle, think: What would an engineer do?