The very first time I wrote an entire application in .NET, I was working to convert a VB6 application. It was a sales tool that had evolved over time. Years before I started on it, it was a couple of equations until it grew and grew. By the time I got there, it could connect to an ERP system and get the actual prices and lead times on parts. Both internal and external sales people depended on this application to do their job. I worked on this application for quite a while. At one point, about 12-18 months into the project one of the sales managers was looking at it. This was a man that didn’t use the software very much. Every once in a while, he’d need to fire it up to look up something for a customer. He was so used to the previous version that the first thing he said was “Where’s the next button?” The previous application had a next button to move from one tab group to another. In discussions about the UI we decided we didn’t need that functionality any more in the new version. Yet at the very first use by this person he asked for that functionality. I tried to explain why the next button was no longer there, the internal sales manager (who I’d had numerous discussions with) tried to explain why it was no longer there. But it didn’t matter. In his mind, if there was no next button, he didn’t feel like he could generate a quote.
It actually got to the point that when I left the company, I received a physical push button that the internal sales manager had labeled “Next.” That button sits on my desk today, 3 jobs later. It’s there as a reminder. It reminds me that sometimes the customer “just wants” something, and that’s ok. After all, most of the the time, I’m writing software for someone else to use. In the case of this sales application, it was a large part of their day to use this software.
I know it can be very frustrating to deal with these situations. After all, as developers, we’re paid to solve problems. We’re paid to know about practices of how people use an application. So when we present something to users, it’s not done absentmindedly. It’s done because in our professional opinion, it’s the best option. Much like people trust a doctor’s or lawyer’s “professional opinion”, developers expect their opinion to be trusted. When it’s not, we often start to think that our users are irrational.
For example, on that same project, we introduced a new paradigm. Before a quote was started, the type of quote had to be selected. These were usually things like the type of industry the quote was for, or the application that it was going to be used for. The intention of this was that we could do some data analytics on the application, such as “How many quotes did we do for industry X?” But we also did it so we could start setting some smart defaults for specific industries. For example, some industries needed copper instead of aluminum because of the environment that it was to be installed in. We were trying to have the application provide more data instead of requiring the user to always know that. But what was the first thing that the users said when they saw it? They said “Why do I have to click here to select this application? I didn’t use to have to do that? Now it takes me 3 clicks to start a quote, it used to only take me 2.”
To me, that was irrational. The clicks weren’t added for the sake of adding clicks, but instead to provide value to the customer, but they weren’t seeing that.
What I realized later in my career, however, is that for as much as irrationality annoys us as developers, we’re often just as guilty. It doesn’t always show in how developers use applications, but often in how things are done. Two areas that jump to my mind when I think about this is TDD and Pair Programming.
Both of these disciplines have some very passionate adopters. Developers that do TDD and developers that routinely pair program can easily talk about the benefits of each practice. For example, I’ve given no less than 3 separate conference talks on TDD, and it was my first Pluralsight course as well. Since I’ve started consistently doing TDD, I’ve seen so many benefits. When I talk to people about TDD a lot of them (most?) even assent to what I tell them. But when it comes to writing code, very few people ever make that shift and start doing TDD. It happens for a variety of reasons. They’re afraid it will take too much time, or they tried it once and ran into a problem with testing certain parts of code, or they’ve always just sat down and started writing etc. On the one hand, they’ll often say “I agree that the things TDD gets you are good” while at the same time saying “But I’m not going to do it.”
I think the same can be said about pair programming. In fact, I know it can, because it dawned on me this week that I don’t really want to pair program with someone despite the fact that numerous people practice pair programming and can tell me all about its benefits. Why don’t I want to do pair programming? For a variety of reasons. First, what if I want to take a small break and my pair doesn’t, so I want to be looking at reddit, or checking email, but I’m pairing with someone so I can’t. Secondly, what if the person I’m pairing with is way smarter than me? Are they going to be sitting there judging the code I write? Constantly thinking to themselves of better ways to write the code? What if the person I’m pairing with doesn’t write clean code? Am I just going to be a constant nag for things like better variable names?
You see, my reasons for not pairing have nothing to do with how effective pair programming is. It’s not that I think I can write code quicker without a pair. It’s not that I think I’ll have fewer errors if I just do it myself. It’s none of that. It’s simply that “I don’t want to.”
If we’re honest with ourselves, we’ll realize that both developers and users are part of a larger, irrational group of beings. That group has a name, and it’s called “humans.” Once I started realizing that, I started being able to work with customers. They stopped frustrating me so much. And that’s important. A developer has to be able to work with customers without constantly getting mad or frustrated, and the burden is on me, not my customers.