It's 1810 A.D. — We're Going to the Moon!
A Zone Leader talks about the concept of unrealistic expectations and feature parity and the impact this can have on reaching delivery goals - not to mention the impact on those feature teams assigned to the project.
Join the DZone community and get the full member experience.Join For Free
Imagine growing up in the year 1810 A.D.
While taking a walk just after sunset you notice the rising moon off in the distance. You become inspired, get an idea, and race to the center of your local province where there is always a crowd gathered at this hour.
Standing on a soapbox in the middle of the crowd you raise your voice to announce that you're going to the moon... the same moon that is a mere 238,900 miles from your soapbox in a time when not even the first automobile has been invented.
Instead of supporting you by rolling up their sleeves and getting to work, everyone gives you an odd stare and goes about their business. Women pull their children close as they walk near you — the crazy guy talking nonsense.
So why is this not the reaction we get when setting unrealistic expectations with software?
Reflecting On the Database Wars Days
Back in the days of the database wars, I remember reading computer periodicals that were filled with competing ads trying to gain database market share through marketing efforts. IBM had an advertisement making claims that DB2 was faster and better than Oracle and Microsoft. A few pages later, Microsoft had their own advertisement that showed why there were better than DB2 and Oracle. Finally, Oracle took up the biggest advertisement on the back page, showing how they are not only better than IBM and Microsoft but vendors that weren't known by most reading the periodical. Gupta anyone?
I had the pleasure to work with an engineer from one of those key vendors who worked on new features and functionality. He told me how his team had gotten to the point where they really wished their CEO would stop attending conferences and really any mainstream events that had reporters nearby.
Their reason was because the CEO would see something that a competitor was doing or get asked by someone about a feature and immediately promise said functionality for an upcoming release, all before the engineers had even been able to analyze such a request.
In this case, this CEO promised the customer a trip to the moon, without realizing the effort or cost to reach such a goal.
To the CEO, he wanted it and he wanted it now. It was up to everyone else to figure out all the logistics. To the engineers, there was no option but to deliver.
My colleague Timothy (barnes7td) and I were having a discussion earlier this week on this very topic. In fact, the "going to the moon before you have built a car" metaphor was his original concept and was all part of a bigger discussion we were having about feature parity.
At the highest level, the application we are building is going to provide Adobe Photoshop and InDesign-like functionality via a standard internet browser. The ensuing client will not only need to be functional using Chromebook devices running at lower screen resolutions, but have the ability to process updates from other clients working on the same project. Needless to say, there is a lot involved in this project.
This gets me to the concept of feature parity when rebuilding an existing application. At the core, I think feature parity is a common expectation to set. However, the reality more or less mirrors a utopian approach.
Like wanting to build a rocket to visit the moon in a time when an automobile hasn't even been built to drive across town, asking for everything that an existing application provides is simply not realistic in the short term. Well, not realistic if you want to provide a functional product to the consumer anytime soon.
What I feel like most forget in these cases is that the original product wasn't delivered with all the features in place for the 1.0 release. In our case, we are replacing a twelve-year-old application that has had feature upon feature added with each passing year. Complicating our goal is the requirement of adhering to core database design shortcomings, which add to the work that is required to reach the customer's expectations.
When I worked as a full-time employee, I had a manager who mentioned the concept that "the unreasonable man gets things done." At that point in my career, there was a C-level executive who always seemed to take this approach — which introduced challenges into our development team's ability to deliver functionality to our customers. Like the CEO in the database wars section (above), results ultimately were delivered, but employing these tactics led to less-than-favorable conditions for the engineers supporting the CEO's ever-changing vision.
Walk before you run, build a car before you attempt to take the skies. Both are reasonable expectations feature teams should keep in mind when delivering solutions. In our case, we continue to remind our client of these foundational concepts while on the journey to replacing an application whose existence is already twice the average age for an application — according to MitoSystems.
In the end, we will provide a solution that is a wonderful replacement to the legacy application. However, it will be over multiple iterations, one building upon the next.
Have a really great day!
Opinions expressed by DZone contributors are their own.