More Hats, More Problems
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.