Migrating technology

I've been thinking a lot about extending the life of a software system.   There are several hard problems to solve.  The first problem I want to discuss is migrating to a new technology stack.  I'm skipping the discussions that take place before the decision to transition to a different technical stack are made.  Whether that decision is good or bad, if it has been made it is your job to get it done.

Consideration #0 - Don't do it all at once

Big rewrites are very likely to fail. So don't try them.  Learn from our collective Agile experience and establish a backlog for your migration.  You will learn a lot from planning the backlog, such as business and sales pain points, architecture dependencies, and areas that don't require immediate attention.  This gives you the advantage of putting new technology into the market faster, further accelerating your learning feedback cycle.

Consideration #1 - Build new features in the new technical stack

While straightforward to understand, this is perhaps the most difficult to implement.  Your end user work flows have to be (relatively) seamless.  The existing system was designed to support a collection of end user goals and workflows.  If the new feature is presented is a jarring manner, you risk putting your users off.

A few years back, my team was challenged to move from Delphi to .NET.  We found ways to render .NET screens inside Delphi containers.  Although we used different component libraries, an end user had to be extremely astute to notice subtle control rendering variations.  A more recent experience involving more disparate technologies has required some visual redesign of the existing application to reduce the perception gap.

Regardless of your technologies, you have to make the user experience transition as seamless as possible.  

Consideration #2 - Rewrite parts of the existing system when appropriate

As your existing system requires modifications, determine if the feature to modify is a good candidate for being rewritten.  Again going back a few years, we were faced with a major overhaul to government reimbursement for Home Health services.

Instead of modifying the existing (tried and true Delphi) payment system, we left it alone.  We wrote the new billing engine in .NET.  This allowed us to guarantee no regression to existing billing and to add significant capability in the new system.

Consideration #3 - Accept that some stuff will remain around for a very long time, maybe forever

This can be hard to accept.  Engineering, and I suppose business, is about choices.  Those choices involve what you do and what you don't do.  There are parts of your system that work, are reliable, and aren't causing you lost sales.  Before you rewrite those pieces, have a compelling reason to do so.

In general, your goal is to devise a scheme to migrate to the new technology over a reasonable period of time, incrementally, with little impact to your end users.  I know this is hard.  But it is possible.  The alternative - a massive all-or-nothing rewrite - has proven again and again to lead to failure.

Understand old solutions to solve new problems

In my last post, I ended with a comment about the importance of understanding solutions in order to solve a broader range of problems.  Problems have an essence.  If you understand the essence of a problem, you can draw from solutions for that class of problems.

Consider the problem of managing vaccination history for a patient.  Take a moment to enumerate the essential characteristics of this problem. Can you think of systems you have seen or used that address problems with similar characteristics?

What would you say if I told you that tracking vaccinations is a very similar problem to your vehicle’s recommended maintenance schedule?  If you don’t believe me, next time you get your oil changed, ask to take a look at the screen the service manager uses to upsell you on a new air filter.  Replace each recommended service with a vaccination and you should see what I mean.

Experience with and exposure to varied solutions is important.  However, it is not enough.  You must internalize the relationship to the problems they solve and the essence of those problems.

Here is an approach that may help:

1. When you use tools (physical or software), identify the problem the tool solves.  Ignore the features – focus on the problems.  For example, don’t think of a hammer as something to “Drive a nail into a wall.”  Think “Deliver force to an object.”  
2. When solving a problem, tease out its essence.  Find solutions that solve problems sharing essential characteristics.  For example, replacing the lid on a paint can requires the use of directed force to seal the canister.

Go out and build an inventory of solutions and the problems they solve.  The larger your solution inventory, the broader the range of problems you will be able to solve.

Drive

I recently received an e-mail relating how certain programming constructs look elegant, but turn out to be grossly inefficient.  That got thinking about abstraction frameworks and how they increase perceived development speed, yet can have unintended consequences (performance being a big one).  That, in turn, got me thinking about why the guys on the thread could immediately spot the underlying inefficiency through visual inspection.

