Safe driving has two components: Safe cars and safe drivers.
A Volvo car is built like a tank and is equipped with all kinds of safety features – it’s a very safe car. Unfortunately, Volvo has unthinkingly undone all the advances they have made on the car side of the equation by making the driver much more likely to cause an accident. How did they do that? With touchscreens, of course.
A driver in a safe car can reach out and touch a lever or a button without taking his eyes of the road. A driver in an expensive new Volvo XC90 must look at the touchscreen. Now, if your car is built like a tank, that might not worry you. But it should worry all of us outside.
When an implementation project for a standard system like SAP or Oracle E-Business Suite runs completely off the rails, it’s because the programmers have been allowed into the project.
Programmers are very accommodating people and they don’t like to say no. And true enough, given enough time and money, they can build anything.
The problem is that the business case for a standard system rests on the word “standard”. Not “almost-standard-with-a-little-bit-of-code”. By all means use the customization features built into the standard system to adapt it to your organization. But you allow even a little bit of custom code into your project, you are ripping out the foundation on which the entire business case rests.
If you’re applying for permanent positions and not getting hired even though you have the skills the organizations asks for, consider whether you are proving your ability to learn new things.
I’m often talking to people who believe their 20 years of experience with technology X or Y should make them shoo-ins for a job. However, they are not getting hired.
The reason is that a modern organization can’t depend on the same skill being useful for the next 20 years. With the speed of technological change, an organization will rather hire someone who has proven his or her ability to learn new skills.
It’s great to have experience. But unless you also have recent experience with some new technology, a developer with less, but more recent, experience will beat you to the job. Learn something new.
This is the dashboard of a Tesla S:
With a large touchscreen and very few physical buttons. A lot of design time went into building this. Very cool-looking.
This is the steering wheel of a Formula One racecar (which is incidentially the whole user interface of the car):
A small screen and a lot of physical buttons. A lot of usability engineering went into building this. Very useful.
If you are going to be handling controls while driving (whether at 55 MPH or 200 MPH), you need tactile feedback from the control you are operating. Tesla opted for cool, Formula One opted for useful.
Are you building technology to look cool or be useful?
The above phase means “who will guard the guards themselves?” and is relevant in many security contexts.
Here in Denmark, we are currently having our own “News of the World” affair. In our case, a contractor at the payment processor handling almost all Danish credit cards was able to automatically send a tip to a journalist whenever a celebrity used his or her credit card. That makes it hard to take an incognito honeymoon like Prince Joachim of Denmark tried (and failed).
This contractor had system administration privileges and was able to continue this illegal monitoring for years without being detected.
Too many IT systems have an all-powerful system administrator. It’s more convenient for the system administrator, but it is not good IT governance. All kinds of sensitive operations need both an operator doing the task and an auditor checking that only the relevant tasks were carried out. Naturally, the audit trail needs to be protected so the operator cannot change it. Not even if he is a system administrator.
Do you know what data and which operations in your systems are sensitive? And are they appropriately protected?