Moving on...

So I think this may be a move to the big leagues so I supposed I'm going to have to provide some real content. Fortunately, my new employer is doing lots of really cool things so I expect I'll measure up to the task.. eventually.

So my new blog is at http://weblogs.asp.net/jimjackson/. That's right! I'm a Microsoft Sponsored Blogger. Not really but it sounds cool right? Me, moveon.org and Rush Limbaugh are going to really have an impact on this election! Wait, that's not right. I'm going to post the tips and tricks that I learn while spinning up on Sharepoing 2007 and Visual Studio 2008. That's pretty much it.

JJ

Anyone can break a shovel...

I was about 12 and my grandparents' turn of the century farm house had shifted on its wooden beam foundation. The whole family was involved in the process of digging up the ends of the beams, jacking them up and laying concrete beneath them to relevel the house. Over lunch, while everyone else went inside, I stayed and continued to dig. The ground in Northern Michigan can be very rocky and at one point I struck a large stone. After about 20 minutes of excavating the stone, I thought it was ready so I wedged the shovel in on one side and attempted to pop it out. Turns out, I had only excavated the top 30% of the stone. With all my weight on the shovel, the handle promptly splintered.


I waltzed into the house proudly displaying the broken shovel as proof of how hard I was working. My grandpa looked at the shovel, scowled and yelled "Hell boy, ANYONE can break a shovel!" I was crestfallen. The proof of my hard work turned out to be nothing more than a measure of how little I knew about using my tools.


Jump forward 25 years and I find the lesson still applies. I am always impressed at how easily some developers and managers in the software provisioning industry are always trying to:

1. Use a piece of technology to solve a problem in direct conflict with that technology's expressed purpose.


2. Decide not to use a technology that is specifically designed to solve a problem because it was 'not invented here' or because it would mean learning something new.

As software developers, it is our job to enhance the state of the art in what we build. We must know enough about the problem and our tools to know what is possible, what isn't and where the lines become fuzzy. For example, a developer who will not use generic collections but insists on manually boxing and unboxing collection contents has not learned the capability of his tool set. Similarly, a developer who insists that databases are 'too much overhead' and decides to wrap a complete custom transactional solution around XML files has gone around the bend only to find an unfortunate and painful hole in his own foot. (The second example is anecdotal!)

We must, as an industry, overcome the stigma of budget and schedule overruns resulting in unusable software. To do that, we must first consider what kind of tool will best suit the job at hand and then strive to use that tool appropriately. If your software is needlessly complex and unmaintainable, it may be that you've done nothing more than break your shovel.

Web 2.0 Refreshments

Just read a blog by Sahil Malik. Smart dude and I think he gets it. Check it out: http://blah.winsmarts.com/2007-1-2007_Prediction.aspx

Team Foundation Server Links

Over my holiday, I read a book on Team Foundation Server and, true to the current low standards for industrial technology publication, the authors knew their business but not how to present it. I found the book sorely in need of an editor who spoke english as a first language. The material was trivial more than half the time and casual the rest of the time. I felt as though I were reading a TechEd transcript. Not exactly a fluent method for getting your point across in print...

At any rate, the authors did do a good job of researching related information freely available on the web. Unfortunately, it was printed and there was no ebook published with the print edition. The result is that I bookmarked all the links that I thought would be helpful and then located their actual URL (many published values are post-MSDN2). Here are the pieces I found useful.

Continuous Integration
- Continuous Integration for TFS
- MSDN Article on Using Team Foundation Build

MS Build
- GUI for MSBuild Sample
- MS Build Sidekick
- Team Build Ticker
- Visual Studio 2005 Extensibility Center
- MSBuild Community
- MS Services Build Framework (SBF) Tasks

ASP.Net Applications in Team Build
- Team System Team Build TechNotes for ASP.Net Deployment Projects
- Building a default ASP.Net project in Team Build
- VS 2005 Web Deployment Projects Information

MSF Process Integration and Customization
- The Origin of Personas
- Why there are 5 missing CMMI process areas
- Starting Point for Customizing MSF Process Guidance

MS Threat Analysis and Modeling Tool
- MS Application Thread Modeling Blog

MSF Document for SCAMPI Requirements Roadmap (CMMI)
- MSF CMMI Reference.xls

MS Visual Studio Developer Center
- MS Visual Studio Developer Center (requires free membership)

Work Item - Process Template Editor
- VSTS Customization Toolkit
- Team Plain for Team System (TFS Web Access)

TFS Version Control
- Branch Merging Primer

Team System Requirements Authoring Starter Kit
- RASK Starter
- RASK Code Definition
- RASK Download