Engineering Priorities

A (really) short post on the priorities of hobby projects, 1st draft projects, final production grade ap­pli­ca­tions.


As per the post tag the below is only 14 serious and 34 for fun-

Hobby / 1st drafts:

  1. Novelty (Can I use this new shiny thing?)
  2. Per­for­mance (Can I make this new shiny thing go faster too??)
  3. Re­li­a­bil­i­ty (Oh yeah–it fails sometimes, but I just restart it.)
  4. Cor­rect­ness (Wait you mean it was supposed to solve problem X and not problem Y???)

As in: I want to try something new that’s fast, usually works, and normally returns me the right thing (for what I thought I was solving).

A serious hobby ap­pli­ca­tion might look like the following:

  1. Cor­rect­ness (My problem is solved!)
  2. Per­for­mance (Pretty fast too!)
  3. Novelty (I used this nifty new Python module)
  4. Re­li­a­bil­i­ty (It may only work on my desktop computer at home though)

As in: I fixed my personal problem with this specific solution that works pretty well–if you deviate even slightly outside my re­quire­ments it will probably break.

Final Production Grade:

  1. Cor­rect­ness (Our sales force is better leveraged–sales went up 15%)
  2. Re­li­a­bil­i­ty (The app is important to business sales, give me 99% uptime–that’s ~3.65 days / year of downtime by the way)
  3. Per­for­mance (It needs to go just fast enough to get the job done)
  4. Novelty (Your platform choices are Java 1.6, JBoss 6, Spring 3.1.0, and Hibernate 4–wait did we say ‘choices’?)

Obviously not all ap­pli­ca­tions follow this pattern. There are many hobby ap­pli­ca­tions that evolve into production grade ap­pli­ca­tions used by en­ter­pris­es (the linux kernel for example). Similarly there are production ap­pli­ca­tions that value per­for­mance over re­li­a­bil­i­ty, witness some of the issues in the last couple years with high frequency trading software. As the tag mentions, all just for fun.

Share