Emerging Tech

When do you let go of a technical dream?


Last Friday's entry will come late. In

fact, it will show up on Wednesday. Sorry about that; I ended up

flying to Colorado, working on my house out there, then driving back.

Something about all that took the wind out of

my sails. Still, it's a good entry containing juicy stuff about dealing with the demons of the past and other

dramatic statements.

Fortunately this Monday passed with a

lot less drama than last week. At least, it passed with less surface

sound and fury. The actual impact of today's decisions, especially

if we carry them forward, promise to be profound. Like all profound

things, though, they take a bit of getting used to. Some people

might not even notice them at first, but will instead sense a change

of pace they do not quite comprehend.

Yesterday, you see, we let go of a dream.

Our leader had the wisdom to, subtly, point the way to another

possible dream, but I doubt it will make much difference at first.

It never really does.

I make no apologies for both leading

and acting as a member of highly technical teams. As such, our

professional dreams tend to focus on implementing particular

solutions chosen from the “solution wheel” to address

architectural functions or business problems. Given my own

background I find the architectural bits far more exciting than

dreary business logic, though I can see the appeal of helping people

resolve their work related issues.

The dream we let go of was no

exception. It was, in fact, a very sexy solution to the rather dirty

business of getting access to client business logic in a health care

environment. Fighting with old applications, shoddy code, and

“standard” equipment that fell out of the manufacturing cycle

years ago doesn't always lend itself to technically sexy solutions.

When one comes along, its easy to fall in love with it. And fall

hard for this one we did, though pain and travail the likes of which

only a dreamer could love.

Unfortunately, that travail proved the

dream's downfall. It's one thing to champion a technology which only

beats up our own group. We can take a little pain, or even a lot for

a short period of time, to bring an important new technology into the

environment. It's another entirely to deal pain to the rest of the

organization with limited or no return and very little end in sight.

This becomes especially true when we fight incident after incident,

resolve issue after issue, without solving the fundamental problems

the dream introduces.

So, it falls onto the leader's

shoulders to finally make a decision. When do we draw the line?

When do we stop supporting something we want so badly we can taste

it? When do we spin the wheel of solutions again to find a better

resolution to whichever architectural function we need to address

this quarter?

You have to start with data.

Information about the number of incidents is a start but hardly tells

you the story. You have to dig into it, discover which issues fueled

those incidents, how quickly we could produce know issue statements

and work around, and finally how those issues tracked back to

fundamental problems. How much of our work was self-inflicted –

i.e. The result of our efforts to support the solution rather than

address the architectural function? How much of our clients' time

and the business logic side of the house's resources did we waste

trying to keep our chose solution up?

From there, its time to set some

metrics and make the unpopular calls. How much is too much? How

much pain do you inflict? Given what we do for other teams, its

reasonable to expect the business logic groups to help us out but

when does it shift from asking for support to throwing them under the

bus in the name of our goals? All architectural changes involve a

good bit of pain and suffering though problems, but when do you

decide it's one step forward and two steps back?

Finally, and least popularly, when do

you re-prioritize the effort? When do you decide the resources,

time, and energy expended were all for nothing? How do you convince

others, especially those who bled to make the dream a reality, that

its time to move on?

That last question keeps me up at night

sometimes. Data isn't sufficient; being right does not make the

emotional and financial commitments go away. It doesn't resolve the

political issues created by supporting a solution you ultimately had

to abandon, or the sense of frustration from the allied teams as they

watch their time investments slip away.

It's a tough call. I wish I could have eased the way to making it.

We'll just have to see what happens next.

Editor's Picks