I’m reading Extreme Programming Refactored: The Case Against XP from Apress Books. I have to confess that although I generally regard XP as an off-the-rails over-reaction to the perceived shortcomings of traditional software design and specification methods, I have some affinity for the XP concept that “the code is the design” — in this limited sense: in some scenarios, the process of coming up with a meaningful estimate of project cost requires so much effort that it’s equivalent to just doing the implementation in the first place.
I should qualify that by saying that clients often want so many guarantees and assurances regarding timelines and costs, yet for development purposes have such a nebulous idea of what they want, and desire so much freedom to keep changing what they want, that up-front design and sign-off on requirements sometimes becomes a fiction that we all pretend we engage in but in fact don’t actually do. This probably is in part because exaggerated XP concepts of emergent design were so undeservedly influential for many years. Its siren song appealed to the tendency of managers to want developers to just do something now, to provide faux closure and specious assurances and political cover at all costs. Not incidentally, XP’s aversion to written documentation exacerbated a natural tendency in business to allocate basically zero resources to technical and end user documentation, too. And in fairness, it worsened many a developer’s aversion to properly commenting and documenting their work.
All that being said, “not knowing until you know” is not just an artifact of business politics. Many times we’re asked for a new feature or enhancement in an existing, complex system and by the time the actual requirement is clarified and all the knock-on impacts and side effects are discovered and researched and accounted for, actually writing and testing the code is relatively minor. Clients like to pay for that minor part as if it’s the entire story, and it’s my never-ending job to bring that pesky time-consuming and necessary planning part to their awareness. Sometimes I’m even able to get them to see the importance of that after the fact documentation and training bit, too.
One obstacle to careful and thorough due diligence is that now and then, someone will come along who is sloppier, yet a good self-marketer, and will initially impress with their ability to sweep aside the concerns of cooler heads, and Make Things Happen. During the interim period before the inevitable flame-out, one must simply bide their time. I recall quoting a custom accounting system years ago for a manufacturer, who ended up having the owner’s nephew do the work at one fourth my quoted price. Ten months later a chastened and beleaguered owner called to have me untangle his nephew’s mess, and that led to a mutually enjoyable business relationship over the ensuing decade.
Another example comes from the above-mentioned XP exposé: the tale of a consultant who was told that his insistence on up front design ran counter to accepted XP practice and if he would not omit that step, the client would find someone who would. The consultant lost his bid for that important project … my guess though is that if he was gracious in defeat, a year or three down the pike he was be able to get the even more lucrative job of undoing the resulting damage. Ultimately it all comes down to trust, and an appreciation for careful work often comes only after first hand experience of the bitter fruits of more hip-seeming ad hoc efforts.
