https://builtin.com/software-engineering-perspectives/when-mvps-hurt ** Skip to main content Loading... [expert-con] When MVPs Hurt If you're migrating or modernizing your system, start with the most important components -- not the least. Headshot of author Marianne Bellotti Marianne Bellotti Expert Contributor Principal engineer and engineering manager at Rebellion Defense; formerly tackled some of the oldest and most complicated computer systems in the world as part of United States Digital Service. December 14, 2021 Updated: December 15, 2021 Headshot of author Marianne Bellotti Marianne Bellotti Expert Contributor Principal engineer and engineering manager at Rebellion Defense; formerly tackled some of the oldest and most complicated computer systems in the world as part of United States Digital Service. December 14, 2021 Updated: December 15, 2021 Join the Expert Contributor Network Join the Expert Contributor Network The wisdom of a minimum viable product (MVP) is well established in technical circles. When building a product, we all know we should remain agile and launch something small and simple to start. Then over time, we can make that product more nuanced by adding more features over time as previous features prove their value. Unfortunately, the same process wreaks havoc when it comes to modernizing an existing system. At first, the reason why is not intuitive. In theory, the same principles should apply: Start with small and simple use cases to upgrade and build upon your success. Certainly it's true that 10-year migration plans never work out well, but defaulting to an agile MVP can bring just as much bad luck to a project as traditional waterfall development. Product Development Vs. Modernization The difference between product development and modernization is the hypothesis you need to prove from sprint to sprint. With product development, you're trying to prove that people will use the technology. With modernization people are already using the system, and often have no choice about it. Legacy systems are, after all, successful systems -- and successful systems tend to alter the process and environments they're built for so that we retire the old ways of doing things and become dependent on them. Instead, the hypothesis we're trying to prove when we're modernizing a system is that the updated technology will do a better job than the old version we're leaving behind. There are a lot of reasons why that might not be the case. 3 Cases When Modernizing Your System Might Not Be an Upgrade 1. There might be some complex flow or requirement that the new technology has no solution for. 2. The new technology might be optimized for different priorities and we might find ourselves on the wrong side of a trade off with security, performance or consistency. 3. Our use of the technology might reveal an edge case the industry hasn't seen yet and trigger undesirable outcomes. The use cases that seem like the simplest and the most likely to be identified as MVPs are also the parts of the system that no one cares about. We don't modernize systems that aren't being used. We turn them off. The problem is, modernizing systems that are being used is pretty hard. So when people are asked to think about a MVP for a modernization, the challenge of migrating a set of functionality to new technology without complications or downtime is perceived as part of the scope in determining the minimum. When Validating Migration, Raise the Stakes I've seen many companies start a migration to Kubernetes by migrating their documentation sites, then act surprised when that success does not inspire enough confidence for critical business systems to sign up to move over. Putting the least important set of functionality on a new technology violates the spirit of an MVP. It does not validate that the modernization effort can add value. It would be the equivalent of a product-development effort deciding their MVP was the login page. Sure, your team might be able to successfully launch it, but did we learn anything about whether the project itself is valuable? The beginning of a modernization effort is a precious period, so don't waste it. This is the time when the team has the most excitement, the most momentum, the greatest level of stakeholder buy-in and the most money and staff. When people conflate minimum with simple, they squander a critical stage of the effort. Migrating part of an active system that isn't important or that fewer people are using is definitely simpler than migrating a critical part of the same system, but the rationale behind MVPs is that they should validate the benefits of the product being developed. If you start with the simplest parts of a migration, you haven't validated that the migration will behave correctly on the parts of the system that are actually important. That's why I tend to gravitate towards starting migrations with the harder parts of the system. It's a more challenging project, yes -- but you will never have more resources and more support for a modernization effort than you do in the very beginning. The hard bits won't be any easier months or years later. Read More From Marianne BellottiShould You Embrace No-Code Software? Build the Right Staging Environment When you successfully migrate a hard part of the system, you've proven that the modernization itself can add value in the same way a MVP validates the effort of building something new. Conquering a hard part of the system tends to inspire stakeholders, especially if other modernization efforts have failed in the past. Sometimes this enthusiasm takes the form of increased moral support for the team, but it can also lead to more resources and more favorable prioritization. Of course, in order to start with something hard right away, I need to have the right environment. When a new system goes live, it's normal for there to be small bugs that pop up as the gears turn for the first time. I need a staging environment that's as close to a carbon copy of production as possible. I also need an engineering team that embraces thorough and comprehensive testing practices. They should write integration tests, yes. They should write unit tests when appropriate, yes. But they should also be prepared to figure out what parts of the system should be tested with the assistance of a fuzzer. They should do live failure tests, particularly around the migration plan itself. If we can't do these things, then by taking on a hard part of the system we are forcing ourselves to tackle both the simple bugs that are found the first time a system runs and the complex bugs found when making changes to interactions with a lot of downstream dependents at the same time. We need to feel confident that we can eliminate as many of the first-attempt bugs as possible through testing before we green light the actual migration on production. If we can't do that, then we should migrate an easy part of the system first in order to get through the bugs and tackle the hard parts as soon as we can. The Takeaway A modernization project hasn't proven its value until it has successfully migrated the important (read: hard) parts. MVPs are useful because they validate that a project is worth doing before we've wasted a lot of time and money on it. For that reason, the right MVP for a modernization effort is often a complex part of the system. If you pick an easier part, you will waste time, money and political capital doing work that does not prove to the organization that this new technology can be trusted with their most critical business functions. Expert Contributors Software Engineering Perspectives [1re_0] Rebellion Defense View profile We are hiring [expert-con] Expert Contributors Built In's expert contributor network publishes thoughtful, solutions-oriented stories written by innovative tech professionals. It is the tech industry's definitive destination for sharing compelling, first-person accounts of problem-solving on the road to innovation. Learn More Jobs at Rebellion Defense11 open jobs All Jobs Data + Analytics Dev + Engineer HR + Recruiting Product Sales Content Data + Analytics [1re_0] Data Scientist (Remote) new Rebellion Defense Remote View Sales [1re_0] Account Executive new Rebellion Defense Remote View Data + Analytics [1re_0] Senior Machine Learning Engineer (Remote) new Rebellion Defense Remote View Product [1re_0] Red Team Operator (Remote) new Rebellion Defense Remote View Developer [1re_0] Senior Software Engineer, Sensor Fusion & Tracking(Remote) new Rebellion Defense Remote View Developer [1re_0] Senior Software Engineer new Rebellion Defense Remote View HR + Recruiting [1re_0] Recruiting Coordinator new Rebellion Defense Seattle, WA View Sales [1re_0] Head of Industry Partnerships new Rebellion Defense Remote View Content [1re_0] Senior Technical Writer new Rebellion Defense Remote View Product [1re_0] Product Manager, Cyber Readiness (Remote) new Rebellion Defense Remote View Developer [1re_0] Engineering Manager, Cyber Readiness new Rebellion Defense Remote View Great Companies Need Great People. That's Where We Come In. Recruit With Us BuiltIn United We Tech Built In is the online community for startups and tech companies. Find startup jobs, tech news and events. About * Our Story * Careers * Our Staff Writers * Content Descriptions Get Involved * Recruit With Built In * Send Us a News Tip * Become an Expert Contributor Resources * Customer Support * Share Feedback * Report a Bug * Remote Jobs in Atlanta * Remote Jobs in Dallas * Remote Jobs in DC * Browse Jobs Tech Hubs * Built In Austin * Built In Boston * Built In Chicago * Built In Colorado * Built In LA * Built In NYC * Built In San Francisco * Built In Seattle * See All Tech Hubs (c) Built In 2021 * Accessibility Statement * Copyright Policy * Privacy Policy * Terms of Use * Do Not Sell My Personal Info * CA Notice of Collection View jobs at top tech companies View Jobs *