“You can check out any time you like, but you can never leave” – Hotel California by The Eagles
That feeling is what many organizations are experiencing once they have jumped onto a cloud service. It can be hard enough to changing a major on-premise system – just think of the huge costs and time expenditures of Oracle-to-SAP and SAP-to-Oracle stories occasionally in the news. But once your data live in the cloud, it can be almost impossible to get them out.
Before you sign up to a cloud service, make sure to run a trial period and test that you can make a complete data export. Open the file and check that everything you put into the system is actually in your data export, together with all the necessary information about which records are linked to which. If your prospective vendor does not offer a complete data dump that you can automatically pull at will, look for another vendor.
If you do sign up to a cloud service, establish an automatic procedure to retrieve all of your data regularly. This is the only way to be sure that you have your data if your cloud provider goes under, or if all of their servers are impounded because they happened to be running in the same datacenter as a suspected terrorist.
Make sure you can actually leave.
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.
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)
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.
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.
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.
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.
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.