Knowledge of the business domain is essential to developers. They must know the business as well as the business folks know it.
We have all worked in environments where the business analyst’s word is gospel. The analyst specifies a solution, and the developer translates it verbatim into code.
This approach to software development is less then optimal.
Imagine sending a running back onto the field blindfolded. We tell him, never mind that you cannot see a thing. The analyst will relay instructions to your ear. Follow them to the letter and Bob’s your uncle.
- Run 6 yards on a 37 degree angle to the left. Your left, not mine.
- Now tack right, 82 degrees, and run 15 yards at a speed of 26 miles per hour.
- Wait, 300 pound linebacker at 7 ‘o’ clock. Wheel, dummy, wheel.
- Uh oh, too late. No, wait. The linebacker got tripped by his own cornerback!
See, the defense has blindfolds on too. In fact, all 22 players on the field are blind as bats. They are unseeing puppets, lumbering about, whose strings the business analyst is pulling. Don’t you think there will be stumbles? You bet there will be. The business analysts have to be superhuman to get everything right all the time. Your team must loose the blindfolds.
Pre-empt the bug
Business folks and analysts are as fallible as the next person. There will be holes in the information they provide. These gaps can cause errors. Developers must recognize and fill those gaps so that they can avoid those errors. The alternative is to let the error happen, hope that someone catches it, then fix the error. How can this ever be better than avoiding the error in the first place?