Are they inherently smarter? Maybe.

Did they screw up a similar project and learn? Possibly.

Are they driven to understand how things work at a fundamental level? Check.

What separates these guys from the huddled masses is an innate drive to understand their world (in this case, software engineering) down to the ones and zeros.  I’ve sat next to both of them while they code.  They have debuggers, output windows, browsers inspectors, and SQL execution plans running well after typical developers would have committed the code.

They have a drive to know their code is correct, fast, and readable.  They dissect it, improve it, and test it.  If someone is going to break their code, it will damn sure be them, not someone else.
But you protest.  Surely, they must not understand deadlines!  Clearly, they take longer!

You protest in vain.  These guys are among the most productive guys I’ve worked with.  Their code is clean before they release it.  There is rarely rework.  Because they have spent so much time understanding their tools, they avoid mistakes made by developers who focus on getting it done and checked-in.

Their breadth of understanding allows them to quickly select appropriate constructs and patterns based on the problem.  Contrast this with developers forced to solve problems based on what they know versus the nature of the problem itself.  More importantly, their depth of knowledge allows them to know why their solution will work and what its limitations are.  Most developers won’t fully understand why their solution works. Or what problems it can’t solve.

I’ll leave things here.  I plan to return to this last paragraph in a future post.

Free to be crazy

I’ve been thinking about why I am comfortable throwing out crazy ideas to my team. I don’t think it is solely my lack of concern about appearing foolish (although there is an element of that).

I’ve repeatedly told my team – everyone, not just managers – that one of their most important jobs is to keep me from making bad decisions. I need to know that I am going to get honest feedback from everyone. This gives me freedom to come up with crazy ideas without fear they will be accepted simply because they came from me.

How do you get the team to a point where everyone believes they can safely share feedback with you?

• Reinforce the need to know the truth from your staff. Encourage people to challenge you. They may not do this initially. After all, you are the boss.
• When you propose an idea, actively solicit input in public settings: “What do you think?” “Is there something I am missing?” “What would you do?” It will take time. If you keep asking, people will start to use their voice.
• Once people find their voice, listen. The ensuing dialogue is the reinforcement needed to move your team into a positive feedback cycle. Use this time to explore your idea, tear it apart, defend it (without being defensive), and find viable alternatives.

I have found that most of the time there are only a few outcomes (in descending order of occurrence):

• I realize I am crazy and I’m grateful that we didn’t act on my idea.
• A kernel of goodness is contained in my idea and the interaction results in a much better idea.
• I actually had a pretty good idea after all.

Remember, you aren’t trying to be right. You are trying to get to the best decision for the situation. Your job isn’t to be right – it is to make sure the right decisions are made by the team.

One last consideration. If you never accept the feedback, then you have two problems. Number one, your team will stop offering it. And two, you aren’t really interested in hearing it – which is why number one happens.

So go out and be crazy. Something good is sure to happen.

Argue your way to good decisions

If you observed my Friday afternoon leadership team meetings, you might think we are the most argumentative bunch of folks on the planet. And with good reason.

We are.

You might further think we constantly fight, back stab, and never agree to anything.

You'd be wrong.

Respectful disagreements
From the time I interviewed and recruited the team, we've interacted with respect. During interviews, I challenged their beliefs. I wanted to know how they handle a differing opinion by someone "in authority." Could they defend their position without becoming defensive? Could they acknowledge a counterpoint even if they didn't agree?

I didn't ask the "Tell me about a time when you disagreed with your boss" question. I wanted to disagree with them and see how they reacted. If you are going to do behavioral interviews, then you might as well elicit behaviors.

One important point. Even in heated discussions involving critical decisions, we maintain respect. We don't throw things; we don't shout; we don't name call.

High Standards
Every member of my leadership team is excellent at what they do. They have selected each other as much as they've selected me. We expect the best from each other and push each other. We don't want to let each other down.

Keep this in mind when you recruit. I've found that if you hire wrong, the team descends to the lowest common denominator. Hire well and your team rises to levels of achievement unreachable individually.

