Many years ago I worked at Bankers Trust Australia, building derivative product applications with VMS Cobol for the user interface and Fortran for the numerically intensive parts. I mention the technology so that you can understand that this was the early days of the derivatives markets when there were only a few players in Australia, using relatively unsophisticated technology. I remember how proud we were of the first release, particularly of the way we validated all the user input and provided field-by-field feedback to the traders. Then I was lead into a trap.
"Wow, that validation is really impressive. It must have taken you quite a while to do that", said a trader.
"Yeah, it probably took a few weeks to get it all right", we replied.
"So you could have delivered it a few weeks earlier if you hadn't done that?"
"Yes, but the application would have crashed each time you made a mistake and you'd have had to start again", we said.
"We're pretty smart, and we can learnt to deal with that. Next time we'd rather have the features two weeks earlier so we can make some money from them thanks".
The underlying problem was that we hadn't talked to them about what was important (my excuse is that it was a long time ago and I was young and naive), but the lesson has stuck with me. In that situation, an input function vomiting it's guts on the screen was a scope issue, not a quality issue. In the years since I've regularly heard people say "we cut quality to go faster" or "we cut quality to finish earlier", but when I dig deeper I invariably hear that they altered the behaviour from the end-user perspective, and to me, a developer on a software project, that's cutting scope. I appreciate that other people with different perspectives might consider these features to be the difference between a high-quality or low-quality application, so when we start talking about "quality" we probably need to clearly understand which perspective we're talking about.
I was reminded of that by a recent post by Uncle Bob that starts with "People often make the argument that time to market is more important that quality. I’m not sure just what they mean by that. Do they mean that it’s ok if 20% of the features don’t work so long as they deliver quickly? If so, that’s just stupid.". I think that would be stupid, but what I think people mean is that the internal quality of the code has been sacrificed to reduce initial time to market, which is a very different proposition.
Subscribe to:
Post Comments (Atom)
Posts
When we define quality as 'value to some person', then I think the scope issues you describe are still quality issues. Someone cares about those things, but perhaps not the people who were most important.
ReplyDeleteSo if you want a precise way to talk about quality, you could try that definition. There are a lot of others though, so one problem is that we frequently have a precise definition of quality in our own head, but it's different to everyone else's.
I accept that. I think that there are layers to the project, and what is "quality" at one layer often manifests as "scope" for the layer below.
ReplyDeleteSeeing your model and my model side by side, my new model that says that one man's scope is another man's quality helps me explain a lot :D
ReplyDelete