The Art in a Demur

It doesn't happen too frequently, but every once in a long while you will get partway into the design stage of a project and run into political interference under the dreaded guise of "company policy." It goes against company policy to purchase abc. It's against the policy to outsource this. Et cetera. And in your heart and in your experience you know that the manner you had planned is the correct method, regardless. For times like this keep this little story in your back pocket; it's a handy urban legend I use to employ just for the purpose.

-----

Back in the 80's a gentleman gained control of an airline in an effort to turn them around from bankruptcy. On one of his earliest flights on his new airline, he flew into Washington D.C. during the middle of winter to meet with federal regulators at the FAA. After his meeting, he boarded a passenger flight on his airline again to head back home. It had sleeted earlier and was now quite cold; the plane sat grounded on the runway. After half an hour, feeling frustrated, the new owner motioned to the stewardess and asked her what the problem was. She explained that, due to the inclement weather, the wings were covered with ice, so they couldn't take off. The gentleman identified himself as the new company president, and asked to leave the plane.

They reconnected a portable stairway exit ramp, and the owner grabbed his carry-on luggage and walked down the stairway and onto the tarmac. He approached the crew chief, identified himself as the new company president, and asked what the problem was. The crew chief explained the icing problem. "Well," the new president answered, "that's easy to fix." He opened up his carry-on bag and took out a portable cordless hair dryer. "Here", he motioned with the hairdryer on, back and forth over the wings. "Just use this." He handed the mechanic the hair dryer and reboarded the plane. After a half hour of de-icing, the plane was able to take off and the new president flew back home. The chief mechanic spread word of how he had been approached by the new president and given instructions.

Sometime later in the year, in the middle of the summer, the new president had occasion to once again visit Washington D.C. After his meeting, he boarded his airline on a passenger flight to head back home. He sat on the plane, waiting for it to leave the terminal, growing more and more impatient. When he glanced out the window, he saw a mechanic, standing on the top of a four-step rollable staircase, gliding a hair dryer back and forth over the wing. He motioned for the stewardess, identified himself, and asked to leave the plane. Once on the tarmac, he walked over to the mechanic, and being angry and in a rush, without even a hello, he tapped the mechanic on the shoulder and asked "what in the hell are you doing?". The mechanic turned to him and said "sorry for the delay sir, but it's company policy".

-----

The moral of the story of course is that just because an important person does something, it doesn't make it a policy. And an action that might make sense to perform some times is not universally correct. So listen to the wisdom in a company policy, but use your noggin and demur when appropriate. (ed. note: I checked with the owner mentioned in the story and he assured me it was entirely fiction).

Artistic Herding

At some point in your career you may be presented with the choice, opportunity or responsibility of joining the technical management team. Most folks who have an ambition toward this (and who are competent people with good technical skills) may find themselves hitting their early management strides by their middle 30s.

The appearance and draw of a management position looks radically different when you're on the climb up however, than when you are actually saddled with the responsibility. Sometimes you hear folks give the old warning "be careful of what you wish for." It's not however, actually as severe a misgiving as all that. It's more like crossing the razor's edge between two distinct and incompatible points of view.

While you're on the upward climb a management position appears as though it could be a good place to share your knowledge and discoveries about how to be a creative professional. Once you're actually there however you often find that your subordinates aren't particularly interested in your opinions, and secondly that you spend most of your time consumed by political positioning, "gaming", and preventing infighting.

What it all boils down to eventually though -- the real guts of the viewpoint canyon -- is a deep social and spiritual divide over the concept and purposes of "work." A simplified way to describe it is like the difference between being a successful feline and being the boarding caretaker for said herd of cats.

From the lone cat's (and lone programmer's) perspective, the objective is to keep your claws (your skills) sharp, to stay light on your feet, to be cautious and curious and aware of the changing environment. You are in a world where you need to hide the mice you discover so that other cats don't steal them. You stay coy and aloof and full of misdirection. Your concept of "work" involves a certain amount of territorialism.

From the perspective of the cat herder you just mostly want to ensure that people aren't spending all of their time picking cat fights. There is some sense of direction and movement you want to achieve, of course, but mostly you want to avoid having the cats bored to tears, sleeping on the job, or scheming for their next kill. You really just want to keep them out of trouble. Your concept of "work" is about the gestalt of your employer.

More about how a manager reconciles these viewpoints in later posts.

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.