How to Balance Today’s Priorities with Tomorrow’s Vision for Custom Development

When building software, balancing short-term priorities with long-term vision can be difficult. When teams deliver software based on a roadmap plus work with project/release planning – that's where art meets the science of software engineering. We often help clients strike this balance while planning projects, and doing so, we've gathered some "lessons learned" along the way. In fact, we find that development teams often fall into one of these two pitfalls:

1. Cautious planning and unclear roadmaps that may delay getting the project started
vs.
2. Building enticing features that may delay a working release

Here, we examine example hurdles from real-world scenarios, plus three things to consider to help avoid these pitfalls in your future development projects.

Lessons from building an MVP

We often work with clients in situations that call for software to be delivered in phases.  These projects often include launching some kind of a minimum viable product (MVP), followed by releases that include enhancements to that MVP.  In these cases, the priority of post-MVP enhancements is often driven by lessons we learn during and after the release of the MVP.  What qualifies as "minimum" changes drastically from project to project, but we believe the concept is valid. Let's take a look at two common pitfalls during the early stages of custom software development. 

Real-world example 1:

Confusion over end-user audience

Recently, we built a fairly standard web application for a client in the healthcare industry. The application was a rewrite of an existing tool ready to be retired. During planning, one thing became clear: There was conflict between the business reps and the technology reps regarding who the end user of the app would be.  The app was primarily used internally, and both sides knew the initial user population would exclusively be internal. But one side envisioned the app eventually being available to the public.

With a business-driven deadline on the horizon, we chose to build, and subsequently enhance, an MVP.  While building the MVP, the priority of features that might be helpful to external users and related security and architecture concerns continued to crop up and eventually led to conflict.  We found ourselves debating the current plan because of an unclear roadmap, which caused the team's productivity to suffer. 

Real-world example 2:

Conflicting ideas on project size

In another similar scenario, we worked on a hybrid team with a client on another application rewrite project. In this case, the requirements of the project were quite well-defined and agreed upon by the business and technology representatives, but there was a clear disagreement on how large the initial user population would be.  Eventually the decision was made to proceed with the MVP, but priority was placed on building a massively scalable architecture to meet the demands of an exploding user population.  In this case, the team focused on (and subsequently struggled with) creating/recreating the ideal architecture which caused significant delays in getting a working release into the hands of their users. 

In both cases – and like many cases – the parties involved are well-intentioned and acting in the best interest of their businesses.  Also in both cases, we experienced conflicting priorities originating from different parties involved in the projects that put strain on the project team.  These are not uncommon situations.  Here are a few things to keep in mind to avoid similar scenarios on your own projects: 

3 ways to avoid these pitfalls

1. Focus on known priorities. You've probably heard the programmer term, "You aren't gonna need it." Apply it here. Focus on well-defined and agreed-upon priorities to start a project so you build development momentum. Tip for developers: Focus on well-defined and agreed-upon priorities to start a project so you build development momentum.  Share on XDevelop the functionality that is needed to immediately solve core business problems and get working software into the hands of users. We still advocate bringing complexity forward in project plans, as long as the complexity is related to the immediate priorities of the project. Defer work related to features and functionality where priority is less clear as disruptive or attractive as those features may be. 
2. Focus on responsible evolution. As you follow a product roadmap and software is delivered and continually enhanced, expect that portions of the software will be thrown out and re-written.  This shouldn't be considered waste – this is evolution. Inevitably, services and components will be swapped out, added, and removed. In these scenarios, application architecture should contain appropriate levels of abstraction to accommodate change in the future. Consider adopting practices related to Evolutionary Architecture as a starting point.   
3. Focus on early investments in quality. We've seen countless instances where upfront investment in basic automation (test, build, deploy) is passed over for adding more functionality to the system.  Yes, we agree – get working, desirable software into the hands of users as soon as possible. But, teams should not neglect making investments in the practices and tooling that will pay off in the long run.  One of the best ways to ensure changes can be made to the software in the future? Make sure the code written today is "clean" – appropriately abstracted, well tested, well structured, well named.  Automated tests not only exercise the code being written in the present, but also can alert developers when breaking changes are made in future iterations. Further, when builds and deployments are automated, you increase how frequently the code is tested and increase the likelihood that breaking changes will be detected as soon as possible. 

Let the adventure begin

We know complicated projects are prone to bumps and detours along the way. But thankfully, the process is continually being refined and perfected by those who have done it, and done it often. If you're just getting started on a large-scale custom development project, consider partnering with an experienced technology firm to help you stay focused on your priorities today while continuing to plan for the vision of your business.