Strategically Getting Back Burner Software Projects Done

Steven Bui

Jan 2, 2019·5 min read

Good ideas and useful projects are often stuck on a back burner indefinitely because they require months to a year to complete. How does a software developer get a back burner project started when product management controls the vision and roadmap of the product? The first dreadful idea is creating a project proposal and gathering enough support. That’s a lot of time and effort invested in just trying to get a project unstuck. What if there’s another way? Over the years that I led the development of a product, I learned a few creative and useful techniques that help me to usher in a test infrastructure replacement and large code refactoring projects.

A small disclaimer: These methods are not for getting a rogue project completed. These projects mentioned are ones that PM agreed on, but there were always more valuable projects to do.

The Semi-Stealth Project with Limited Development

An opportunity showed itself for a replacement test infrastructure that engineering had been championing for many years. A proof of concept of the new test infrastructure showed it took one-third of the time to write test cases compared to the current test infrastructure. However, it was in a proof of concept stage, which means it would require a large amount of work to reach maturity. The hardest part is identifying an opportunity and taking the initiative because it needs taking on a risky bet.

Project Analysis

The new test infrastructure takes one-third of the effort to write tests compared to the current system. Let’s say it takes three work units to write tests with the existing infrastructure. The replacement infrastructure could have limited development with the two work units saved and use the one work unit to write the needed test cases. However, it was estimated to take nine months to complete, but it wasn’t an all-or-nothing decision. The proof of concept had already provided a rough foundation to work on, but more development was required to achieve working parity. There would be a net zero gain initially during active development of the new infrastructure. Over time, the infrastructure development should drop as the infrastructure matured and there would be positive gains.

The Pitch

The project was estimated to need around nine months to complete if solely focused on it. If I were to ask PM for approval for a nine months infrastructure project, it would have gotten a quick ‘no’ because the existing system ‘works’ and there were more business reasons to spend it on developing the product. I had a conversation with PM which I told them that I wanted to switch out the existing test infrastructure for a new one. Of course, they asked about the time cost, and I said it costs “nothing” because it wouldn’t affect current schedule forecasts and it would provide better team velocity once switched over. Is this pulling a fast one over PM? Well, it was a sneaky pitch, but I was still committed to delivering what PM wanted on time. Do they care how I executed? No, they agreed to it as long as the current schedule isn’t affected. I was creative and strategic with how the resources are used.

Fruition

In the end, it took a bit over twelve months (or 24 person months) to complete at the two-thirds work rate. At maturity, the development cost dropped to half a work unit to further develop and maintain. That’s a net gain of one and a half work units for the team velocity. The new system showcased in front of engineering, which some of the other teams wanted to switch over to the new infrastructure.

Creating Building Blocks with Overlapping Components

Making strategic decisions based on code or functionality overlap is possible for a developer. The product code interconnects in a way that different functionalities of the product could be reusing the same code. This concept is known as code reuse. So two or more new features could have some overlap in the code with each other. Strategically making the overlapping code able to be reused helps reduce costs of projects.

Small Scale Example

There are Project A and Project B, which both of them share a need for new database functionality. Project A’s estimation cost is four months, and Project B’s estimation cost is two months. If Project B was completed first, then the price of Project A goes down to three months. Vice versa. Completion of either project reduces the other’s cost because of the shared functionality.

Project X

There was a good usability enhancement, Project X, that the developers strongly wanted to implement, but it didn’t introduce any new features. The improvement was useful, but it didn’t provide enough ROI (return on investment) compared to other projects with higher ROI. Therefore, it was stuck on the PM’s back burner because it would have taken eight-person months and there were not enough existing customers that wanted it.

Small valuable projects, which are easy to gain PM’s approval, helped to assemble building blocks for Project X slowly. How is this possible? Small-scale code refactoring is part of any software development because it improves the code for gains such as maintainability or performance. It was very cheap to have the code refactored slowly in a way that enabled code reuse in the future. Code refactoring allowed the functionality to be separated and placed in a different function.

Throughout roughly a year and a half, Project X’s time cost slowly dropped down to one person month. At that point, the cost was smaller, and it rose to a higher ROI. PM approved the project and the developers were happy it was finally implemented because it saved time for power users of the product.

Explicit Piecemeal Efforts

Both of the previously mentioned stories implicitly broke down the large project into smaller parts. This piecemeal approach could be used explicitly also. The project below took close to three years to complete because it was worked on during small gaps of free time. It would have probably taken four-person months if solely worked.

The strategic methods:

• Use the time saved from by the more efficient system to implement the project
• Use overlapping projects to implement or reduce the cost of the project slowly
• Explicitly spending spare time on a piecemeal approach

All methods use a similar approach to Agile development concept of breaking down ‘epics’ into smaller ‘user stories’. Bullet point 1 is excellent for infrastructure replacement projects. Bullet point 2 and 3 are great for features or enhancements.

Advice:

• Be very patient
• The pitch of a project matters
• Look at existing product functionality for code reuse
• Break the project down to smaller pieces to see if functionality overlaps with any other projects
• Code refactoring is a powerful way to decouple existing functionality or enable new ways for code reuse
• Making forward-looking design enables easier implementation