Juixe Techknow

As the saying goes, if a thing is worth doing, it’s worth doing well. It has been proven that doing a thing right the first time is most efficient and cost effective. But what is the cost of doing something wrong? In terms of money, I’ve seen cases where something is done incorrectly and then had to redone at a loss of $100k. In terms of time, you can model it in the following thought experiment.

If a task takes x amount of time to complete and it is done wrong the first time, how long does it take to fix it?  More than 4x. It takes to x amount of time to complete the task the first time, probably at least x amount of time to find out it was done wrong, another x amount to figure out what the first guy did, and finally x amount to fix it correctly.

We all can agree that time is money and if a task is done incorrectly it may cost at a minimum as much as four times as much as it would cost if done correctly the first time around.

I have over 100 iOS apps in three different devices, an iPod running running iOS 4.2, and an iPhone and iPad on iOS 5. As much as possible, I always sync all devices to my laptop so that they all have the latest updates. I know that since iOS 5, apps and songs purchased from iTunes on one device will automatically sync to other devices. That said I still find that I have sync for other reasons, to transfer photos to iPhoto and sync a large number of podcasts I listen to. And perhaps, most importantly, I’ve sync to charge my device. One issue, definitely first world problem, I have with having multiple iOS devices is managing all the apps in the different devices. If I delete on app from the iPad, it doesn’t delete it from the iPhone. If I delete it from the iTunes on my laptop and I sync with a device that contains that app, it will copy it back to iTunes.

Another big issue is that you have to configure your app pages and folders on each device. If you spend an hour organizing your apps into folders and pages in one device you have to re-do it all over again on the second device. What ends up happening is that you’ll have two devices with the same apps in different pages and folders.

What I am missing from my mobile experience is the ability to sync, not only the apps and content of apps, but the meta-data about how I organize apps between iOS devices. I want to have the choice to clone how one iOS device organizes and layouts the apps to other devices. I would also like the ability to have different app layout settings, such as have the iOS device automatically put applications into folders based on the app category or my usage of the app. And of course, I would like to have a way to delete an app from one device and have it disappear from all other devices.

Processes are supposed to support people, not people support processes. A process should be documented in one document or checklist or directory or wiki or website that everyone has access to. Everyone should have a copy readily available. It should not be outlined in emails or sporadically over several documents across different locations. Always review the process and remove friction. Try to minimize steps when possible, centralize the information, anoint clear responsibilities, build in safety nets, empower developer to make decisions, let it grow as the team grows. Automate the process as much as you can, make reports people can use, make everyone’s progress visible. For some certain teams, there is diminishing returns for adding more processes.

Software users didn’t take Knuth in college and you should not expect them to have a Computer Science degree to understand how to use your application. There is no worse assumption that a software programmer can make than to assume that end users know what you are talking about, especially when there is so much miscommunication involved in specifying, designing, implementing, testing, and releasing a software application within an internal team. Your users don’t understand your language, they don’t understand what you mean when you say object-oriented, exception handling, concatenated document, application server log file, null pointer, database query and they don’t care so don’t use these expressions in labels or descriptions in your UI! If you have to explain your User Interface to a end user, your are doing usability wrong. Forget leaky abstraction, there is nothing worse than leaky implementation details in your UI. If your users have to use suspended disbelief and take your word for it to understand how your User Interface works, you should go back to the drawing board.

One of the reasons why the User Interface and User Experience is so horrible in applications, especially internal and enterprise applications, is that they are done by programmers, usually prototyped quickly, and shipped soon thereafter. The truth is that programmers have to wear multiple hats, depending of your company size, these included tester, computer programmer, domain expert, UI designer, type editor, IT, security guru, database administrator, system architect, document writer, and more. In addition of having to fill all of these roles, there usually must be done in a tight deadline with many technology risks, unknown factors untested partners, and already late dependencies.

The simple fact is that the more hats a programmer wears the less productive he will be. If you have programmer having to manage your version control system, update your application UI, and debug memory you are not getting your monies worth. The more hats you have developers wear, the more time it will take to context switch, the more time you spend tracking down issues, and the more you pay in the end.