Take Small Bites and Chew Well [Air Force Software Blunder Part 2]
Test and Monitor | Posted December 21, 2012

I'm still pondering the disappointing news last week from the Air Force about its decision to abandon the Expeditionary Combat Support System (ECSS), which was an end-to-end complete logistics system that would have replaced multiple legacy systems that have been in place for decades. If you look at the very premise of having a multi-year software project, warning flags should pop up immediately.

The software industry has been dynamic since its inception, but in the last few years it has moved into warp speed and even the most Agile teams building the lightest weight software are having trouble keeping up. If you take six years to build your replacement system, it’s already obsolete on your launch date.

Even back in the 80’s when I worked on one of the legacy systems ECSS was intended to replace, we weren’t trying to release the whole system all at once. We decided to focus on being able to generate a Crash Report because we knew that would be the most significant proof to the organization that there was value in what we were doing. But don’t let that fool you – you can’t build a report without first understanding what the user needs in that report. Then you have to figure out the data elements you have to gather in order to build that report, which forces you to design the data structure and input for all of those elements. One report can lead you pretty far back in your dependency tree if you're building a system from scratch.

So what am I saying? Well, I’ve been part of large system re-designs multiple times in my career. When you look at the forest, it makes you gulp for air. But if you concentrate on one tree and decide to just replace that one tree, it’s easier to walk the dependencies to see where you start. That’s the whole idea behind software iterations – take it one step at a time.

Step 1: Get the Foundation Right

For example, if the lowest ground is being able to enter your inventory items, then create all the necessary user stories for that piece. Make sure you architect the tables and interfaces in as flexible a manner as possible so you can start to use the system at the same time you are extending it for the next set of functionality. Then build those tables and interfaces with the right data mapping for the legacy system so you can run both side by side for as long as you need to.

Step 2: Make It Easy to Add To

APIs have to be a critical part of your design from the beginning. At SmartBear, we like to think of software in terms of Legos and it’s the perfect analogy for this type of endeavor. Usually when you build with Legos, you know what your end result is intended to be. But you can’t build everything at once – you start with the foundation and add from there. In that analogy, think of the little sticky-outy things on the Legos as APIs. They are the connectors that hold the whole thing together, and as long as you can match up the components to each other via APIs, you can keep adding to your Lego structure without too much disruption.

Step 3: Make Someone Happy

Okay, not just one someone… but pick a user base to focus on. To follow the thread here, if you're replacing the inventory item entry system first, then your first target audience should be the folks entering new items into the system. One common user base with one common function – if you can focus on their needs and make sure you get it right, you can move on to the next module without giving up time, resources, and budget to too many features at one time. Yes, the rest of the users have to use the legacy system for everything else, but as long as you have secured the data and its mapped interfaces, you should be able to build the next set of inventory management features on top of that structure in the same manner.

Use smaller iterations and take smaller bitesIt’s Not Rocket Science

Mom always told you to take smaller bites and chew your food well (36 times, right?), and we all know you should listen to Mom. Sometimes this kind of development process can be hard to sell at the top because it doesn’t get sexy or interesting until the last stages of the project. It may still take six years to replace the legacy system in the end, but at least you'll be able to do it. And you will have enough chances to iterate over your design so you are making use of the latest technology advances. 

See also:


By submitting this form, you agree to our
Terms of Use and Privacy Policy

Thanks for Subscribing

Keep an eye on your inbox for more great content.

Continue Reading

Add a little SmartBear to your life

Stay on top of your Software game with the latest developer tips, best practices and news, delivered straight to your inbox