T-SQL Tuesday #13 – What the Business Says Is Not What the Business Wants

Steve Jones created this month’s topic: What the business says is not what the business wants. Despite the inflammatory title, it’s really about interacting with business: What issues have you had in interacting with the business to get your job done? I’m going to piss a lot of you off right now: it’s your fault. Ready to get more angry? Shut up and listen. Stop. Shut up. Listen. When you start having those gut reactions about terminology, proper technique, or anything else: shut up and listen. You don’t make cars or DVDs or coffee makers. The business users don’t write code. There’s a knowledge gap. The users are probably talking like that because they want you to take them seriously. STFU and listen. When you’re talking to business users, turn off the thinking part of your brain that is already designing an elegant solution in BCNF that uses the latest .NET IFlangingSkrillAdapter and a combination of Silverlight, HTML5, and buttplugs to solve the problem. Stop it. Stop it right now. Just listen to what the users are saying to you. Listen to how they’re saying it. Underneath that project they’re asking you to build, there’s a real problem that you need to solve. Sometimes, they aren’t even asking you to solve the real problem. Sometimes they’re asking you to solve a problem that wouldn’t exist if someone had listened three years ago. When I started out in IT, I wanted to build awesome things. I wanted to change the world and make smart solutions and have everyone look at me and say “Oh, look at how clever he is!” Clever software isn’t going to solve your users’ problems. Time after time I had to go back and forth with the users. Every time we met, we’d both be more frustrated – things were going slower than expected and features didn’t work as designed. I’d stalk back to my desk after those meetings, grumbling the whole way about how the users didn’t know what they wanted and how they should let me design what they wanted. You know what happens when you let computer geeks design something for humans to use? You end up with elegant, useless, software that doesn’t help anyone. This really hit home a few years ago. A buddy and I were working at a client solving some of their needs. When he was talking to one of the users, he noticed that she seemed to be holding back. He stopped for the day and said, “Let’s meet again tomorrow at 9:00 and take a look at this fresh.” She agreed. The next day, my buddy comes into the office, grabs a fresh pad of paper and walks off to his meeting. He showed up three hours later demanding more paper. I gave him one of my many spare legal pads and kept typing away, working on my elegant code that would interface between six disparate systems. At the end of the day, my buddy had two legal pads of notes. Think about that it: in 8 hours of listening to a user, my friend was able to fill two legal pads with factual notes. There was nothing speculative in there. It was all facts about processes, business rules, and the information that was moving around inside the company. The next day, we talked about the underlying problems. At first we started talking about the systems we could build and the consulting money that was there and the commission we could make. We stopped. We looked at the papers again. The problem wasn’t that there was software to be written and rates to be raised. The problem was that there was software in the first place. Sure, the software had been written to fill some nominal business need, but it really existed to satisfy a developer’s visceral urge to try out something new. In solving their programming problems, our predecessors had removed the business needs and created their own elegant, but useless, software. Listen to your users. They know what they want and they know what they need. They may not always have the words and sometimes you just need to listen.