Skip to content

As A Developer, I know how to talk to my PO about existing code

Alex de Boutray9 min read

Women discussing in front of a whiteboard

Cover photo by You X Ventures on Unsplash

Monday, 10am. You’re around a table with a new team, looking at a product owner presenting the project you’ll be working on for the next few months.

While this project wouldn’t be the core software of your company, it would play an integral part in the firm’s development over the next few years. The PO wants it to be done quickly and cleanly so that you can all get back to improving the main product. To help achieve that goal, they’ve found an old prototype that had been in a drawer for a few months - or even better, an open source solution doing something similar.

This should be fairly easy then: take the existing software, add what we need, and deliver.

tl;dr

There are many different ways we can find value in existing code, like product inspiration or architecture ideas.

Lean principles should not be forgotten when dealing with old or open source code.

Communication may become more difficult. We offer a few tips and a milestone-based feature/cost analysis tool to ensure everyone is on the same page.

A few thoughts to start with

Human see, human want

Thanks to agile, everyone nowadays pays at least lip service to the notion that code only has value if it serves the user. It’s the reason we work with stories and try to keep our sprints short: the more user feedback we can incorporate in our process, the less worthless code we produce.

I’ve noticed that all this tends to be disregarded when trying to incorporate existing code. Both the devs and the PO like shiny new things.

The PO sees a cool feature in a demo and all of a sudden it’s a requirement in your project. You thought you were in for a simple time tracking app? Here come Face ID, SSO, custom transitions and a full-blown local database.

Devs easily adopt a black and white approach. “We’ll just incorporate the open source code, it’s free” and “the old code is just too bad, I have to redo it from scratch” are two sentences that I’ve said many many times, often based on my personal preferences for the technologies used. This can bias the opinion of the unsuspecting PO and deteriorate your relationship with them when your actual speed differs greatly from the planned one.

For example, if you’re looking at some oddly written code in a language you’re not familiar with, you might overestimate threefold the complexity of implementing it. Your PO, who’s used to you not overshooting my more than 50%, might interpret this as intentional and trust you less for it.

On the other end of the spectrum, if you promise something will be “free” (never a good move) and you end up spending a week on it, other features will be delayed and the whole project will suffer as a result.

So how can we align everyone’s expectations and settle on a common analysis of the situation?

Back to the drawing board

The next step is a very classic one: write user stories. Forget about the “free” existing code, just define your product as you would a new one. Depending on your company and team culture, this might be a task that only the PO works on but outside input - especially from user-facing stakeholders, or even better, users themselves - is always welcome.

The one question that should be on everyone’s mind during the prioritization phase should be “Do OUR users actually want this or are we just copying the other product?“. It may sound silly, but I’ve found double-checking this point saved us a lot of time. The other question to ask is “could we release WITHOUT this feature?” or “could the user benefit from the rest, even without this feature?“. This forces prioritization. I’ve seen features originally touted as critical continuously fall deeper down in the backlog, and eventually be dropped altogether just by asking this question.

The prioritization should also be carried a little more into the future than usual, because we’ll want to be able to assess the potential impact of using existing code in the medium term. If you usually work with weekly sprints and two weeks of backlog, you may miss out on benefits from the existing code by failing to foresee the need for some features or architectural choices.

For example, on one of our projects, extending our rough planning to two months allowed us to look into versioning and realize that the open source code we were adapting had a clever, working versioning system that we could just copy and paste if we designed our objects in a certain way. As a rule of thumb, staying close to the existing code will give you some options for the future, which have value.

Try to define some frequent milestones (maybe once a month, depending on the scope of your project) and define the specs of the product at that point. You may want to get a bit deeper than usual into their definitions and the technical strategies to achieve them. This will help us use the tools demonstrated later in this article.

In particular, you should have a decent idea of how your new code might interact with the existing one: are you going to rewrite an API? Use the existing one? Are you familiar with it? What would it take for you to be able to write this feature right now?

But wait, didn’t we have existing code?

Yes we did! Now is the time to get back to it.

An existing chunk of code will have two effects on your work to reach a milestone:

The secret is to be able to quantify the effects. It is evidently impossible, but you will have to get a good enough estimate to decide which strategy to choose. On larger projects where the potential to integrate a lot of existing code exists, it might be worth getting real life data by actually integrating a feature from existing code and analyzing your execution speed.

Another useful tool to plan work is the milestones we previously defined. They can help us analyze the impact of existing code on time and feature constraints (a.k.a. deliverables). Below is a graphical visualization that we used in one of our projects.

Feature / Cost for milestone 1

To reach milestone 1, we have to develop 3 features: bootstrapping the project, implementing a basic auth and the Facebook one. Since we already have the first two in the existing code (and we consider the integration cost to be zero for simplicity), they do not require additional time or money.

Under the y-axis are the features from the existing code not yet integrated into our product.

Feature / Cost for milestone 1

To complete milestone 1, we have to build the Facebook integration. To do this, we spend time and money with the first derivative of the curve being our development speed or development cost.

Feature / Cost for milestone 2

We then start milestone 2, for which we can take the CMS integration from the existing code.

Complete Feature / Cost

We repeat the process for all milestones and all features.

The constraints in this graph are the (x,y) coordinates of every milestone. They represent time / feature coupling that you have to respect for corporate and/or other reasons. They could be demos, client deployments, etc. In the end, they’re the only thing you need to account for.

What’s next?

We’ve only touched one of several aspects of working with existing code. I believe the most important thing in this situation is to keep a common language amongst the team that you can use to have productive discussions. In my experience, the most frustrating disagreements happen when one member of the team struggles to their ideas to the others. In these situations, we leverage the tools presented in this article to help us stay on track and be more productive.

Keep in mind that this is just an inspiration. Design your own tools! Your team’s needs will vary with the different personalities and skillsets involved, requiring bespoke solutions.