Nondisclosure agreements don’t usually come with an expiration date, but this story is so old nobody will care. Still, names have been changed to protect… oh… me.
I was doing this Clipper-on-Unix project (yes!) in 1996. It was a really big deal. The idea was to migrate a rather large vertical application from FoxPro on SCO Xenix (doesn’t that make you smile already?) to FlagShip on Linux. We would add a few major features, mainly interfaces to credit cards and some application-specific hardware. We had a few months to do it, and I was the only Clipper guy. (And by the way, can I just say that FlagShip itself was all kinds of awesome?)
By “we” I mean I was subcontracting this work. I was being paid by the vertical systems vendor, not the end client. Very important point.
One part of the specification was “interface to the Central Registration System.” This software was going to be in a few hundred locations, and every location had to run real-time-ish transactions into the Central Registration System (CRS). So it had to work over modem lines (remember the timeframe here) and with reasonable speed. The client supplied fairly good interface specs too. This looked really hard, but on the other hand our existing vertical product only supported a slice of CRS functionality anyway, like 10%. So the “interface” part of it would be only 10% too. Right?
We flew out to the client headquarters to show off the nearly-completed application. There was a horrible, horrible problem in my modem-specific code–something to do with sign extension in C!–but I solved that in the hotel room around 4:00 a.m. the day of the demo.
…one of the acceptance testers said something about not being able to perform a certain operation on our software, that the CRS had an interface for.
I was surprised. Very surprised. The spec called for a straight port, plus Feature A, Feature B, and Feature C. It did not mention Features D through Z. And this operation was definitely in Feature Z territory.
So I said, more or less, “That’s Feature Z. We don’t have Feature Z.”
And the client said, “It’s part of the CRS interface!”
Obviously we’re unclear on what an “interface” is.
I think it’s pretty clear that an “interface” is a connection between systems. If my application doesn’t create widgets, and the “interface” spec says, “If you’re creating widgets, here’s the transaction you have to send,” then my response is “We’re good here. There is no widget creation.”
The client took it to mean our application is supposed to make widgets now. And it didn’t.
The vertical system vendor, facing a disappointed client on one side–a really big disappointed client–and overworked me on the other side, figured it made more sense to blame overworked me for not implementing the widget creator code.
Let’s get this straight.
I’d brought this up in conference calls a couple of months previously. “Hey Management Guy,” I said when reviewing the interface spec, “There’s this whole section on Widget Creation Messages. Our app doesn’t do that. How would you like us to handle the interface on that?”
And the Management Guy said, “Then that doesn’t apply to you.”
All righty then! I didn’t give it much thought after that. Over the succeeding months, when we made progress calls with various client personnel, the Widget Creation feature never came up. They knew we didn’t do Widgets.
But then we showed up. Not for the first time.
With the application. Also not for the first time.
And that time the lack of Widget Creation was an issue.
My point, and I do have one.
I might have a few points.
- Maybe it’s write a negative spec. Detail what isn’t in the scope of work in addition to what is.
- Maybe it’s make sure you know who the client is. The “kid” who busted this open was not someone with a lot of rank in the client company. She wasn’t in any of the planning, design, review, or status meetings.
- Maybe it’s do frequent releases. So the client at least has a chance of spotting the discrepancy sooner rather than later.
- Maybe it’s watch your contractual language. This part is what saved me; I made sure the vertical systems vendor warranted that their existing code base already had the required functionality except for Features A, B, and C. You could draw a Venn diagram and show that Feature Z was either the client’s responsibility (because it wasn’t considered “required”) or the vendor’s (because it was “required” and they had “warranted” it) but definitely not mine.
- Maybe it’s keep asking the same questions over and over again. You know what? I have no patience for that. I need to be talking to the decision maker, or someone who has authority to represent the decision maker. If they lack authority to commit, then asking for feature decisions is a clear waste of effort.
So that’s my little horror story for today. Maybe later I’ll fill in the “not letting me refactor” bit of the saga. What a nightmare that was.