Artistic Meta

With marching orders and a vague foggy vision of where you are headed, you are ready to create the Meta-Project. Not the project itself, the Meta-Project enwraps the actual project creating an environment for it to succeed. The Meta-Project is more of a thought process, something you keep to yourself, in your heart, to guide you to a successful completion. In an earlier post I described how to resolve the utility-cost-speed triad; this is the other half of the mental preparations required to launch a project.

To start you need to create the tone, the environment under which your project will proceed. Sometimes you will need to be methodical and professional, moving slowly with each step well-documented. You may need to get management reaffirmation and written approval all along the way. At other times you may need to create a blender, a whir of activity that juggles six balls at once. You may need to generate enough excitement that your coworkers get overwhelmed with enthusiasm and complete the project for you. I can not give you guidance as to the appropriate tone for you to succeed in your project -- you need to use your intuition, foresight, and knowledge of the culture at your company to determine what will work in your environment.

I usually find it helpful at this point to sketch out figures of my thoughts. One such drawing is a graph of "risk space" -- along one axis I label Risk, and along the other I label Volatility. I then draw circular regions that indicate representations of where each design option would land. Some projects are risky because they have a high probability of technical failure: this may be due to an increased complexity brought about by the interaction of multiple layers of software, or perhaps because the development language itself presents certain challenges of learning and implementation.

Some projects are risky for political reasons: they might for example shed light on why certain business units of a company are performing poorly, or the software may replace the functions of another system that already keeps several staff members gainfully employed. Some projects may be risky because the goals are ill-defined, or no single person has enough authority to assure completion, or the people in authority are themselves insecure and may not be around at the end of the project for support when you need them.

Volatility is intended as an estimation hedge. The risk for any one implementation may run from low to high: if all the factors are well known then the volatility should be low. On some projects you will get the gut feeling that you are in for a barrel of surprises however, where most of the problems will surface during development or after implementation. In this case the volatility is high. "Type 3" projects tend to be volatile, because you can expect to incorporate new technologies and deal with new staff as the project develops. Some small projects can be surprisingly volatile, not for anything inherent in the design process itself, but because of business uncertainty. If the corporation is undergoing severe changes, then smaller projects tend to get swept under the rugs and scrapped easily.

By preparing yourself thoroughly mentally before a project gets under way you will glide through all of the challenges that it presents.

The Art in Courtesy

A typical windows form has tons of small visual cues that you can leverage to provide ultimate courtesy to your client. To start with consider the lowly mouse-pointer icon. You can of course change this to different icons under different circumstances to signal various conditions. Always change the pointer to an hourglass if your process is running a thread that disables user input. Change it to a question mark when they hover over a label, and then provide help about the field when they click on that label.

Use the status area strip at the bottom of a form to show messages about the internal tasks you are performing. These should be detailed enough to provide helpful information should you need to debug a client's problem during operation.

A mouse has two buttons usually... take advantage of this by providing right-click context menus where appropriate.

When you expect data to be entered in a specific format, overlay a graphic example (mm/dd/yy).

Make the effort to disable buttons, checkboxes, menu items, and fields when they are logically unavailable. If a field on a form is required for entry before the submit button can be pressed, then that button should not enable until after the required field has been entered.

Always indicate which fields are required in a manner that is both clear and consistent, yet discreet.

Take advantage of the title bar: it can show both variable words and an icon, and these display when your application is minimized.

When a user hovers over a field, they may be confused about what to enter. You may pop up a short callout of information, or even a callout help-button that will display a sub form.

Finally on any operation that require extensive processing time, display a progress bar showing the estimated time to completion. Run the long task in a background thread so that the user interface can still be moved or minimized. Provide a button to cancel any long-running operation.

Correctly handling all the small visual cues requires quite a bit more effort during development, but doing so marks the difference between a hack and a professional developer.

Artistic Threads

In a earlier post I wrote about how to monitor performance, but how do you plan for great throughput from the start? In the modern world of distributed services and multicore computers you can improve performance considerably by careful use of threading. Before jumping in and firing off threads for everything however, consider when they can actually be of most use.

First, if you fire off a larger number of threads than the cores on the client, multiple threads don't really gain you any advantage. Even with multiple threads started, the processor can only have a fixed number of processors "alive" at any given instant. You won't gain much from multiple threads on processes heavily dependent on SQL back ends either: the database engine already multithreads its queries. But other situations could be good candidates for threading.

If you need to repeatedly call external services for example, or are waiting for data back from remote servers, then using multiple threads can be a lifesaver.

Earlier I wrote more about what to stay alert for to keep your processes threadsafe, but regardless, a general guideline is to tightly manage the quantity of threads that you allow to execute simultaneously.

When you encounter an error in a thread's initiator you need to remember to safely bail out all of the threaded children from their initiator, something that I also discussed in this post. Threads can be tremendous performance enhancers if used carefully and artfully.