No, it’s not Agile methodologies, Ruby on Rails skills, or Test Driven Development. [click to continue…]


On Not Knowing Until You Know

by bob on December 25, 2012

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.



On Professionalism

December 25, 2012

In software development, there are — how to put it delicately? — prima donnas.  It’s always been that way, but this year I’ve had more than my share to deal with, and it’s moved me to reflect on the nature of professional conduct.  What, exactly, constitutes “professional conduct” in this field? Accusations of “unprofessionalism”, after […]

Read the full article →

Connecting to a Mirrored Sql Server Database With No Failover Specified

March 10, 2012

I was testing a new development tool today that connects to remote servers using a proprietary connection string builder that doesn’t allow you to specify a failover server.  Since I was connecting to a mirrored database I was curious what the implications were for not specifying a “Failover Partner” in the connection string. The answer […]

Read the full article →

On Solutions Looking For Problems

March 8, 2012

Microsoft has now made Windows 8 and its Metro touch interface available for us all to look at and Neil McAllister over at InfoWorld isn’t mincing words.  He’s calling the Metro value proposition for developers “a con”.  His fellow columnist J. Peter Bruzzese calls it Windows Frankenstein.  Meanwhile Visual Studio 11 is getting a lukewarm […]

Read the full article →

On Usability

March 2, 2012

It’s spring, when many US citizens not only have to cope with figuring out their income taxes, but if they have college-bound or college-age children, learn that there are things worse — far worse — than the dreaded Form 1040. I’m speaking of FAFSA and related “now you have to dance for your money” applications […]

Read the full article →

On Intuition

February 28, 2012

We techno-geeks like to think that we make all our decisions based on dispassionate evaluation of empirical facts, but there are times when things just don’t pass the sniff test. I’ve been in this game for nearly 30 years and my sniffer sometimes smells that “off” quality of the air in the IT fridge in […]

Read the full article →

Fixing an OutOfMemoryException on a DataTable.NewRow() Call

October 12, 2011

Few things were less expected by me yesterday than the out of memory exception that was suddenly being thrown by very mature code that had functioned pretty much unchanged for about five years.  Especially when the offending line of code simply created an empty DataRow with less than two dozen columns.  What, I thought, could […]

Read the full article →

SQL Server INSTEAD OF Trigger “Gotchas” Revealed

May 26, 2011

I just finished implementing a schema change on a table that is central to a public-facing database.  The objective was to normalize the table, and this required that the original table be broken down into five tables.  This will allow my client a lot more flexibility, but it also means that hundreds of thousands of […]

Read the full article →

When is a Routine Too Big?

March 14, 2011

I’m thinking — and not for the first time — of slimming down a monster method that has grown beyond the size any “well-written” routine is “supposed” to be.  Depending on who you’re listening to, no routine should exceed a hundred or so lines of code, or two or three screen’s worth.  And almost universally, […]

Read the full article →