“Why is (insert name here) so difficult to work with?”
I’ve had this question asked of me more than once. Once I probe a little – which generally involves multiple conversations and times where I’ve sat with both the developer(s) in question and the business people raising this issue – I find what some people would refer to as an “impedance mismatch. “
I’m sure you’ve heard the term before, but did you know that its origin lies in the electrical world? The term impedance is used to describe the resistance of a system. Impedance is essentially a measure of the amount that some object prevents the flow of electrical current. Electrical systems attempt to match sources and outputs to maximize power. When mismatch occurs, there is wasted energy.
Where is the mismatch in software development projects? If you are a business user, I’m sure you would be quick to say that developers really slow things down – causing “resistance” because they are so detail-oriented. In reality, when business people and developers are involved, the impedance mismatch is really a difference in expectations.
What I’ve observed over the years with software projects is that business people get frustrated by what they perceive as constant questions from developers about things they believe that they have already answered. I can appreciate the limited time that business users have available; it’s just that it is difficult from a development standpoint to operate any differently. Why?
Consider this: Without software, computers have no intelligence whatsoever. In fact, they are very literal and they will only do exactly what someone tells them to do and how they were told to do it. This means that every step in a business process, down to how the data is displayed, how it is stored, the operations and calculations needed to be performed must be given to the computer in the form of specific instructions.
This is why developers are “detail-oriented” (they have to be) and why business people sometimes get frustrated with continual questions from development teams. I’ve seen projects go astray because business input was limited, and development teams had to make guesses based on the information they had available to them – resulting in expensive and time-consuming re-work later because the system wasn’t what the business users thought that they were getting, another source of major frustration.
Why can't all of the questions be asked in advance? Since developers do not have the business background and experience, they cannot anticipate everything in advance. What usually happens on software projects is that the business problem starts out being expressed at a higher level than what will be sufficient later on as actual development is under way.
Starting at a high level is good, as it provides a project team with an overall idea of what the end solution should be. Just don't expect that every question can and will be anticipated up front. It might be helpful to keep the following in mind: Developers are dealing with an insanely stupid, very literal machine and will need your help in telling that machine what you want it to do. As the old saying goes: The devil is in the details.