… a blog entry in which I define the term “proving”. I’m defining it here because I needed to link to a definition and couldn’t find a suitable URL to point to.
A few years ago, we were in a meeting when an architect explained to the project manager “we’ll be spending the first few weeks of the project proving the technology”. The manager was a taken aback. He took a deep breath and pointed out that the project was already committed to the technology - J2EE Web etc - and that the project sponsors would be a smidgen disappointed to learn that the underlying technology was “unproven”. Really, everyone was on the same proverbial page, but it was clear that no-one in the room (me included) had a solid understanding of “prove”.
What does it mean “to prove the framework” or to “prove the MVC architecture”? Are you proving these things exist? Checking if they’re feasible? Are you deriving a mathematical proof that they it’s inevitable they will improve business value? Here’s one definition:
- To establish the truth or validity of by presentation of argument or evidence.
- Law. To establish the authenticity of (a will).
- To determine the quality of by testing; try out.
- Mathematics. To demonstrate the validity of (a hypothesis or proposition). To verify (the result of a calculation).
- Printing. To make a sample impression of (type).
- Archaic. To find out or learn (something) through experience.
The third and sixth definitions say it best. Proving a technology means bashing it around to see what works and what doesn’t. According to The Straight Dope, it derives from a medieval term, Exceptio probat regulam, which is where you get seemingly paradoxical expressions like “the exception that proves the rule”, “proving ground”, and “the proof of the pudding”. However, said article also refutes that theory completely! In any event, it’s certainly a useful way to explain the usage in a software context.
Definitions - and arguments about them - are rather boring. This post is not here to prove a point (sorry), but to lend significance to an idea. Proving technology early on is a smart strategy for reducing risks later on. It’s really the idea behind the XP notion of “spiking” and also a key jusitifcation for the more traditional idea of throwaway prototypes; prototypes can be used to prove technology, not just for user acceptance.
1 response so far ↓
1 Software As She’s Developed » Blog Archive » Designing Like a Pollyanna: Have your Cake and Eat it Too // Nov 23, 2007 at 3:34 am
[…] So these trade-offs are useful, but shouldn’t be an automatic assumption. It plays to a higher-level rule about design and lateral thinking: Ignore constraints at first. In too many cases, people are afraid of going down certain paths because they can immediately detect an obstacle down the road. I once tried producing a novel design with a domain specialist who would immediately shoot down most any idea I had on the basis that users would never work with it. Once I bypassed him and got to the users themselves, the situation was quite different; the users embraced the concept and gave further suggestions for improvement. The domain specialist, who had long since working as an active user, was applying constraints too early and preventing us from proving the concept (“proving” == “bashing into shape”). In the same way, when we automatically assume “improving X will diminish Y”, what we’re doing is limiting our options prematurely. Better to ask first “is there a way I can improve both”, or, failing that, “is there a way I can deliver the critical attribute X without diminishing Y too much?”. […]
Leave a Comment