The Art in the Vision

Once in a great while you end up in the right place and at the right time in the flowing river of people, companies, and technologies, where you are able to offer a Vision. You know something about a specific technology that your employer can leverage to a competitive advantage. This presents both amazing opportunities and complex personal challenges.

On the one hand, the impetus to share and promote your vision is intense. You know in your heart that it has great value, and if you don't take action on it then after a while it will lose its competitive advantage. At the same time though sharing it puts you in an awkward position with your peers. They may resent what they interpret as your self-important viewpoint, or they may simply be jealous of the attention you receive for your ideas.

Is there a way for you to proceed that doesn't get you laughed out of town? The key to this is actually twofold: first comes the "progressive reveal," and second comes the retained ever-expanding ballast.

To accomplish progressive-reveal you need to explain enough of your idea to the highest person in your company that would logically support you, at a level of detail to convince the listener that this is something you can achieve. You don't want to give away the whole tamale -- don't explain the "how", just the "what." Then assume the responsibility to make it happen. In return get a firm commitment from the person in charge; you will be progressively revealing more of the "how" as the project proceeds.

Once you actually unfold your idea into reality you will need to expand some "ballast." The ballast is the counterweight that keeps control of the idea's implementation from floating away from you, and prevents the debt the company owes you from sinking your soul. The method to accomplish this varies, but generally always remember that "control" provides the compensation for the actuarial value that you create.

Of course there is a managerial "flip side" to this process as well: how to create an environment that allows your most savvy employees to instantiate their visions, but that is a topic for a later post.

Artistic Patching

Most of the time when you're developing software you get buried in writing code to flesh out a bunch of business requirements, you set up a test desktop environment, and then slave away and work through the bugs. Then you tie up a handful of loose ends, catch up a bit on your documentation, throw together some training notes, and then finally the big install. Ach, it doesn't work in production. Nothing can be more frustrating.

You go back and check your setup notes, make sure all your key tables have the right data, make sure all the network paths are mapped and exist, triple check your configuration file settings, and still no-go. What the heck could it possibly be? All the DLLs look correct, all the web services are up, and as far as you know all your cohorts installed their respective pieces.

When you have reached the end of your rope it's time to think outside the box. And the part that you are overlooking is simply this: you need to apply all the service packs and Windows Updates on the production boxes. Yeah the SQL service packs as well.

At times it seems like a royal pain to hassle with software infrastructure that works as the foundation that you seldom actually think about. But the whole reason that you have development tools that have the power that they do is because they build upon this humongous hidden foundation. Do you want to avoid installation problems? Practice the art of keeping your core software fully patched.

More Art in Change

Business rules change and you will need a way to accommodate that. To maintain system resilience and modular compatibility you must however avoid certain habits; here's how. The four secret words are inheritance, overload, deprecation, and propertizing.

These are pretty standard concepts in the object oriented world, but using them correctly takes a bit of discipline. Part of the issue is that post-hoc seat of the pants changes are a poor excuse for thoughtful refactoring in the first place.

For example say you have a routine that estimates a car's mileage based upon a single measurement plus a date of measurement. This gets implemented as myCar.getCurrentMiles. Now your company wants to change the method to use two measurements and two measurement dates instead. How do you proceed?

Look at all the options and consider what they buy you, but also consider what they break.

The first and easiest option is the overload. You already have myCar.getCurrentMiles (measurement, date), now in the same class you add myCar.getCurrentMiles(measure1, date1, measure2, date2). Of course this new method starts out with the code that used to be in the old method (have the old method call the new method with null values for the second measure and date).

External calls using the old method will still work, and developers coding for this method will see both signatures in their intellisence pop up. This does have the drawback however of failing to provide much to the consumer in the way of choosing the newer signature of the method over the older. When to call it with one measurement, and when with two? More about the other alternatives for handling change in a later post.