Search This Blog


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.