28 July 2011

A BA's Rules to Software Developers

I respect most developers a lot, mostly because they have a job that I would absolutely hate to even consider doing. Several times in my life, mostly when I was incredibly frustrated at being unable to find an application that did exactly what I needed done, I have attempted to learn how to program. I even went so far as to spend a couple weeks learning VB5 to create an application to store data from an online game I played and it (mostly) worked.

But never could I do that job for a living. Nothing wrong with the job, its just not one that in any way suits me. I understand what developers do, and in some ways I do many of the same things (logically tear apart a problem, take the pieces and form them back into a solution, stare at a monitor all day, etc), but its the writing of the code itself that just bores me to no end.

One of the bloggers I follow, Ben Brooks, recently published a list of rules from users to developers. With that in mind, I humbly submit to my developer friends a list of things that drive me nuts when you do them. These are the rules by which you should live (yeah, the non-dev telling the dev what to do; I know, hubris). Be aware that these rules are for dealing with me, not Joe User, the guy who has trouble finding the power switch on his PC. When you deal with Joe, please feel free to disregard all of what I say below.
  1. Don't tell me it can't be done; I know it can. Yes, it could take a server the size of the moon, more money that Scrooge McDuck has in his vault and a project duration that couldn't be completed before the Sun runs out of hydrogen, but it could be done.
  2. Give me better options. I'm a pretty smart guy (Mensa says so), but if you're a developer, chances are, you're pretty smart, too. I come up with some pretty good ideas and I'm sure you can, too. If your idea is better than mine, I want to hear about it.
  3. If my idea sucks, yours better not. Don't tell me how awful my idea is if you can't come up with a better one. Please note that a 'better one' is not defined as you doing nothing.
  4. Don't lead me down a wrong path intentionally. I once worked with a dev who would explain to me a problem and present two solutions, one obviously bad and one that seemed to work. When I would select the one that seemed to work, he would tell me all the horrible things about the option I selected he intentionally left out the first time. Give me all the information I need to make an informed decision.
  5. Work with me. I value your opinion about technical details, so please value mine about business needs. My job is not to make your life miserable so please don't feel its your job to make my life miserable.
  6. Never tell me the odds (wait, no, that's Han Solo's rule; nevermind.)
  7. Don't become a lone gunman. We're not out to get you nor is everything worthy of a loony conspiracy theory. Yes, it is true, your knowledge will likely be incomplete during the project, but don't fear, so will everyone else's knowledge.
  8. Development is not an end unto itself. Never forget that even if you have perfect architecture, defect free code and standards compliant output, you can still completely fail to provide any business value. You don't have a job to churn out code, you have a job to churn out worthwhile code.
  9. Your opinion is worth just as much as everyone else's (which means not a whole lot). Don't refuse to do something just because you don't like the idea. Refuse to do something because the idea is objectively deficient, not because you just don't like it.
  10. You're not an android so don't think you are the final arbiter of what is logical. You're human and equally as able to suffer emotional pitfalls as the rest of us.
  11. Lastly, don't go rogue. Its one thing to daydream about sending the system down in flames, but its something else to actively pursue that as the goal. If your objections are so serious, get out before you try and sink it like it was the Titanic.


  1. Anonymous1:51 am

    Your 1st sentence and 1st point contradict each other.

    If you don't like what the developer is telling, you....then do it yourself.

  2. Actually, there is zero contradiction.

    If you don't like the job your heart surgeon is doing, do you go to medical school and become a heart surgeon? No.

    If you don't like the job the barista is doing, do you hop behind the counter, push them out of the way and do it yourself? No.

    The answer to these questions is no. I'm a BA and a development manager. I do excellent work, and here's the key point, within my area of expertise. I'm not a developer and have no desire to do that work, but I do know enough from many years of working on technology projects to call BS when someone tells me something isn't possible.

    My point is not that a developer can't suggest it to be unwise to do something or that there might be better ways to do something, only that to tell me no and provide no other alternatives is a cop-out answer.

  3. And with so little provocation a defensive stance is taken...

    Ted's post is meant to be a friendly poke. But anon, without a rapport and relationship with Ted has bristled.

    Such is the way of the internetz.

  4. Now we need the BA rules for business people/users. I think they have to a bit nicer (or at least worded in a nicer way), but I have a few suggestions if/when you do it.

  5. David, that's a great suggestion. I have planned to blog this weekend about things BAs can learn from developers. Its funny that when I wrote this post, I intended to do one from the other perspective, but it looks like anonymous tried to do it for me first. ;) I'll add your suggestion to the list as well!

  6. The worst thing a developer can say is can't