a dumb programming mistake

I had a couple of dumb development mistakes come and bite me in the butt this week, and I thought I’d share them here – well, at least one for now.

Without going in to the type of data too much here – the specifics aren’t important – the system I’ve got needed to show a list of data to a user.  Initially we just showed all the data to the one user.  Later, we added other user types.  However, my controller code (MVC-style) simply defined different views to use based on user type, but never changed the query.  So, whether you were an admin, or an area user, or a distinct individual which should only have seen a few items from the list, your view was passed all of the data.  The views simply filtered out which ones to display during a loop.

Stupid?  Yes.  Noticeable?  Not at all.  I looked at this code yesterday and remember thinking at the time “yeah, I’ll go back and make this better later” – I was planning on overhauling the user/role system, and I’d fix it all later.  That never happened, and over the past couple years, this has become slower and slower.

Fast forwards to yesterday, and we had 80 processes each being handed *290,000* objects ina view, in most cases to filter and display, say, 60.  Even getting new updated software on the server today was a pain, because we were continually hitting loads of 40-70 (unix loads, 15 min avg of 60 was where we were at most of today).

This came to a head the past couple days because our usage patterns changed – user load spiked both because of timing in the month and the user base has grown.  It was a perfect storm, and I was caught in the middle.  The upside is that I found this major issue and it’s resolved.  The downside is that it took almost 2 days (mon and tue) because I was finding other things I thought were the culprits; they were issues, but had no major impact given the 800lb gorilla in the room.

Lessons learned?  I’m not immune to even basic stupid oversights.  The moment I saw this code, I knew the issue, but I’ve not looked at it in… 3 years?  There was no need to, so I never went back to audit for stupid code.  Perhaps I need to budget more time for stupidity audits?

Any major faux pas you care to share or admit to?


I'm currently working on a book for web freelancers, covering everything you need to know to get started or just get better. Want to stay updated? Sign up for my mailing list to get updates when the book is ready to be released!

Web Developer Freelancing Handbook

Share and Enjoy:
  • del.icio.us
  • DZone
  • Facebook
  • Reddit
  • StumbleUpon
  • Digg
  • Simpy
  • Technorati

{ 3 comments to read ... please submit one more! }

  1. It was not so much of a mistake, more a reallocation of your time. Things like this happen, and if you client doesn’t budget for maintenance, then they won’t pay for changes they wont directly see. Its a problem I face all the time.

  2. Hi Michael,

    I think you have have followed Microsoft’s strategy when it comes to releasing code – which is release now, patch later.

    There are many programmers who follow this strategy thinking that it’ll save them more time.

    It’s good that you fixed your own code – I suspect that for others, this would have taken them a week to fix.

  3. One of the sayings often quoted by Agileistas, attributed to Knuth, is “premature optimization is the root of all evil.” As practiced, and as you described, it is not so much about hair-brained lapses as deliberate trade-off of your time programming for an indeterminate number of CPU cycles. In other words, it isn’t that you know exactly how much of a gain you might have gotten by spending more time thinking about it, you just made the judgement call that thinking about it more at that moment was not absolutely a necessity. You chose to rack up a little technical debt and pay for it later.

    As I see it, it is more the common practice than the exception: the trick is in adequately predicting which areas are going to rise to the level of an acute critical impact and which areas are going to pose a risk of death by a thousand cuts, and getting both into the stream of work.

{ 0 Pingbacks/Trackbacks }

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="">



0.1906750202179