You’re Cleverer Than You Think

I often train experienced developers in new tools, and I’ve found that most underestimate what they can do – their actual skill level is higher than their own perceived skill level.

Skill development

This is different from new developers, who tend to overestimate their skills.

The reason this happens to most experienced people is the “loss of control” feeling overcomes the feeling of accomplishment. If you are very skilled with one tool, you are acutely aware that you are not an expert in the new tool – yet you feel that you should be. Cut yourself some slack – you are cleverer than you think.

(The graphic is from my newsletter “Technology That Fits” – for a regular dose of fresh IT thinking every week or two, sign up here)

Hardware is Cheap, Developers are Expensive

When advising customers on ADF projects, I often find development environments where many or all developers are working against the same database. That introduces a hard dependency between different parts of the project – if one developer deploys a defective PL/SQL package to the database, nobody else can run the application.

This approach made sense back when hardware was expensive and databases had to be managed by high priests in glass-walled, climate-controlled rooms. Today, you can buy a development machine with a quad-core i7, 16GB of RAM and a 256GB SSD disk for $1,200. This machine can easily run an enterprise-class database, application server and IDE. Additionally, virtualization software allows you to build, distribute, and reset environments easily.

It doesn’t make sense to have expensive developers work on old hardware. As soon as they have lost a day due to an inflexible development environment, you have lost more than the cost of a proper development laptop.

Don’t waste expensive developer time because you’re too cheap to buy proper hardware.

Giving Your Users What They Don’t Want

I’m leading a workshop in a fancy business building in Lisbon this week, and they have a very interesting elevator system. There are no buttons inside the elevator, but instead a touchscreen outside, where you indicate which floor you want to go to. IMG_2926

And it’s an unmitigated User Experience disaster. I have a master in operations research from way back, and I recognize that fitting people into elevators is an instance of the bin packing problem (literally ;-). With information about everyone’s destination, you can produce an optimal allocation of people to elevators.

But look at the screen above. If I’m on the seventh floor, where do you think I want to go? In 95% of the cases to the ground floor. How do I get there? By pressing the small triangle at the bottom and scolling down to find the ground floor.

This is why engineers should never be allowed to design user interfaces.

Technology Tunnel Vision

I have a favorite presentation that I have been giving at user group conferences for many years. In this, I compare different development tools so IT managers and developers can make an informed decision.

It’s always had a hard time getting onto the official Oracle OpenWorld agenda, because it is about several tools. OpenWorld Conference slots are allocated by track, and each track manager has too few. Therefore, they will only take presentations specifically about their product.

Unfortunately, I’m seeing the same tunnel vision spreading to user groups who should know better. The IT community is fragmenting into separate silos of knowledge with few people with enough knowledge to compare tools.

Technology Tunnel Vision

I just received another rejection letter for my tool comparison from a user group, so I’m happy to point out that the UKOUG Tech 14 conference did not suffer from this, and gave my APEX vs ADF comparison a slot on the APEX track.

Are you one of those who only know one tool? Make a resolution to learn something new in 2015.

Clueless in Seattle – How Amazon Doesn’t Get Mobile

Have you bought a book from Amazon on your phone? Unless you’re uncommonly persistent, you haven’t. The reason is that Amazon is clueless about the mobile use case.

This is how it works:

  1. You hear about a book in some way (social media, email etc)
  2. You open your Kindle app, but you can’t buy books there
  3. If you really want the book, you download and install the Amazon app in the hope that you can buy the book there. No luck, you can’t buy e-Books through their app (!)
  4. If you really, really want the book, you open your browser and navigate to the Amazon website. Which promptly tries to redirect you back to the app (where you can’t buy books, remember?)

Buying an e-Book is the obvious mobile use case: Happens on the go, should take less than two minutes. But Amazon is so blinded by their previous successes that they believe their website and their proprietary devices is enough. It isn’t.

Some organizations do need a mobile app.

Why You Don’t Need a Mobile App

I’ve been discussing mobile apps with several customers lately, and they all seem to think they need a mobile app.

The fact is: Most organizations do not need a mobile app.

Your users might need some functionality available on a tablet computer, but that can be handled with a modern web application. It does not require you to increase the complexity of your technical infrastructure with apps written in new programming languages and managed through other tools.

The only time you really need an app is when your users have many, short interactions (less than two minutes), and these have to happen in a situation where you cannot use a tablet. Are you really in that situation? If not, save your energy for something more useful than building mobile apps.

Do You Know It All?

Last week’s Technology That Fits newsletter (sign up here) stimulated some interesting discussions. I showed the following graphic:

Doomed Projects

Everybody agreed that projects that choose good tools for good reasons are good, and projects that choose bad tools for bad reasons are bad. But some disagreed on Learning and Lucky categories above.

I call projects that choose good tools for bad reasons “lucky”. They are CMMI level 1 – sometimes they succeed, sometimes they fail, and they never get any wiser. I’m not recommending you accept that as a satisfactory state of affairs, but for an individual project, being lucky is enough to pull off a success.

Projects that seem to have good process but make tool choices you disagree on are “Learning” projects. Some people will walk out or loudly complain if their favorite tool is not used. I find that to be a narrow-minded approach. If clever people have chosen a different approach from you, it means you have an opportunity to learn. Don’t think only you have all the answers.

Put Your Parents in the Cloud

If you’re going home for Christmas, you will probably be asked to have a look at your parents’ computer. If they are not already set up for cloud services, make sure you spend a few hours getting all their stuff into the cloud.

For organizations, there are many interesting and relevant discussions to have before deciding whether a cloud-based solution is right for you. But for private consumers, it is a no-brainer that all their data should reside safely in the cloud.

Several people I know in my parents’ generation have had their laptops stolen or lost them due to fire, flood or other calamities. Most of these were not set up for cloud services, which meant that irreplaceable vacation photos as well as important documents and emails were lost.

I’ve set up my parents with

  • IMAP mail with their ISP (they used to run POP3 which placed all mail locally on the machine)
  • Microsoft OneDrive for documents and photos (they run Windows and the generous 15GB limit means that a free account is enough)
  • Google Play (for their music, which did not fit under the 15GB but easily comes under the 20,000 song limit for free Google Play account)
  • Norton 360 for antivirus etc

Make sure you give the gift of Cloud safety this year :-)

You’re Not Here to Write Code

Too many programmers think that their job is to write code. It isn’t.

The job of the programmer is to help the business solve a problem using appropriate technology for the task at hand. The programmer knows (or should know) the available tools and will hopefully select the right one for the task.

Unfortunately, too many programmers suffer from framework-phobia and don’t trust any code they have not written themselves. That takes more time, causes more bugs and will be harder to maintain down the line. Use good frameworks and solve problems!


Useful vs Useless Meetings

As I wrote about in my last post, some meetings are incredibly useful and productive. But, as the Wall Street Journal just pointed out, many meetings are a complete waste of time.

Meeting Contribution

The difference lies in whether the meeting has a clear purpose that is articulated in advance. By making the purpose clear up front, you can also make an informed decision about which people are likely to be able to contribute meaningfully, and which people will just be eating donuts and checking Facebook. Don’t invite the latter group.

The above graph is from this week’s issue of the Technology That Fits newsletter, where I discuss the issue further. Sign up here.