Confidence
What type of person is better equipped to be wrong and make a change? One with low self-esteem or one with high self-esteem?

Correct - high self-esteem. If we felt that our self-worth was tied to being correct, we would never get to problem resolution. We would be too busy defending our self-esteem.

So what does all this lead to (other than ending a sentence with a preposition)?

Freedom.

Freedom to acknowledge a better idea. Freedom to ask for help. Freedom to admit a mistake. Freedom to learn from each other.

What matters is that we arrive at a good decision. Equally important, it is a decision that has been argued, ripped apart, challenged, and extensively reviewed. When I walk out of the room, I'm confident a good decision has been made.

That is why I love leading this group of argumentative folks.

Risk versus perfection

I was recently asked how I can encourage my team to take risks, while simultaneously driving them to perfection. “After all”, the questioner posed, “doesn’t the drive for perfection inhibit risk taking?”

It was a terrific question. I was not able to answer immediately. With the benefit of a few weeks of thought, here goes.

First, I don’t ask for perfection. I ask for excellence. This is an important, subtle difference. Excellence is the attitude for approaching a task. Excellence is:

• Driven by personal investment to deliver a quality outcome
• Attention to details without losing sight of key principles
• A commitment to deliver what one agrees to deliver, when promised
• A passion for delighting the recipient of the deliverable
• An understanding that every part matters, from the highest detail (functionality, visual design) to the lowest detail (alignment, colors).

Taking risks, on the other hand, is trying something with an uncertain outcome. Risk taking is:

• A willingness to explore options, even if the result is failure (it never is, by the way)
• An ability to judge potential gain versus potential loss
• Trusting one’s intuition

Taking risks and excellence are not mutually exclusive. Taking risks is about choices we make. Excellence is the attitude we have when executing those choices. That is, once I choose to take a risk (change partners or technology, for example), the decision must be executed with excellence.

Sending a human to the moon was a risk; it was performed with excellence.

Encourage your teams to take risks. And expect excellence in all they do.

Resumes: Views from a hiring manager

I’ve been fortunate to grow a team significantly in the last year. To achieve this, I’ve had many screenings and interviews. This process led to the following observations.

Focus your skills list
Just because you programmed in Prolog twenty years ago doesn’t mean it belongs on your resume. I am put off by a resume that list dozens of languages, operating systems, and tools. It leaves the impression you can’t self-assess your strengths. Secondly, it doesn’t allow me to determine the technologies you actually know well.

You might say, “I list my skill level for each technology!”

Strike two.

Can you really say that you are 4 out of top level of 5 in C#, C++, Java, Perl, Ruby, PHP, SQL, OOP, MVVM, MVC, M-I-C-K-E-Y M-O-U-S-E, Agile, and Waterfall? Yes, I’ve seen this type of listing repeatedly. No they didn’t get a call.

Anything you put on your resume is fair game. If you haven’t used something for years or you have only dabbled, you won’t discuss it well. That can only hurt you. If you list something in this category, acknowledge it was a while ago. And rehearse why you still mention it.

Highlight strengths
List your strong skills that match the job for which you are applying. Eliminate everything not relevant to the job description. If I’m looking for .NET C# with Visual Studio, then Java with Eclipse isn’t necessarily going to help. There is an exception.

If you have substantial domain experience (e.g., Healthcare), then highlight it. Domain experience is often more valuable than technical skills. In this scenario, drive home the domain experience while acknowledging that you used different technology.

Demonstrate that you understand the external environment and are self-aware regarding your technology skills. Then highlight (through examples) your ability to acquire new skills and obtain a level of excellence with them.

Closing thoughts
Tune your skills list to the job description. It is better to identify a few skills you know well than to dilute precious interview time on average or weak ones. And remember, knowledge of languages and tools isn’t the only deciding factor for hiring someone. Your attitude about learning and passion for software are as much a factor as experience and skills.


Be ruthless with what you put on your resume. If you don’t, I will.