If I had a nickel for every time I’ve heard someone in IT say something along the lines of “we want to be a trusted partner,” I’d be wealthy. If I had a nickel for every time a business person said it, I’d be broke. Becoming a trusted partner seems to be something that IT is obsessed with, but not so much on the business side.
I do think that being trusted is important, but no matter how much you talk about it, it will never be granted to you. It must be earned. While I can’t tell you how to earn it, I can give you a simple example of how it could be earned.
I’m not an auto mechanic, so I am forced to trust the guy at the mechanics to take care of my car. Because of the information inequality – he knows way more than I do about cars – I am always suspicious of his motives. After all, he is in the position to diagnose my problem and then make money on me by fixing the supposed problem. Here’s a person I inherently distrust. Sort of sounds like IT as well to me…
One day I took my car in because I swore something was wrong with it. I was prepared to pay for new brakes mentally. So, when they put it up on the lift, told me that the brakes were fine and then didn’t charge me, I started to see this shop in a different light. And it wasn’t just once that they didn’t push unnecessary work on me, but several visits. Usually I was just in for an oil change and since I was there I’d ask about something else. Time and time again they probably could have fleeced me and didn’t.
After that, I trusted them to tell me when things were wrong and was more willing to have them done. That’s what establishes trust. It’s not doing as you are asked, even if you do it cheaply. It’s not suggesting all kinds of new and shiny things you could do. It starts by doing something that is truly in the customer’s best interest in a way that they know it is. Sure, a fancy architecture might be in their best interests in a really long run, but your customer isn’t going to sense that.
Save all that for later, when they’re finally listening to you. Start off by demonstrating a willingness to solve their immediate problems, to save them money and time, and to help them avoid unnecessary work and you will have a much better chance of becoming trusted by the business. Continue to pretend you know better and you can just keep talking about becoming one.
Why is it when you’re driving around town, mostly what you see are McMansions and not more FallingWater-like houses?
I chose Fallingwater because it’s iconic of Wright’s masterful style of architecture. And yet, most people don’t seek out to purchase a house that looks like that. The American dream seems to be better defined by the McMansion. Why when you could have such a masterfully crafted and custom home like Fallingwater would most people prefer the McMansion?
Well, for one, people aren’t that unique (as much as we like to think we are) and so we tend to purchase things that aren’t that unique. A carefully crafted home is expensive. You pay a premium to acquire the services of a truly premium architect and builder to get a unique home. And finally, most of us don’t “need” Fallingwater. We need a roof over our heads.
Get where I’m going with this? If not, I’ll be more blunt: Agile software development bases itself on a craft-like approach to software development and puts (as Boehm and Turner wrote) “a premium on premium people.” If we look to the way we solve our own lives, where a relatively cookie cutter approach to home problems more than solves our needs, does the possibility exist that a canned approach to software development using average architects, designers and programmers might actually produce a useful result?
Many a person has pointed out that Apple designs for one person (Steve Jobs, presumably), and that Microsoft relies heavily on focus groups to design their software. Nobody debates that Apple garners a cult-like following for what they do, and Microsoft doesn’t. But the numbers don’t lie – we’d rather buy and use McMansions than Fallingwater. Cheap facsimiles appeal to us more for some reason than the real crafted approach. Just look at how the multitude of Android phones, which aren’t as good as iOS, are slowly overtaking Apple. Even Apple’s own Steve W. predicted that it will eventually happen.
Craftsmanship we seem to admire, but apparently from afar. Consider if what you’re delivering to your customer is really Fallingwater or just another McMansion. There’s nothing wrong with a McMansion if it meets your customer’s needs.
I was driving down the highway the other afternoon when I saw a billboard for some car. I don’t recall the car, but I do recall the slogan “Enough of ‘Good Enough'” it read. Presumably the implication was that other car manufacturers make a car that’s just “good enough” and that this car was exceptional.
“Good enough” is a common phrase in software development, and I get the concept, but not the practical applications of it that I see. Conceptually, you build something that is just enough to meet the customer’s needs and no more. The issue is, the definition of what a customer wants or needs isn’t exactly readily available. If you were making some sort of trivial object and dealing with economically perfect competition, good enough would make sense. You’d want to produce something that exactly met the customer’s needs and right around the same price as your competitors. Competition would assure your prices were kept low. Simplicity of the object would assure that product differentiation was a non-issue.
But software development is more of a monopolistic oligopoly. Your slightly different software is competing against others who solve similar problems but not in exactly the same way. The meaning of “good enough” begins to lose meaning because the myriad of trade-offs each competitor can make. You might offer feature X, the other might offer a product without the feature at a lower price point. Which will the customer buy? Is price all there is to it? Of course not.
Add on top of that the skewed meaning of “good enough” to many software developers and you’ve got yourself a real conundrum. I can’t count the number of times a software developer has informed me that the poor behavior of the software was user error. It’s so common, there’s a classic joke about it:
How many software engineers does it take to change a light bulb? None. We’ll document it in the manual.
In spirit, I love the idea of good enough – to never build more than your customer wants. But in practice, exactly what your customer wants may not be clear and even if it is, your developers are inclined (for some crazy reason) to make odd decisions about how the system should or shouldn’t function.
The car company is right. Enough of “good enough.” Pursue perfection.
Have you ever marveled at Microsoft Word? Probably not. People love to hate Microsoft and I’m not sure why. Although some of the early attempts, like that annoying paperclip “Clippy” who would pop up at inopportune times, weren’t so great, Word has quietly evolved into what I’d call a smart program.
It’s the little things, like knowing that when I type an asterisk that I’m probably starting a bulleted list, or knowing when I begin a paragraph with “1.” that I’m starting an ordered list. Or quietly correcting my commonly misspelled words (though occasionally it’s overzealous – it doesn’t do so well with technical jargon). Or automatically highlighting poor grammar and spelling errors which it isn’t sure how to correct. It’s these little things that save me time and reduce the errors I make.
And though we don’t think of it much, I believe that the little error-proofing behaviors that a program like Word is providing is what differentiates a “Smart System” from a not-so-smart one. By comparison, it’s not at all infrequent for me to encounter a product with a host of bugs which all get closed with some resolution akin to “the user was just using it wrong.” If the user is able to use it wrong, is that really the fault of the user or the software?
I believe it’s the latter. Smarter software makes people’s lives easier, not more confusing. Smarter software makes the simple decisions, the ones we don’t think about all that much because we think we’re know what we’re doing, automatic.
Smart developers anticipate these things and design smart software. Compliant developers code the requirements as specified and rarely consider how the system might be just that teensy bit smarter for the users. Then, when the bugs come, they call the undesirable or confusing behavior “enhancements,” because it was coded to spec.
What would a smart system do? What would your system do to be just slightly smarter? It doesn’t have to happen all in one instant, but incrementally becoming more usable, more intelligent, more able to let the user of your system focus on the real work instead of the software’s implementation details.
I was just reading a great article, despite its age, on why software developers don’t practice what they preach. One of the keys, as Humphrey points out, is that despite being taught best practices, we often view the programs as too small to deserve the attention of a full development lifecycle. Furthermore, we (professors of college courses and management presumably) focus on outcomes rather than on the process to get there.
As he says in the article, “This craft-like approach for advancing the state of software practice has not been effective in the past and it will almost certainly not be effective in the future.” And yet, we hear repeatedly of the software-as-a-craft viewpoint.
Moreover, he goes on, “As opposed to laboratory courses in chemistry, physics, or biology or the rigorous training of surgeons, software practices are largely ad-hoc and informal. Students thus become convinced that coding and testing are essential and everything else is optional. As they gain experience, it grows increasingly difficult to change their minds.” We see this in current practices espoused – test driven development, pair programming, automated code review and unit test tools, continuous integration and testing… all focused on coding and testing and very little on designing a good solution in the first place. Little attention is paid to boring, but proven practices such as Fagan-style inspections for analysis, design and coding.
While Humphrey’s research predates the current Agile movement, it is not reason to ignore the results of his research. Process has a place, and can show measurable advantage over coding and testing alone, both in terms of quality and speed.
If we desire to have rigor in our processes, then it is up to us as management to demand it and audit for it. We are in control of the outcomes if we choose to be. To get there, we need to spend less time looking over the budget spreadsheets and more time looking at exactly how our developers get things done.