I'll go ahead and say this to get it out of the way.  I've never worked on a project that used a purely agile methodology.  I've worked for clients that chose bits and pieces of things usually associated with agile such as continuous builds and the writing of unit tests, but I've never been submerged into a purely agile experience.  So, my comments are coming not from experience with agile methodologies, but rather experience without them.

I've been curious for the past few years about the benefits that an agile approach brings.  I've read numerous books on things like RUP and SCRUM.  As I've gathered knowledge about the subject, I've had the chance to balance the experiences I've had in the projects I've been involved with against the philosophies and practices I was reading and thinking about.  I've boiled all these meandering thoughts down to a list of perennial problems I see in projects and how I think an agile approach could lesson or eliminate them.  Of all the various flavors of agile methods that exist, SCRUM seems to be the one I identify with the most, so I'll be speaking in its terms, below.  If you aren't familiar with SCRUM, you might want to read more about it, here.

• Scope Creep / Late Breaking Requirements - With a SCRUM project life-cycle, the software design is refined before each sprint.  Further, during the course of the sprint, the goal is to write the software to meet the CURRENT requirements only.  Let's face it.  Any developer who has any experience, at all, can tell you that there will always be more features requested after the project has started and that users will always change there minds about things.  If we know this will always be the case, why do we design a whole system up front and pretend it's never going to change?  In fact, we try to insure that it doesn't change by slapping a change request and approval process on the users who change their minds.  To me, the ultimate goal is to put the most useful software possible in the user's hands.  Punishing users for suggesting improvements to the software doesn't seem conducive to that.  With a methodology like SCRUM, these changes are part of the process and thus welcomed. 
•   End Product Not Meeting the User's Needs - I think a majority of the problems that occur in software projects boils down to a lack of communication.  Communication may break down because no attempt is made to convey things like project status and the way the application will work - or it may just be that the business side of the house and the IT department speak is entirely different terms.  If the project is to be a success, the users and the developers have to be on the same page.  The only way that can happen is for the two groups to talk...often and in the same terms.  There are users who never know exactly what they want until they don't get it.  In SCRUM, after each sprint is finished, the solution is presented to the users for approval.  Users can see and maybe touch and use the software in its current state.  This seems to me to be the best way to squeeze those questions and concerns out of a user that they never seem to be able to think of when they're requesting the software. 
• Developer Thrashing - In SCRUM, there is a daily meeting to determine where each developer is with there tasks and what can be done to expedite anything holding them back.
• Pushback From the Business on Length/Cost of Projects - Before each sprint, a decision is made as to which tasks will be completed during that span of time and which developer will be responsible for each.  This decision is a COOPERATIVE effort between IT and the business.  Each task has an estimated amount of time required for completion and a priority assigned by the business.  Accuracy in estimating the effort required for a task and how much effort can be expended by the development team during a single sprint can be tuned over time and this type of metric is very easy to gather from the process.  Since the the business is involved in the scheduling of tasks and would have access to the metrics, a better understanding of what takes time and why can be had.

Though my experience with agile methodologies is light, I can tell you that the apparent benefits of applying them has motivated me to push for there use in my current project.  I'll check back in with the results.

In my last post, I referred to the application I have been working on for some time.  It's a windows application, straight up, and does not use any of the click once features (a decision that we waited too late to address properly).  We found ourselves, therefore, needing a way to update the application in the wild without a manual un-install/install each time.  Additionally, we didn't want the users to have to do much to receive new bits from us.

I'll save the details of what we implemented for another post, but I wanted to touch on one part of the process.  It's pretty commonly known that if an assembly is loaded into a running process, the physical file is locked.  Therefore, it was impossible for us to update the assemblies on our client's machines without shutting down the application, first.  in my implementation, I created an instance of the Process class and used it to start up our application updater.  Then, I asked the main application to end, so the updater could refresh the assemblies it had locked.  Something like this...

