It's Just a Feature for Feature Port
It's Just a Feature for Feature Port
Are feature-to-feature ports really that difficult to develop for? Absolutely not, teams need to understand functionality and feature-driven development.
Join the DZone community and get the full member experience.Join For Free
A long time ago, in a galaxy far, far away known as my teenage years, I used to watch the popular CBS show Magnum, PI. The show's protagonist, Thomas Magnum (portrayed by Tom Selleck), had a running self-narration throughout the show which helped fill out the plot and characters.
One line of narration that Magnum often spoke was, "I know what you're thinking...". He did this when it was clear to the audience that he was about to do something that wouldn't work out all that well, and used it to explain why he was doing it anyway. Usually there would be unforeseen complications that led Magnum into danger and from which he would have to extract himself and others in dramatic fashion.
Gotta love Hollywood!
Just like in the show, unexpected complications ensue requiring dramatic interventions by the protagonists. I've even used it myself several times during my software career, each time when someone is porting some functionality to a new language, framework or platform.
It's just a simple feature for feature port. We don't need to figure out the requirements. We don't need the business people until the end. We aren't going to add anything new or change the functionality at all!
My first experience with one of those "simple" ports was to do a 4-day assessment of the 6 months of work that had been done without delivering anything. After telling that client that the code developed to that point was garbage (which it really was), they engaged me to rebuild the system from scratch. I worked closely with the people who would be using the system to determine what they actually needed, and shipped the new version in about 4 months.
That version *did* have some different functionality. Some features were added, some dropped. Some were changed to accommodate changes in how the business worked since the system I was replacing had been deployed a few years earlier.
But it was just a port of the existing functionality.
I've encountered this phenomenon several times since. Each time it starts with the statement that "it's simple"! That immediately triggers Thomas Magnum's voice in my head: "I know what you're thinking."
Just like in the show, unexpected complications ensue requiring dramatic interventions by the protagonists. I saw boatloads of this with DOS to Windows in the 90's, Windows to the Web in the 00's, and now with the Web to Mobile ports of the 10's.
So, how do we avoid those Magnum moments? Well, that actually is simple. Treat all work as a new endeavor, even a simple port of functionality.
Regardless of how much or little the functionality is expected to change, the business people need to be engaged. The people building the new version of the system, who likely aren't the people who built the older system, need to understand the domain and why the system does what it does. The business people need to understand what trade-offs they need to make with a new platform, or what new capabilities exist that can improve the user experience.
The biggest factor, though, is that the assumptions underlying the existing system may not be applicable anymore. A mobile application can't necessarily assume that it will always have fantastic connectivity with LTE bandwidth. A web application may be able to leverage HTML5 and CSS3 if the target audience is comprised of people who have enabled automatic updates of their browser of choice. If the audience is more broad, that assumption may not be valid and an application could simply not render properly.
All of this is to say that the requirements discovery process makes sense even when the problem domain and solution are supposedly well understood. Define those personae! Build that Story Map! Work iteratively and incrementally! Invest the time in figuring out what functionality should be present in a minimal viable product to obtain feedback on the work completed to that point.
I know what you're thinking... we already know how to do that! Yes, you're right. Don't skimp on those activities when porting functionality. An investment of a few days to a few weeks will eliminate the need for all the drama in the last 20 minutes of the episode.
After all, delivering software effectively shouldn't require drama. Let's leave that to Hollywood.
Published at DZone with permission of Dave Rooney , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.