One cool and sunny winter day, a beautiful young woman named Kate Libby (a.k.a "Acid Burn") was
writing some mean code. That code was part of a new system that would integrate
aspects of the Organization's SharePoint site with its Active Directory and
various databases. (Kate had since grown out of her
hackerish ways.)
It was early in the morning when the piece of code had finally passed all the tests and was ready to deploy - just about two hours into the day. At this rate, Kate would be at the
pub by noon for a couple of pints, and then off to play a game of pickup
Football in the early afternoon down at the park by her office.
Kate hit the deploy button and started packing her things, getting ready to leave. Just a quick
verification on the live site and off she'd be.
"Oh jeez, what's wrong now?" Kate asked herself. "Why can't anything
just work?"
All the unit tests had passed. All the integration tests had passed. All the acceptance
tests had passed. All the tests-by-hand had passed. What was the difference between
the test site and the live one?
The error messages were largely useless. The last time Kate was getting useless error messages,
there was an issue with differences in credentials to
AD, SharePoint, the database server, or any combination of them. Kate proceeded
under that assumption - it had a relatively high degree of being correct.
Twelve hours into three rewrites (trying different strategies to do the same thing) and several
hundred WTFs later, it finally hit her:
"OMFG," yelled Kate.
She noticed that it worked in Firefox, but not in Internet Explorer. After another round of WTFs and some time spent wondering why the different browsers caused a
server error, and then some time wondering why SharePoint should error out on its own browser, she realized:
The issue wasn't with
her code at all - it never had been.
The form was supposed to be a normal form - nothing to do with ASP.NET at all. But ASP didn't
care - it wanted to see
EnableEventValidation in the
@Page directive
to let you submit your own form - but only through Internet Explorer.
Kate's story is a tragedy: the essential complexity of the problem took her a couple of hours, while the accidental complexity ate up twelve. It cost her a couple of pints and some
good fun on the field.
Luckily, you can avoid twelve hours of useless re-work if you just learn the lesson from Kate Libby's
horrific tale:
isolate errors before you fix them. Otherwise, you might spend a
ridiculous amount of time "fixing" the parts that already work.
Hey! Why don't you make your life easier and subscribe to the full post
or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate
wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!
Leave a comment
I think perhaps Crash Override was messing with her???
Posted by
Ben Nadel
on Mar 05, 2008 at 12:06 PM UTC - 5 hrs
I guess we can all learn different things from the same story. The lesson I learned (or at least re-affirmed) is to stay away from tools like SharePoint which are high in accidental complexity.
Posted by Steve Campbell
on Mar 05, 2008 at 01:30 PM UTC - 5 hrs
@Ben: The world may never know!
@Steve: Good point! I guess Kate could have just refused to work on the software, or gotten another job. =)
About my POV on SharePoint in general - it's really easy for just about anyone to build a site that gets you to 90% functionality of the app you want to build (I'll admit that 10% of that requires someone with the mind of a programmer but perhaps not the knowledge).
It's just that other 10% that seems near impossible (even to a programmer) where doing something similar on another platform wouldn't take near as much effort.
I can tell you, if it had been a home-brew application, Kate's code (the "essential complexity" part of it) would have taken under an hour to write as opposed to the two (given a sufficiently maintainable base application). But the rest of the app would have taken much longer than it originally did. What's a decision-maker to do?
Posted by
Sammy Larbi
on Mar 05, 2008 at 02:09 PM UTC - 5 hrs
hi
I have a big issue hear i can isolate problems so quikly and somtimes it takes me long time to fix it. which technic can i use to respond quickly?
Posted by Thuso
on May 30, 2008 at 08:50 AM UTC - 5 hrs
Thuso - If your platform has a debugger, use that - step through the code one statement at a time to see where it goes wrong. Or set plenty of breakpoints to narrow down between which two something goes wrong.
If you don't have a debugger, or prefer not to use one, you can print variables values out and see where they go wrong - narrowing the area you search between each time.
Start taking out unnecessary code to see if that's breaking it. Just get down to the essential part of the problem. The idea is to narrow down the places you are looking until you find what part of the code is causing the problem. Then, you can focus your efforts there.
Hope that helps,
Sam
Posted by
Sammy Larbi
on May 30, 2008 at 09:53 AM UTC - 5 hrs
