Big rewrites: Summing things up

My last several posts dealt with migrating technologies, people, and skills considerations. Certainly, a few posts can't do justice to something as complex as a system technology refresh.  On the other hand, there are a few principles that can be helpful guides as you navigate the the complexity.

• Iterate
  If possible, break the rewrite into smaller chunks.  Determine the smallest amount of business value you can deliver and start there.   This allows you to stay focused on software delivery fundamentals and to use the new technology in the real world.  Release management, branching and merging, and patching are just a few of the processes I've seen atrophy after years of rewriting software without a delivery.
• People
  A blended team of existing folks and new hires is desired, but comes with issues that require supportive, yet firm, management. The technology transition is going to happen - that is where you must remain firm.    It is not reasonable to expect your existing team to learn a new technology stack in the context of significant business implications.  You will have acquire skills and that will cause friction.  These new folks have to be integrated into a new, combined team.
• Skills
  The existing team members are a key to success due to expertise of the system, customers, and industry.  Your commitment to their education, skills, and to be blunt - employment, is the supportive aspect. Show them how they will participate in the transition itself, as well as their contribution in the new world after the change.  Provide them a picture of their role after the new technology is in place to assure them that they aren't helping the "new folks" build the system that is putting them out of a job.

These principles provide you a start at identifying the core issues you will face regardless of technology or industry.  For example, iteration is simple in theory.  In practice you have to address factors such as, "What is the least meaningful value I can ship to the market?", "How can I deliver 'less than everything' alongside existing software?", and "How long do I really have in the market with the existing product?"

The questions that follow from the principles are the real power.  Conversations surrounding the questions and their answers will do more to increase project success than all the project management during the project itself.  After all, if you don't have the right skills, your team is demoralized, and the project is a multi-year science project, your project status reports are going to be the least of your worries.

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.

So you want to be an architect

Over the last year or two, I’ve spoken with a handful of developers about their career. Several of them desire to become software architects. I’ve never really been satisfied with my guidance to them.

With apologies to them for my poor initial responses, here are attributes I look for in an architect.

Be a coach and mentor
You might think technical excellence should be the first item on my list. While it is a requirement, it is not sufficient to be an architect. What matters is one’s ability to coach and mentor others to higher levels of achievement. A highly technical individual who cannot coach and mentor is not an architect. She is a highly technical individual contributor.

Architects build large systems through a team. So while the architect may be the most technical, he must maximize the output of the team as a whole. Some examples of coaching and mentoring:

• While reviewing other’s work, look for opportunities to praise good practice and to demonstrate improvements in critical thinking skills. It’s not about showing a better way to implement a specific module. Use the opportunity to teach a better way to think about the problem and possible solutions.




• Share your knowledge with the team. Use every opportunity to share not only your technical decisions, but options you considered but eliminated. Help your team understand how you made the decision, not just what the decision was.




• Expect your team to have great ideas. You don’t have to be the smartest all the time. You cannot expect your team to be willing to learn from others if you won’t.

Desire to learn
The best architects learn constantly. One monitor has Visual Studio open and the other has a blog about some piece of technology.

Take time to read, study, and practice.

I’ve known architects who spent personal time developing programs to exercise one or two language features. They may not need it immediately, but at some point they encountered a problem that feature was suited for.

Architects learn from everyone. That includes business folks, QA, developers, and their leadership team.

Experience
There is no substitute for experience in architecture. I’ve run into twenty-something developers with architect titles. I find that laughable. Experience brings diversity of challenges, solutions, technologies, and business contexts. It also brings time to have studied under other architects and senior mentors.

You don’t have to have had many jobs and worked on dozens of systems. An architect must be exposed to a multitude of problems to solve. Each challenge faced and solved adds a tool to be used for the next problem. It provides maturity and confidence required to push through hard problems and solve them.

A senior developer may master many software engineering technologies. An architect combines this basic requirement with coaching, personal desire to learn, and experience.

An architect brings these elements together to solve new challenges. In this process, the seeds are sowed for new architects to be developed.

On a personal note, I want to thank architects Mary Holstege, Andreas Guenther, Derik Whittaker, and Roger Larson. This article is merely a summary of what separates these folks from the rest of the bunch.