One question that has been bouncing around in my mind is what, exactly, does one have to do to be considered Agile? Let’s look at the Agile Manifesto:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Every developer, no matter how experienced, has to dig in and fix bugs. This is, in my experience, the typical cycle: bug is reported bug is assigned to developer developer thinks the bug is fixed developer marks bug as resolved tester checks to see bug is fixed, but it isn’t. tester reopens bug, assigns it back to developer back to step number two. Repeat until developer (or tester) climbs to the top of a 307 foot administrative building with high-powered rifles to demonstrate USMC-worthy marksmanship.
Today was my last full time day on this contract. Tomorrow I start up full-time with another. Personally, I've gotten in the habit of looking a my past contract and conducting my own personal retrospective on what I learned or how I would do things differently. I figured that because my memory is getting worse in my old age, I'd started putting these things down on my blog.
For a greenfield project, don't use the database someone hands off to you
Note: I originally wrote this post on August 23, 2008. As things change with the book NHibernate in Action, I will be updating this post and resetting the date.
I'd like to take a break from boring you two readers of my blog about my experience with Linux and VMware, and take a moment to annoy you with a rant. Diversity is the spice of life after all.
This little remonstration of mine is about the Manning Early Access Program (MEAP).
Yesterday myself, Don, D'Arcy, and Eric were wandering around Seattle, just checking out the sights after the MVP Summit. We took a break from the usual "run down D'Arcy and Manitoba" shtick, and actually had a serious conversation on the relevance of stored procedures for your typical database development/line of business app. D'Arcy blogged take on it already. I was going to reply in his comments, but as the comments grew, I figured my own post was in order.
One of the biggest discussions that I typically get when I try to introduce things like NHibernate (i.e. OSS) on a new contract goes like this:
"We're a bit reluctant to use that because it will introduce more code into our code base that isn't ours. Because it's OSS, there's no support, and if there was a bug in it, we'd have to maintain it ourselves. That being case, we'd rather just write our own code, because that way we know what is going on with it and can maintain it better.
