Are we willing to cross the crevasse?

posted by cjh, 20 January 2011

Dan North’s post on software craftsmanship, and Martin Fowler’s response to it, are right on the money regarding what’s required for programming to become a proper profession.

Ultimately, developers are mostly rather good at putting software together, even those who don’t use the most fashionable methods. Good software can be made using many different methods, not just the ones espoused by the current golden children of the software development fashion cliques, whether it be extreme, lean, agile, or whatever.

Where we continue to fail is in not even attempting to build the bridge that Dan and Martin talked about in The Yawning Crevasse of Doom. We mutter and sneer about how business folk don’t know what they want, and how they’re incapable of applying rational thought to that problem. They feed us endless waffle, and our job is to make it all make sense, to figure out what they need and to meet those needs.

I call BULLDUST! The business knows what it needs, mostly, or they wouldn’t open the dialog. The problem is with developers. We don’t want the business to read, understand or speak our languages, because that makes our speciality less special. Face it, we’ve spent all this time learning out how to describe the structure and function of a computer program in a formal way, and we don’t want someone else telling us why it doesn’t meet their needs. Especially when they don’t even seem to know what they need. It’s bad enough that we often build software that doesn’t meet the business needs, but we certainly don’t want to be told why.

The level of dialog engendered by these attitudes devolves to the business throwing their waffle words at us, and us throwing software back. Agile methods tell us how we can do that really quickly, so that a single interchange in this dialog might take as little as just one week.


And all because all we can speak is software, and all we can hear is waffle. Let me tell you something - the business actually does know what it wants. All we have to do is help them know how to say it. A way to capture the meanings that are in their heads.

If we can find a way to talk the same language, we’ll have dialog interchanges that take only seconds or minutes. Interchanges that don’t require building anything. Interchanges that carry meaning, in each direction, until we can agree on the nature of the things we’re talking about. Only then should we apply all those craftsmanship techniques to build the right thing in the right way.

That’s the kind of dialog a semantic modeling language can facilitate. You might like my one or you might not, but to advance, we must start trying to build such things. I have to say however, the dismissive responses I see from software craftsmen doesn’t improve my confidence that we have the will to fix this problem. Yes, I know that a semantic modeling language doesn’t do anything you can’t already do… except communicate back to your business users before you build the software. I can only fall back on the incredible enthusiasm I get from business folk and regular computer users when I show them what I’m attempting. They understand the nature of the problem that developers are so unable or unwilling to see.