object-relational impedance mismatch (often addressed with
ORM tools), the
object-XML impedance mismatch (often addressed with
OXM tools), and even the
developer-DBA impedance mismatch. I don’t believe that these impedance mismatches are as difficult as they are
sometimes made out to be, but for those wishing to mitigate them, we have tools such as
Java Persistence API implementations and
JDO implementations for dealing with the object-relational mismatch (and some of the developer-DBA impedance mismatch) and similarly have approaches such as
Apache Commons Digester for dealing with the object-XML mismatch (and .NET’s
LINQ deals with both
OXM mismatches). At this point in my career, I believe the developer/non-developer impedance mismatch is perhaps the most frustrating impedance mismatch I have run into.
proven practices (my new preferred term for what I think "
best practices" was originally intended to mean) for dealing with the developer/non-developer mismatch. In this post, I look at some of the most common areas of developer/non-developer mismatch and speculate as to why they occur and what can be done to address these specific areas of developer/non-developer impedance mismatch.
DRY Principle / Modularity
Don’t Repeat Yourself) principles coined in the often-referenced book
The Pragmatic Programmer: From Journeyman to Master. Although the term was coined in this 1999 book, the practice had been one that developers for decades had understood to some degree. Regardless of native spoken language or favorite programming language, developers today widely recognize virtues of some degree of DRY-ness. There may be
some debate as to what level this should be taken (I’ve seen it taken past the point of common sense), but most of us agree with the perils of repeated documentation at different levels of the software product or of repeated code (
Faith in DRY; no hope for software," writes, "Today we produce software through a laborious, undisciplined process that combines the low quality work of many with the heroic high quality work of a few. … Not enough people believe in DRY and other good practices like it." I believe this is especially true when one considers the non-developers involved in a software development project. In my experience, the developers generally do see the value in some significant degree of DRY, but non-developer stakeholders see little value in DRY principles.
Readable and Maintainable Code
Overbearing Processes and Management Decisions
Bean Counting and Pencil Pushing
bean counting and
pencil-pushing will be required.. Clients or consumers directly or indirectly finance the creation of software. It can be difficult for developers to recognize and appreciate the legitimate management and metrics collection that goes on during these business-oriented phases. It can be equally difficult for managers and other non-developers to understand that some things are more subtle than the apparent "bottom line." Non-developers may over-emphasize short-term "bottom line" considerations at the expense of long-term quality and maintainability of the product while developers may overly neglect bottom line considerations and create software products that require too much time and investment to justify their likely return on investment.
lines of code, number of defects in various states, number of requirements, and so forth to feel like he or she has a handle on the software development progress being made. It
doesn’t really matter that these are not created equally and should not be counted as if they are equal.
Battle for Control
Coding: Job for a Craftsman or for a Technician?
Appreciation of Software Development Nuances and Subtleties
Developers Aren’t So Different from Others, But Then They Are
most often-quoted books in the areas of software development and
software development management. One of its great quotes is made early in the work (first sentence of Preface to the First Edition): "In many ways, managing a large computer programming project is like managing any other large undertaking—in more ways than most programmers believe. But in many other ways it is different—in more ways than most professional managers expect." One of the key explanations of the impedance mismatch between developers and non-developer managers seems to lie in this profound statement. Developers, as a group, probably should be more willing to buy into certain proven "traditional" management approaches, but managers need to avoid falling into the trap of thinking that the tactics outlined in the latest business management book will be sufficient for managing software developers.
What Values Most
We in the software development community tend to deal with mismatches all the time. We often spend significant energy and time "gluing" things together that weren’t necessarily designed to go together. Despite all of this technical experience we have making incongruent pieces work together, we still seem to have difficulty resolving perhaps the most difficult and most important mismatch of all: the
mismatch between software developers and people who are not software developers. Although there are some positives that come from this (such as checks-and-balances on "science fair projects"), there is significant dysfunction, angst, resentment, and demoralization caused by this impedance mismatch.