Saturday, September 26, 2009

6 Rules for Software Product Development

These are my basic rules for developing software products.  I wrote them while under the influence of a rather heavy Belgian Ale, still sweating from having mowed the entire lawn on an empty stomach.  My brain is on auto-pilot, sloshing around like a soaked bread roll in a fish bowl sitting on the dashboard of a 4x4 truck going up a mountain side.

Rule 1 – Apps should Control their Files

If opening a corrupted or invalid file causes your application to crash, your application is a complete piece of fucking shit.  Period.  There are zero exceptions to this rule. Ever.  Your app should read, parse and validate anything it tries to open and handle it clean.  Tell the user and offer them a way to work around it.  Don’t just puke up a hex error and die.  If you fail this rule, you should be kicked in the nuts repeatedly with combat boots.

Rule 2 – A New Competing Product Should Start at Par

If your 1.0 product doesn’t match your competitor’s product at the VERY minimum, you fucked up.  There is no excuse for competing by starting out on a shaky foot.  You already know what the competitor’s stuff can do.  Why would you even consider putting out something that doesn’t at least match that (let alone beat it)?

Rule 3 – Consistency Matters

Oh yes.  If your product has different looking dialog forms, or inconsistent command line syntax, you fucked up bad. Really bad!  In fact: you suck ass.  Ask yourself “does this option apply pervasively?”  “is my noun/verb syntax consistent"?”  If not, you suck ass.  I already said that, didn’t I.

Rule 4 – Versioning Isn’t just a Giggle Party Joke

0.009.01?  2009.01?  Version 4?  Version 4.0?  Make up your fucking mind!!!  If you release something “less” than 1.0 to the publi,c you’re a complete fucking idiot!  A dumbass dipshit numbnuts moron.  Go back to school or read a book for once.

Rule 5 – Ask for Input and Respect It

You either have customers or you’re looking to gain some.  If they speak up, you should pay attention to what they’re saying.  And when they submit feedback, you should respond to each one with something to acknowledge you (a) recieved it and (b) are reviewing it.  If a customer submits a comment and gets nothing back in return it’s the same as saying “fuck you, we want your money not your opinion.”  And if your product is stated to be in “beta” don’t EVER say “too late, maybe for the next release”.  That’s just ass-wipeness 101.  Alpha and Beta are still “unfinished” stages and therefore self-proclaimed as being in flux, aka “not finished”, or “not stablized”.  If you don’t want to field change requests before final release, then call it a “release candidate”.  Stop being a whiney ass pukeface like some turtleneck wearing snob.

Rule 6 – Pick a Respectable Name

Don’t name your “business product” something like “sweet nutsack” or “frilly foo-foo” or “galloping gay-face”.  Business customers wear suits, not Devo costumes.  They don’t have an artistic flair and giggle like 12 year old girls at a Jonas concert. They do boring shit like balance books, make forecasts and Powerpoint presentations and play golf.  Aim your shit at that and you’ll do ok.  Otherwise, you’re aiming at a barn with your eyes poked out.

Holy crap, I’m fired up right now.  I’m really tired of bullshit software developers acting like God just handed them a table to carry around.  I really need to drink some coffee and come down a bit.

Post a Comment