Unfortunately, about every third time this code ran, on average, the application froze instead of exiting...keeping the assemblies locked and rendering the updater useless.  So, what to do.  First, I tried the sledgehammer approach of having the main application's thread sleep for a while before exiting.  This improved things a bit.  I saw one freeze out of every 4 or 5 attempts.  I reasoned that the application's main thread (only thread) must be in the middle of doing something when Application.Exit is being called and isn't handling the request well.  I found a nice comparison of Application.Exit, Environment.Exit and End here.  After reading it, I realized that the message pump may still have work on its queue when exit is being called.  I modified the above code to look like the following.

I've known about it and handled it well for years.  You know...when you have a string with a single quote embedded in it and you need to insert the string into a database column.  For the longest time, I simply replaced any quotes with two quotes and all was well.  ADO.Net was smarter than I gave it credit for, however, and it apparently hung me up.

 I've been working on a brand new client-server application for the past several months.  I created the dal that was to be used by the entire application and it had been working well.  We just started allowing some user acceptance testing and it happened.  A user keyed in a string with an apostrophe in it and the application thre an exception.  "No problem", I thought, "I'll just replace any quotes with two quotes and I'm on my way".

One of the developers on this project approached me,  shortly after,  and pointed out that quotes I was doubling in the dal were, in fact, being saved in the database as double quotes.  Huh?  After two hours of debugging and tweaking I figured out the problem.  I found a post on Scott Gutherie's blog that pointed out that the SqlParameter class automatically takes care of escaping single quotes.   So why was it seemingly ignoring my quotes?

Turns out that the problem laid with the creation of the actual parameters.  I had created an interface and my Dal class implemented it.  Besides the other benefits to ding this, I wanted to be able to write specific implementations for different databases and be able to switch them out, if needed, without changing any of the application code.  So, necessarily, all the application code was written against the interface and not the specific dal class.  A side effect of this was that the code that called into the dal could not create specific parameter clases such as SqlParameter, but rather it asked the dal to create a parameter specific to the database the class was written for, and the parameter was stored in a variable of type  IDataParameter.

Long story short, the dal contained a method called CreateParameter that looked like this

Note that this method does not specify a DBType for the parameter.  Apparently, the lack of a type confused the SqlParameter class.  I modified the dal to check each parameter being passed in to see if it was a string type.  If it was, I manually set it to a DBType of Varchar.  This worked, in my case, because our standard was to use varchars for all string data types unless a char made more sense.  At any rate, this modification allowed me to remove the code that manually escaped the single quote.  The SqlParameter class now had all it needed to handle the situation on its own.

Do you thrash?  Thrashing is when you find yourself in a situation where you can't seem to make any progress on a problem no matter how much effort you're exerting.  Thrashing can frustrate and kill both productivity and timelines.  Maybe you're trying to track down an elusive bug, working in an unfamiliar language or technology, or you're doing something unique and uncharted.  The common thread in all these scenarios is a lack of information.  Where do I look next? How can I create a particular behavior with the tools I have at hand?  What tool should I be using instead?

Assuming that your thrashing is based on a lack of information, the warning signs should be fairly obvious.  Do you have a pretty good idea how you're going to accomplish your task?  If you don't, you may be on your way to a good thrashing.  Thrashing can usually be prevented with preparation. 

First, know your tools.  Be honest.  How familiar are you with the language you're using?  Do you often read code written in that language?  If not, you need to.  If you do, do you find yourself wondering what chunks of the code are doing?  As my high school English teacher said, "If you come across a word you don't understand, look it up."  Doing this will keep thrashing due to ignorance of the language at bay.

Second, know you're requirements and have a design in mind.  I can't tell you how many times code I've worked on has been held up because either the requirements were unclear or certain points in them are disputed among the users.  If you don't know exactly how the application is to behave, it's your job as the developer to clarify these things.

 If you should find yourself in a situation where you're thrashing, the best way to break out is to remember that someone knows the answer to the questions you have.  Find them and ask.  In my book, the only excuse for thrashing is the rare situation where there is no expert or they are unavailable.