While developing your product, you will encounter several risks that will impede progress and therefore result in lower throughput from your development team.
This article is part 4 in a 5-part series explaining maximizing long-term throughput in the software development process. Today, we focus on risks that affect the development team (e.g. using a new API) as opposed to risks that more generally affect your company (e.g. Google entering your market and competing with your product).
Because history repeats itself, we already have an inventory of many of the risks your project will face. Of course, there are unpredictable risks, but below, I’ll cover the common ones we’ve encountered.
A Note on Offshore “Resources” (Read: Developers)
I’ve been asked this question several times in my professional career: “Can we hire these developers from country X to develop some components of the software for cheaper than your rate and have you manage them?”
My answer? No. Would you ask your surgeon if you could bring in an outside team of unproven nurses so you could have a cheaper operation? It could work, but it’s a big risk.
Most software development firms’ developers are trained in a given process and work efficiently as a team. Your firm won’t have the same level of control over the process of an outside team beyond telling them which features to develop that week.
Potential Risks of Any Development Process
Note: When we say “third-party,” we mean adding another group or individual to the equation, whether they’re outsourced or in-house.
| Risk | Factors that increase risk | How to mitigate risk/what to expect |
|---|---|---|
| Working with Third--Party Designers | The designer is moonlighting. They won’t have enough time to commit to your project and will probably flake on you. The designer has limited HTML/CSS/production experience. They’re designing in a vacuum. Don’t hire MC Escher to design your house. While the designs may be aesthetically pleasing they may not be practical or easily implementable. | Have a plan B. Anticipate that you will get to a point where you outgrow the designer’s capabilities or availability.
This will slow down your project and cost you more. We often see clients paying the third-party for unusable work and then paying us to redo it. |
| Working with Third-Party Developer(s) | The developer is moonlighting. See above.
The developer has limited full-stack development experience. Time experienced developers spend training other developers still costs you; training will slow you down and adversely impacts your throughput in the short-term. The developer is not well-versed in best practices. When everyone understands and follows the same set of best practices you can move extremely quickly and be confident that you are getting extremely high quality code. Unless the third-party developers’ quality of work is unquestionably on-par with or better than your other in-house developers or the firm you’ve hired, they’ll adversely impact throughput. |
See above. Furthermore, code is more expensive than design and more integral to your project. So the risk and the bad effect on your product and budget is magnified. |
| An Existing Design, Wireframe, and/or Mockup | There are unrealistic aspects to the design. The design may reflect bells, whistles and “nice to haves” but in all likelihood will need to change to reflect reality: budget, time and what the end-users really want.
The design will change. As the application is built to whatever design is provided, there is 100% likelihood that everyone on the team will want to change various aspects of the design. This is a good thing; however, there is a cost associated with it. |
Don’t spend too much time on wireframing and design before development. If you do spend a lot of time on this phase, don’t get attached, and don’t expect it to save you time down the road. |
| Using a Backend API as a Datastore | The API is slow. As the frontend application is built it may become evident that optimizations need to be made to the backend API in order to provide a better experience to the end user. Performance improvements will need to be made to both the backend API and the frontend application. Your team will also need to collaborate with the backend API developers in order to design and develop the most cost-effective optimizations.
The API will need to be modified. It’s almost always the case that the API won’t have all of the fields and methods necessary to support 100% of the desired functionality in the frontend application. Frontend developers will need to spend more time interfacing with the backend API developers in order to identify all required functionality. |
Expect that the developers will need to spend time focusing on (1) improving the performance of the API; and (2) modifying the API to reflect the needs of the frontend. |
| Integrating with unknown APIs | The more APIs you integrate with, the higher the risk. Of course, for many products, this is inevitable. You should just be prepared. | If your budget is tight, perhaps you can do without the integration with the unknown API. |
| Working with an Existing Codebase | It may seem like building on an existing codebase, whether it’s live or halfway built, will save you time and costs. However, this is often not true.
We see this happen in two forms. You’ve fired a vendor or employee. Unfortunately, companies do not typically switch development vendors because the vendor was doing an excellent job. In this situation, working on an existing codebase is akin to asking contractors to perform structural improvements on a large 100 year old apartment building that has no blueprints. It’s simply a risk and there is no telling what may be uncovered. |
Depending on your situation, it might be better to nix the existing codebase and start anew. Also realize that any estimate from an outside firm on building on your existing codebase is tantamount to shooting in the dark. How many times has your car mechanic given you an accurate initial estimate?
You never know what problems you’ll see in the engine (or the code) until you get under the hood and start doing the work. The bigger the app, the bigger the risk. |
If you anticipate risks and work to avoid them, you can maximize the long-term throughput for your development process.
Want to learn more?
Check out our tips for successful software development:
