How to make your code last: call it a temporary solution

Throughout my career, I have found several common themes that appear over and over again.  One of them popped up again recently: If you say you are going to develop a temporary solution and clean it up later, you never will.  It’s not always a matter of laziness (although, at times, it is), the odds are very high that an obstacle will get in our way later.

I was writing a demo Web Part project last week in order to demonstrate how SharePoint projects can use Continuous Integration.  The project itself was not the focus of the talk, I just wanted to demonstrate how CI works. 

Although the content of the solution was not significant to my original theme, it caught my audience’s attention.  Once we got through the discussion of CI, they were very interested in the approach I took and how I was deploying the Web Parts.  It turns out that they were having problems building and deploying Web Parts themselves.

Fortunately, I learned my lesson long ago that all code I demo or commit to source control should be thought out.  I could have cut a lot of corners when building this project, but I didn’t.  I’m not saying that I write perfect, bug-free software, I just attempt to do a good job as a professional. To quote the Manifesto for Software Craftsmanship I’ve come to value “Not only working software, but also well-crafted software.”

When the presentation was over, the client wanted my code and build scripts.  They are still interested in CI, but my sample code and build scripts solved the exact problems they were having at that time.  Now this is a lucky situation where my little demo app solved a problem for a client that I didn’t know they had.  But think if I had taken short cuts or allowed myself to get sloppy.  I would have had to spend the next day or week rewriting the project before I handed it over to them.  Or I would have lost credibility with them because my code could have been short cutting around their problem.

In the end, my code and/or its build script may be the building blocks for the client’s own Web Parts and projects.  So this seemingly inconsequential application may become the foundation for future code.  They may not use the code itself in the future, but there is power there because it helps form the clients initial understanding of Web Part development.  How about that?  If I had done a sloppy job, that means their initial understanding would be … well… sloppy, or even worse, incorrect.