Thoughts on Web Development
Most consulting engagements usually end with a hand-off of the project’s deliverables to the client’s resources during the last few days of the consultant being in contact with the client. This is often referred to as the “knowledge transfer” and can involve walking the client through the finished code artifacts and any documentation around it.
Most consultants dread this part of the process as it often requires mounds of documentation and tons of meetings with seemingly little accomplished. Even after the process is completed, many consultants will still get a follow up call from the client six months later when the developer who was supposed to take over their project has left for greener pastures.
There are many reasons why consultant-developed software often follows this pattern. Firstly, most clients are plagued with the inability to identify a suitable maintenance resource in a timely manner. Often this important task is put off until the last minute thus reducing the quality of resources that can be found to take over the project. Also if the client’s resource is tasked with learning the code base in a very short time, they often don’t get enough information and are overwhelmed when they are expected to deliver a round of enhancements soon after the consultant leaves.
To increase the chances of a successful hand off, the client resource should be identified soon after the project enters its testing phase to ensure that they have sufficient time to get up to speed. Also it can help to let the hand-off resource take a crack at some of the lower priority bugs that inevitably creep up so that they get familiar with the code. Having them get their hands dirty when the consultant is still around to support them can be extremely valuable to the client.
Consultants should also make every effort to develop a maintainable solution that can easily be transitioned. A complex custom application framework, a cutting edge technology, or an unfamiliar platform can all reduce the client’s chances of successfully maintaining their shiny new application. While it can be appealing to try a new technology or build a new skill set, such decisions often create unnecessary risks for the client and their resources.
So does this mean that consultants should simplify their architectures to Typed DataSets and drag-and-drop GridViews? Not necessarily.
Even with the most non-technical clients, a consultant should take the time to explain the important architectural decisions in ways where the risks and rewards are absolutely clear to the client. If a technical decision is made that reduces development time but requires a specialized resource, then the risks and reward of such a decision should be clearly communicated to the client before it’s too late to turn back. Projects often fail because of technical decisions that were made up front later on became extremely costly to support and were ultimately irreversible without re-writing large parts of the application.
Finally, consultants should beware of clients that expect to just pay an invoice and get some working software with very little personal involvement in the project. No matter how much they may profess that they “just want something that works” they will have always opinions on how it should work. So a consultant is better off setting their expectations of the client’s involvement as early as possible. This will ensure both a healthy development cycle for the project and help transition it to a capable maintenance resource that can support any future needs.
I recently had a chance to attend Headspring System’s Agile/Extreme Programming boot camp for Advanced .NET developers led by Jeffrey Palermo in Austin, TX. I had wanted to learn the proper techniques to approach agile development on the .NET platform from an expert and when I found out about this course, I eagerly signed up.
The three day course covered best practices in regards to Agile design and process while incorporating multiple deep dives into Jeffrey’s tools of choice when doing development. The exercises followed a format of first explaining how a normal development process becomes more agile and then having the hands on experience of implementing that process with different tools and concepts. Jeffrey explained how simple things like source control can become more agile through regular branching and merging and he demonstrated how to do this with TortoiseSVN.
While a lot of software development training is often presented very academically, Headspring’s was very hands-on and really pushed everyone to pick up the processes and tools very quickly, just as you would in the real world.
On day one, upon entering the classroom we were told to check out a Subversion repository hosted on Google Code that would house the code for the application that we would be extending over the next few days. This application was a Work Order management system designed using Domain-Driven Design and built using a Model-View-Presenter implementation with NHibernate serving as the ORM between our entities and the database. The application also had a suite of both automated Unit Tests and Integration Tests which were regularly run as part of it’s NAnt-based automated build script. If you’re curious to see the system, download the Visual Studio 2008 solution here.
Over the next two days, we extended and refactored this Work Order system to support new features and workflows by first writing NUnit tests and then designing interfaces around the problem domain. By focusing our whiteboarding sessions on separating the concerns into smaller pieces that each group could begin implementing, the whole class of fifteen students was able to work as a team to successfully build and test the new features in a just a few hours. Along the way we touched on many concepts like Inversion of Control by using StructureMap and reliable, targeted Refactoring by using Resharper.
Finally, we ended the class with a review of all of the concepts and tools that were used during the exercises and we identified some of the design patterns that were implemented by the final solution.
I really appreciated that Jeffrey tailored the exercises as per the class’s feedback. Many of the attendees wanted to see more detail on NHibernate so Jeffrey dedicated a lot of time to going over some best practices around NHibernate mappings and he demonstrated ways to optimize the queries produced by it.
There was a obviously a lot more to this course than I could possibly cover in a single blog post. If all of this content sounds interesting to you, I would highly suggest signing up for one of Headspring’s upcoming sessions if you are looking for some practical guidance to help you hit the ground running with Agile development.
One final note: If you are considering taking this course, I would recommend familiarizing yourself somewhat with the following tools beforehand: TortoiseSVN, NUnit, and Resharper. Also, I would recommend having at least a basic understanding of Test Driven Development, Model-View-Presenter, and Inversion of Control. The course moves very quickly and you will have an easier time keeping up if you at least have some working knowledge of these tools and concepts prior to attending the course.
Thanks again to both Jeffrey Palermo and Jimmy Bogard for a great training experience and chance to inundate them with questions as I am known to do!
The Web Gambit 