Principles of Efficiency
Example
There's no time like the present to build automation. I've personally never regretted automating a solution, but I've often regretted doing something manually rather than building a process.
Start working smart now, not later. You'll thank yourself.
Don't do something twice. Cache the result and re-use it; you'll use more memory, but if it saves you an expensive operation (disk, database, network), it'll pay for itself.
When working with developers, remember that they need two things: input, and the desired output. Generally, you should leave the processing in between up to them, that's where their expertise is.
Focus on what's important. Allow the little things to float by with minimal process, that's OK as long as there's enough tracking that you can find out what happened, and when, if you need to some day. But remember that you probably won't.
Minimize mouse movement. The keyboard is almost always faster, as long as you're working with text or data and not images or video.
Be organized. Use the tools you have to organize files (or e-mails, or photographs, or stool samples) into folders, or better yet tags. Never save a file as "Document1"; you might think you'll never need to find it again, but if you're wrong you'll suffer for it.
Principles of Respect for Customers
-
Do not clutter.
Don't put crap on users' desktops without asking, and don't even ask at all unless there's a significant likelihood that someone will actually want YOUR app cluttering up their picture of a cat in a boot.
- Do not spam.
Don't have "send me spam" checked by default.
- Be secure, but not difficult.
Don't store customers' passwords in clear text, don't have unreasonable rules on password content, and don't make them get a court order to reset their passwords.
- Don't have arbitrary limits.
Don't assume you know what your customers want to do or how much space they'll need. Don't restrict them to nine header types, 256 columns, or three saved games; let them go as far as they like, or until you run out of memory. If you must set a limit, for example a field length in a database or an integer type in an application, take the greatest number you think they could possibly want and multiply it by two to ten.
Principles of Style
Mixed case is easier to read than all lower case, and all upper case is damn difficult for the eye. Underscores can help break up words, but on the whole PascalCase and camelCase are almost as easy to read, and significantly shorter.
Symmetry is easier on the eye than assymetry, which is why same line opening braces are ugly.
White space is very important, but don't over-do it. Gulfs of white space can make it difficult to see where braces match, for example. Indent enough that you can easily see what's been indented, but not so much that you waste excessive amounts of horizontal space. Remember that a line that runs off the right margin is harder to read and understand, it makes end-of-line comments nearly useless, and does not print well.
Use international standards for dates when coding; use the OS settings when displaying.
Principles of UI Design
Read. Read widely and often, so you can integrate all the good ideas and discard the chaff. Visit a lot of web sites, and pay attention to what works and what doesn't. Two of my favorite sites are Google and Wikipedia: they give me a world of information, in an uncluttered way, and with their search features I can find what I need in a quick and intuitive way, rather than frustrating layers of folders.
Here are a few sites I've found to be helpful:
You'll build your own idea of what works. These are my thoughts.
- Clarity is your first, second, and third priority.
Computer programs are made up of inputs, processing, and outputs. An effective UI makes it clear what inputs are in use, what the current progress is, and displays the outputs efficiently. Too much data is overwhelming, so focus on what's most important and ensure that it's visible, then store the rest in logical thematic groups.
- Be responsive and remain responsive.
People are an impatient lot. If your app runs for more than a few seconds, it should identify itself as being busy. If it might plausibly take more than ten seconds, provide a progress meter and a cancel button. Serious apps should have separate threads for the UI and operations, and possibly a new thread for any task which is likely to take significant time. Any task that can easily end up in a loop should have a timeout feature.
- Handle exceptions gracefully.
Catch exceptions, especially in sensitive areas such as file access, network access, and memory allocation. When an error occurs, give a meaningful error message, and suggest possible problems ("That file was too large to upload; try something smaller.").
- Prettiness matters.
People respond subjectively to an app, just as they respond subjectively to everything else. Sure, in the long run they'll lean towards effective over pretty, but don't handicap yourself if you don't have to. Line up your controls nice and neat, use plenty of white space, and pay attention to colors and layouts.
- Allow customization.
Part of what made Office successful was that power users could rearrange their menus. Your top priority is to get to the best possible interface, but if you have extra time it's also helpful to let your users make things personal. A little bit goes a long way: remember when screen savers were all the rage, back in Windows 3? Windows 7's best selling point for non-savvy users is automatic rotating desktop backgrounds!
Example: Allow users to apply their own labels to high-level objects. This is less important when working with files, as there is an existing organization for them, but if your application handles, say, database connections, it is much easier on the customer to work with "Production" and "Development" than some long obscure abbreviation decided by the IT department six years ago.
Side benefit: if your UI is customizeable, you can more easily accomodate the colorblind and visually impaired.
- Remember settings.
When the user repositions windows or adjusts column widths, it because doing so allows him or her to use the tool better. Store their setting and recall it when the application runs again.
- Be consistent, externally and internally.
Don't reinvent basic interfaces. If your application includes windows, put the Close button in the top-right corner; if your application loads or saves data to file, make the shortcuts Ctrl-O and Ctrl-S, like every Windows application under the sun.
Be internally consistent. If V is the code to switch to View mode on the main map, use V to switch to View mode on every other screen too.
Use space consistently. Put OK on the left and Cancel on the right, on a Windows system.
- Write useful help files.
"Press the Save button to save your data" is probably not going to help anyone. Your help content should address real issues: explaining unclear commands (could they be made clearer?), limits and gotchas (if they can't be coded away), and strategic considerations.
- Don't be obtrusive.
Modal dialogs should be a last resort, for the most critical of error messages. For anything else, let users open and populate dialogs as they like without forcing them to close any. For non-interactive messages (i.e., notifications), put them in a status bar or message queue, rather than interrupting the user's flow with a big ugly message box.
- Use white space, especially between disparate commands.
Put a small gap between items, so that an ambiguous click doesn't select the wrong thing. Don't put "Delete" right next to ANYTHING.
On the other hand, it rarely makes sense to put white space between a button and the edge of the screen; remember the "mile-high buttons" controversy?
- Save automatically.
Most programs require one to take an extra step to save their work. This is a legacy of the days when this entailed swapping out disks (or tapes!) and it took a long time; for most programs today, it should just happen, automatically, in the background.
There can be exceptions; a user may want to poke around in a word processor or spreadsheet program without necessarily saving their changes, but in such a case you should at least autosave to a file, and then give the user the option of keeping the original version or the saved version.
- Learn about the eye and visual attention.
Example
Have you ever noticed that most large corporations use blue for their logo and/or the key color in their ads? The top 10 companies on the Fortune 500 for 2010 are Wal-Mart, Exxon, Chevron, GE, Bank of America, ConocoPhillips, AT&T, Ford, J.P. Morgan Chase, and HP. Three are all-blue, four are primarily blue with some red, and three are black and white.
Use lines to connect and to interrupt. Use color as a highlight, but use it sparingly. Use bold bright colors to be eye-catching or subdued colors to be calm and comfortable.
- Let form follow function.
UI is not an exercise in self-indulgence or an excuse to wear black and use French words. It's the art and science of finding the design that will best meet the customers' needs. Arrange controls in the order they'll be used. Use size and location to indicate prominance. Use color and style for highlights, but don't overwhelm the user with purdy pictures and slick widgets just because you can.
Principles of Rewriting Code
Document. Expand upon the existing documentation, starting with notes where a comment needs to be confirmed.
Test. Build a testing rig that the existing code passes. You can add more tests later to see if your extensions work, but if the old code crashes when fed character code 127, then build the first test so it only uses character codes zero through 126. Remember that your first priority is to clean up the code without actually changing anything; if you jump the gun and start fixing things before you've refactored and built an understanding of the code, you may break something.
Refactor, using the tests to be sure that you're not breaking anything. Start with small adjustments; when you understand the code better and can confidently say "This does that" you can consider larger changes.
- Clean up function and variable names
- Hide fields that are insufficiently protected
- Organize code into coherent modules
- Create interfaces and modify cross-module talk to use them
- Create classes for simple objects, like file handles
- Create classes for complex objects, like database layers
- Where absolutely necessary, re-write from scratch, but maintain the old tests
An alternative is to build a clean code layer on top of the old ugly code, if it exposes a decent interface.
Principles of Organization
Organize on the basis of date, but don't confuse names with dates. If a project is named XYZ and initiated on 2001/02/03, that's two pieces of information. Don't conflate them by naming the project "2001-02-03 XYZ".
Principles of Communication and Management
That whole "vision thing"? Yeah, it's a real phenomenon. Sometimes an organization has all the right people in place, and they all know what the problems are, but someone has to stand up and say "let's do this". Whether you're trying to decide where to go for dinner or steering a multi-billion-dollar company, you need a leader to be effective.
An employee will be secure if he knows what he's doing and has some idea as to why; if he has confidence that his boss knows what he's doing; and if he believes that he's making a material contribution to the group. Without these factors, he may worry about whether he's important to the company.
Everyone gets satisfaction in different ways. Some like to lead, others to follow. Some just want to be heard, others are not happy unless their ideas are implemented.
Successful organizations need intelligent people. Intelligent people need variety.
Three things lead to exhaustion: an excessive workload, a lack of hope for improvement, and repetitive work. To get the most work out of your staff, you need to maintain a realistic load and not burn people out; you need to spend at least some time planning for better days, and incorporate your team in doing so; and they need to be able to switch tasks from time to time, ideally when they choose to. For example, switching between blue sky creative thinking, intense problem solving, and zen "in the zone" routine provides a refreshing change of pace.
In communication, consider what the recipient needs to know. Our instinct is to share what's relevant to us, but this is often not relevent to the listener. What does he or she need to know? Give that and don't waste breath on the rest. Note that this is for business settings; in personal correspondence, filling the air is kinda the point.
Each specialty in an organization speaks a different language. Marketing, sales, and engineering are as different as C#, sign language, and ancient Egyptian. A skilled manager learns to translate, and minimizes the risk of missed translation by serving as a conduit between business units. You are the bus, accepting input from each source, performing translation and buffering, and passing on output to each destination.
Parrotting is a simple but effective way to ensure that communication is successful.
Cushion your deadlines. Front-load projects; do NOT assume that things will lighten up later, rather assume that you'll be hit with additional work. If it doesn't happen, you can deliver ahead of time.
Take on the most complex and uncertain parts of a project as soon as possible. If they turn out to be more difficult or time-consuming than you anticipated, better to find out sooner than later. You may be able to negotiate more time or resources.
Feedback is critical. Most customers would rather have a product delivered six weeks late, but get a personal update every other day, than one week late without notice or explanation. Just leeting them know that you're working on the problem will make them feel better.
Other people in your company are customers, too: internal customers. Treat them with as much respect as external customers, and even more openness and honesty.
If you ignore an underling, they'll do some combination of four things:
- Ask you for instruction. This is generally the best outcome, though even better is if you pro-actively keep in touch with all of your peeps and ensure that they're well-occupied.
- Keep doing what they've been doing. Fine and dandy in the short term, in the long term this strategy results in a loss of effectiveness. Most people who take this approach will gradually become less effective, as the work they actually do and the more important work they should be doing will inevitably diverge.
- Quietly stew in their own feelings of neglect. He or she may start to feel that the work must not matter, or that the boss (this means you!) doesn't care about it, and by extension, doesn't care about the employee. Morale will deteriorate, and you'll see an increase in defensiveness and pettiness.
- Act on their own initiative. This could be good if they have good ideas, but given that you're The Boss, it's assumed that you have the big picture in mind, more so then they do. While you certainly shouldn't squash initiative, you should at least help direct it.
There are exceptions to EVERY rule.
If it seems absurd, question it. If it is absurd, perhaps it can be improved. If there are good reasons for it to be the way it is, you'll benefit from knowing why.