Without the 6P's of re-engineering, you're playing with fire

Re-engineering software is not as simple as just pulling up some code and making changes. This article gives you a quick formula to re-engineer any platform and team

????-?????????????????????? = ??????????????, ????????????, ????????????????, ??????????????????????, ????????????????, ????????????

What is re-engineering?

Software re-engineering?is the examination and alteration of a system to reconstitute it in a new and improved form and often includes areas related to the software system.

Green field software development is easy. Brown field development is where people show their expertise. Re-engineering is brown field development where you are re-building or building out of an existing platform, over time, and it often includes infrastructure, SDLC, team, processes and other factors beyond the software.

6 P's of re-engineering

After successfully re-engineering multiple significant systems for multiple companies (yeah I'm old), the same 6 P's of re-engineering emerged, so I documented them and made the process repeatable.

Here they are:

Process

Agile is not an excuse to not have a process, discipline or change on every whim. I use a permutation of the Scrum-Agile process that is easily applied to teams. When teams do not have a set process, the output is not repeatable and therefore not measurable. Repeatability and measurability are critical to drive improvement.

Agile says that teams "can modify the process to suit their needs". True statement but the reality is when teams start modifying processes, it is often to migrate back to the trappings of their old processes or to solve perceived problems, not their actual problems. Teams new to Agile also don't know enough to know how or when to change the process. Teams wanting to modify the process are my warning flag for derailment.

The more variable the work, the more rigid your process and process adherence should be. A rigid process acts as a governor of the flip-floppers. Repeatable and reliable scheduling of work and the automated build and deployment of software is the bedrock of combating flutter.

Importantly, a repeatable process leads you to your next step.

People

An engineering team's most valuable assets are the actual team members. When the process is repeatable, you quickly discover which team members are actually valuable instead of perceived as valuable. The process requires the sharing of information, not the hoarding of it. Identify the qualities of your team members and understand how they function, especially what they contribute to the group. If you lose a leader wait to see who fills their void.

Team members who are not contributing need as much coaching, help and opportunity as possible to recover. Those who don't need to be gone, but they should never be surprised. Be ruthless in your decision making but compassionate in your execution. Process gives you performance measurement and metrics to help your decision making.

Number one priority, if you have a vacancy on your team, is to fill the position with the right person. Your interview process must be rapid and is more important for your team to execute than to "do the extra work now that they are person down". It becomes the most important thing you and they do.

You are building a culture of excellence. When looking at team members, empower the technical to be technical and the people managers to manage people. They are parallel career paths, not successive. Creating a path with people must manage to move up forces resources to focus on areas where they bring lessor value.

Problems

When someone says "We don't touch that code" that is the first piece you need to focus in on and understand. There is probably a lot of silly stuff going on in that section and you need to blow it right open. When you shine a light on that code, expect the roaches to scatter. Often there is a single person that has taken control or even created that code and holds everyone else hostage to it. Visibility eliminates the leverage.

Start researching all the support tickets for the platform and speak to the end-users if possible, especially internal users. Often those users have given up trying to report things that bug them, but have accepted them as "the way the software works" or as "unfixable". Understand the processes they have created to work around that road-block. Look for the low-hanging fruit that jumps out at you and annoys your users. Typically, it is the stupid stuff like a drop-down that takes ages to populate or a non-sensical sequence of mouse clicks or pop-up boxes that no longer make sense.

Make a list of these items and make sure some are prioritized every sprint. You can even create a "maintenance sprint" that focuses on those items. We created a war-room day every sprint where engineers can pick problems that create the most support or really annoy them that can be fixed and tested in a single day and fix them.

Don't forget your infrastructure, virtual or physical. Your engineers need to understand how their applications are hosted and the implications of their design and deployment decisions. How to load-balance, slot swap, diagnose a slow disk impacting a database. Make friends with your infrastructure teams because they are your extended family. Bitch at them all you like behind closed doors but if someone else bitches about them, step up to their defense. They are part of your solution and engineering family.

Tackle annoying problems to reduce your support tax and help with the users' perception of the platform. Their perception is your reality.

Sometimes your software may be acceptable, but it is just slow. A condition equally annoying.

Performance

Hook up your software to analytics tracking systems, like Application Insight (my personal favorite). Look what pages are slow to load or generate the most errors. Run profilers on the databases and understand what the frequently run slow queries are.

Queue up solutions to these performance issues. They are burning resources on servers and annoying your users. Performance is something you need to pay attention to because over time, these issues may return and they silently eat away at your user's happiness.

Performance is the heartbeat of you platform.

Platform

Platforms are the key to long-term success. Once you understand the platform, you have to decide a path forward. This path is guided by a product and a technology vision. What does this software need to be in five years?

Forget horizontal re-engineering - changing out a storage mechanism or a technology choice across the software makes engineers happy but often doesn't move the ball forward or bring a lot to the customers. Paying down technical debt horizontally has low ROI and is typically high risk and high cost. It also removes an opportunity to seriously move the ball forward.

Re-engineer out of your platforms, one functional area at a time and into re-usable components and subsystems. For example, take email delivery, templates and rendering etc. and at every opportunity move that into shared subsystems and shared components. For example, when you have a large issue or significant feature change involving invoicing, move invoicing into its own subsystem and evolve it independently.

Chew the elephant one bite at a time and pretty soon that old problematic monolithic platform is a high-tech service bus connected farm of subsystems. The more you split your platform, the easier it becomes. The teams become better at executing the changes and your library of shared components and subsystems reduce implementation and support costs.

Profit

Yeah - just had to say it.

Profit comes when:

• You have a distributed asynchronous platform of re-usable subsystems
• You teams are elite focusing on solving the business problems, not playing with technology
• Team members can move freely between teams with zero ramp-up time
• Processes are all repeatable
• Performance is measured

As you expect, there is way more devil in the details than just this recipe, but it should serve as a strong guide to how to successfully re-engineer software and teams.

Remember that re-engineering is a journey and you better all be ready for the long run. Anyone promising management they can replace a system in months is setting everyone up for a death-march and blowing smoke. Most systems have more forgotten features than expected. Those leading a death-march charge just haven't failed in that process before.

Success is a process, an iterative marathon, changing culture and software, not an event or a simple re-write.

Special thanks to Ella-Bella for being a risk taker