We were running out of time.
Our goal was to bring data compare to Compuware Topaz Workbench. File-AID/MVS, Compuware’s file and data management solution, has an extremely popular, extremely comprehensive data compare feature that has been in heavy use for decades. We wanted to take that core functionality and bring it into Eclipse, and at the same time leave the inherent complexity behind.
The quarter had gone smoothly. The mainframe and Eclipse groups had synced up very early in the development cycle, and we had queries going to the mainframe and results coming from the mainframe with several two-week sprints to spare. Still, something was nagging at us.
Compare is a peculiar animal. Conceptually everyone has a clear idea in their head as to what compare entails. But in practice it gets complicated in a hurry.
For instance, when you hit the first record that doesn’t compare, does that represent a changed record, an inserted record or a deleted record? Does the user want to know if the files are exactly, byte-by-byte, identical, or do they just want to know certain records exist in both files? Are they interested in the entire record or do they only care if certain fields within the records match?
We wanted to bring Apple simplicity to what was not an apples-to-apples comparison!
Racing Against Time
Very late in the development cycle, we had yet to hit on a solution we could all agree on. We had shown our proposals, both as wireframe prototypes and by actually implementing them into our development project, to many customers. But, we hadn’t gotten the exact sweet spot of a response.
Part of the issue was that we were having trouble getting to our most typical use case. We wanted to appeal to the next-gen developer with little or no mainframe background. Instead we were often showing our proposals to veteran mainframe developers, and they loved it. But our goal wasn’t to be better than the green screen—our goal was to provide the best compare feature Eclipse has to offer.
When we finally hit on the right mix of simplicity and functionality—a UI that lets a compare run with a couple clicks while still allowing the user to tailor the compare to suit their needs—another challenge emerged. We only had one-and-a-half sprints left!
It was now entirely up to the team. If we committed to the challenge, we’d move forward. Otherwise we would deliver what we currently had working. That wasn’t a horrible option; we knew we already had a viable compare. But what we were shooting for was a delightful compare!
In diplomatic terms this led to frank and open discussions. The team did not want to sacrifice quality for functionality. Plus, another team (not our mainframe compatriots!) was refactoring some core technology that had the potential to impact our test environment. We couldn’t afford to lose any time.
The team weighed all of this and decided to move forward.
We made some tough decisions. Certain usability stories that we would have loved to sneak in now had to be considered out of scope. But the team pulled together and implemented the UI changes. We all walked away proud of the effort and proud of the resulting feature.
Lessons learned? In Agile, the whole is greater than the sum of the parts. Agile works best in an open, communicative environment. And once the team commits—get out of the way!
How’d we do? We’d love to have you tell us! Here is a five-minute video of File-AID/Eclipse Compare in action. What do you think?