Programming: What’s business got to do with it?

Businesspeople have two distinct roles in software building:

  1. To determine how software should look and behave as a user
  2. To prioritize the feature/bug fix list based on business priorities

By businesspeople, I mean the customer, the client, the program manager, the product owner, project manager, client liason, customer proxy or any non-technical and non-design person involved in a software project. Ideally this should not just be a guessing game, but based on their relationship with the customer, including feedback and user testing, as well as market research, etc.

If they do any less than this, then your software project will end up somewhere totally useless, even if it technically works.

If they do any more than this, then your software project will end up totally useless and will not work well technically either.

That’s the function of a businessperson on a software project.

There’s no sense in being precise when you don’t even know what you’re talking about – John von Neumann

Instead, most business people try to stick their noses where they don’t belong. Dictating technical and design decisions based on their qualification of, you know, having used MS Office before. They also try to manage software projects as if we were building a bridge instead of software, and as if we were low-skilled, replaceable cogs in a machine, instead of highly-skilled, professional craftsmen.

The result? Ugly, broken software.

Dr. Spaceman from 30 Rock

Would you, could you, to a doctor?

It’s like me trying to tell a surgeon how he should be performing surgery based on, you know, having body parts.  No, I don’t think we need those extra sutures.  Oh, you should be using the 1/5″ scalpel instead of the 1/8″.

Nevermind that he is a well-trained, highly skilled professional who has done this before.  By employing him to do work for you, you clearly not only have the right to dictate how he does his job, but also clearly know better than him.

Of course, any decent doctor would NOT comply, and probably has an ethical obligation not to do so.  Software development professionals should behave the same way.

What’s a highly-skilled professional to do?

The crux of the problem is that even though we know the right way to build software, most of the people who employ us don’t know it.

One solution would be to go work for a company that is run by technical people.  Apple and Google are the big examples, but there’s plenty of smaller fish out there.

Or you can find a position in a team with a strong technical leader.  The company may have a lot of BS, but a strong technical manager can shield his/her team from it and give them the freedom to build great software.

Both of those are great options, but to truly solve the problem wherever you are, it’s going to take education.  It’s not a particularly sexy idea, but it’s at the heart of every movement.  We can either sit around and whine that they don’t get it, or we can make it better.

Businesspeople just don’t know what they don’t know.

If we intend to work together (and it really seems inevitable, doesn’t it?) I submit that we need to help them understand what it would take to build great software.  As in, please do the two things outlined at the top of this post, and do them well.  And for everything else, please let us do what we came here to do: build great software.

9 Responses to “Programming: What’s business got to do with it?”

  1. SeanJA says:

    No, I will not put a million rows and columns on that page just because you are using excel to run your business.

    Is that Dr. Spaceman?

  2. SeanJA says:

    I guess hovering over the image would have answered that question… oh well

  3. Charles Chopin says:

    It’s kinda like I tell my wife: “You may tell me *what* you want done, or you may tell me *how* to do it. If you choose to tell me how to do it, I take no responsibility for the outcome . . .”

  4. Kenneth says:

    “as if we were low-skilled, replaceable cogs in a machine”
    Even if immediate management were to value a decent developer, there’s always upper management and if not, upper upper management (you get the point), whose only issue is the bottom line. The bottom line that drives decent developers out and replaces them with the cheapest developer possible, and they never pause to wonder why they have huge teams maintaining just a few applications, when all you really needed was a few great developers writing since inception.

  5. Did you hear the doctor stuff from Uncle Bob Martin? I’ve heard he saying this before, in a dutch podcast. Anyway, those are good ideas.

  6. Amber says:

    @Carlos I hadn’t heard Uncle Bob talk about the doctor analogy, but I’m a big fan of him and try to keep up with his blog.

    @Kenneth I think that having strong technical managers is so important. The fact is that hiring better developers is smarter for the bottom-line also. You can hire less good developers to produce more valuable work than mediocre programmers. You get more maintainable software with less downtime to your business. Smart programmers can think of the simple solutions to complex business problems that is just way over the head of mediocre programmers. It’s about managing up to teach them that.

  7. You’re hitting the nail, Amber. Totally agreed on the points made in the post. :)

  8. Matt says:

    I was with you until the very last sentence.

    “And for everything else, please let us do what we came here to do: build great software.”

    That’s one reason why programmers get a bad rap – it’s perceived (sometimes correctly) that the answer to every problem is code. I’d rework the sentence to say they came here to soave problems or something similar.

  9. Graham Lea says:

    Hi Amber.

    Interesting thoughts, but I have to disagree with your first point:
    “Businesspeople [should] determine how software should look and behave as a user”.

    Having just finished reading “The Inmates Are Running the Asylum” by Alan Cooper, I’m fairly convinced that neither business people nor software developers are the right people to “determine how software should look and behave”.

    While you’re right on the money that business people don’t have the necessary skills to dictate HOW to build software, Alan’s argument is that neither business people NOR programmers have the skills to correctly design the user experience that is needed by the users.

    If you haven’t read the book, I suggest you get a copy and see if it changes your mind on some of the things you’ve said above.

    Cheers,

    Graham.

Leave a Reply