I started reading Apprenticeship Patterns today after Dave Hoover suggested it to me during a Twitter conversation while he was attending ObtivaCon. It’s a great read so far, I wish someone had handed it to me 10 years ago. Here are some choice quotes thanks to my handy Kindle.

Apprenticeship makes a difference because it instills a lifelong passion to master the craft. It instills a passion for perpetual learning and, in the process, enables the apprentice to become a great developer. --Pete McBreen, Software Craftsmanship

“effort is what makes you smart or talented”

“I guess it basically means having the attitude that there’s always a better/smarter/faster way to do what you just did and what you’re currently doing. Apprenticeship is the state/process of evolving and looking for better ways and finding people, companies and situations that force you to learn those better/smarter/faster ways.”

It is not something we give to people by telling them about their high intelligence. It is something we equip them to get for themselves—by teaching them to value learning over the appearance of smartness, to relish challenge and to use errors as routes to mastery”

I have been working on a project with my wife the last few weeks. Since this is a totally personal project I am free to use whatever tools I want to use without having to justify my decisions to a team.

So I have been going nuts with the tooling. I set up a SVN repository on my Windows Home Server. I set up TeamCity and two separate CI builds using UppercuT that run NUnit tests, NCover code coverage analysis and NDepend reports. I am writing my app using ASP.NET MVC and the S#arp Architecture frameworks. Heck, I’ve even setup Selenium tests that get run every night. And I have NHibernate Profiler wired in there too JUST BECAUSE I CAN. It’s a lot of infrastructure set up for one page so far. 8)

So when I couldn’t get my single Selenium web test to pass in the TeamCity nightly build, I was a bit obsessed with figuring out why. Turns out, I had made a modification to a test base class that was causing the problem. I didn’t discover this issue when I created it because I typically don’t run Selenium tests prior to check in. I prefer to let the nightly build do that. So it took me a couple days to figure it out. Which prompted this post to Twitter which made its way to Facebook:

Yo Dawg, I heard your build failed because you refactored your unit tests. So, I wrote some unit tests for your unit tests, so you can...

To which my buddy Drew Welliver, an awesome developer over at L&I, commented:

Code so nice... I refactored it twice, then thrice, then.... At some point ya gotta wonder, wouldn't it have been easier to just run the application yerself and find the friggin' bugs?...

And followed up with:

And code coverage is cool, but scripts running code running scripts running code running scripts running... The users are still gonna break it, SOMEHOW....  And all that testing becomes academic.  The reality SEEMS to be that when I've worked on systems that used testing frameworks, their bug lists never seemed to be any shorter than the ones that didn't.

The Fallacy of Unit Testing Proving Quality

I don't think any TDD-er will say they don't produce bugs because they have tests. I would hope that it makes you think about your code a bit more and help you to discover more bugs prior to them getting out, but you never know if you are testing the right assumptions.

I do know that, if I have a bug and I write a test that demonstrates that bug, I know I have fixed it when that test passes and that that test gets run every time a check in is made to  source control, ensuring that bug never returns.

The value of unit tests is not only the immediate feed back that the code you are working on does what you think it does but also sustained confidence that that code still does what you think it does though out the life of the development effort and beyond.

Spending ten minutes writing a test that gets run thousands of times though out the life of the project and into the maintenance phase of the product lifecycle is value.

Additional Benefits

A tight feed back cycle between change=>flaw=>fix does yield better code. The wider your gap in feedback cycle the longer it will take you to fix the problem because you have to reestablish all that context.

If you have to monkey test over the course of days, how do you know what change might have caused the problem? (no offense to monkeys of course)

The bottom line comes down to this question:

 "Have you ever hesitated to make a change in a large system because you had no idea what effects it might have elsewhere in that system?"

A logical ,well thought out test suit gives you the confidence to make that change. If your tests start failing you simply back the change out right then and there and try something else while you have all the context for what you are working on.

The alternative of waiting days to weeks for unmotivated half qualified monkey testers to find that bug and then wondering which of the 40 change sets checked in during that time might have caused the issue is not one for me.

And Drew, I take you up on that beer offer brother. I am always down for testing out some beer.

UPDATE: And you want hard numbers? Here are some hard number for you.

UPDATE: Looks like I may have jumped the gun with this review. The actual print version is due to be released in September 2009. So the content may change a bit.

I am a huge fan of Manning’s Early Access Program. I get to read books on new technology as they are written. It is almost like the authors and I are learning about the topic together. Every few weeks an update arrives in my inbox and I upload it to my Kindle via Amazon’s conversion service.

A few weeks ago, the final shipping edition completed chapter of ASP.NET MVC in Action hit my inbox and after getting it on my Kindle I forgot about it for a few weeks. I have a personal project that my wife and I have been talking about for a while now that I want to write using MVC. So, as a way to get myself in the right mindset I sat down and read the book cover to cover recently.

The book is broken up into four major sections. Chapters 1-5 give you an in depth overview of the core concepts of the MVC architecture. Model, View, Controller and Routing all get dedicated chapters that give you a firm understanding of their purpose and usage.

The second section of the book covers the various extension points of the framework as well as application architectural concerns. View Helpers, Partials, Components and Action Filters are all touched on.

The third portion of the book is a kind of  of hodgepodge of topics. MonoRail and Ruby on Rails get a chapter that gives some historical context on the topic. Hosting and Deployment are covered to help you figure out how to get MVC running under IIS6 or IIS7. “Classic” ASP.NET tooling is covered to give you an idea of existing tools and techniques that applicable in the new framework.

The final section of the book wraps everything up nicely with some guidance with Best Practices and a set of Recipes to get you started.

I can recommend this book as a great place to start on your journey into ASP.NET MVC with a couple caveats.

This book is not for beginners. It assumes you have a significant amount of ASP.NET development under your belt. And by “ASP.NET Development” I do not mean dragging and dropping controls on Web Forms. If you have implemented IHttpHandler or pages that do not require View State this book should be right up your alley. On the other hand if GridView is your best friend because it handles everything for you… maybe this book is not so much for you.

This book is highly opinionated. The authors are prominent figures in the ALT.NET community. There is a certain amount of agenda pushed in this book. Concepts like DI/IoC, Unit Testing and ORM are not only mentioned but are actively demonstrated as best practices. When available open source projects are used in examples and Microsoft tooling are more or less shunned. NHibernate, StructureMap, NUnit, MVCContrib and the current state of the art in ALT.NET toolbox all make appearances. Jeffrey Palermo’s Code Camp Server serves as the sample application through most of the book.

This is not so much of a problem for me as this is Kool-Aid that I have openly drank and serve to others around me. I use these tools, I understand their value and enjoy seeing them being used in examples in a book. Others who prefer to be fed the Microsoft story line by line wanting to only stick to the nuts and bolts of the technology might find this distracting.

In the end Jeffrey Palermo, Ben Scheirman and Jimmy Bogard not only did an excellent job of putting together a great practical guide to ASP.NET MVC they also successfully embedded some subversive ALT.NET concepts that will hopeful make us all better developers. And at the end of the day that is a damn fine accomplishment.

This one is for all my contractor buddies out there.

Stolen from {CodeSqueeze}.

Saw this on Boing Boing today and can't agree more. I declare this my official stance on everything from today forward.

The Cult of Done Manifesto

1. There are three states of being. Not knowing, action and completion.
2. Accept that everything is a draft. It helps to get it done.
3. There is no editing stage.
4. Pretending you know what you're doing is almost the same as knowing what you are doing, so just accept that you know what you're doing even if you don't and do it.
5. Banish procrastination. If you wait more than a week to get an idea done, abandon it.
6. The point of being done is not to finish but to get other things done.
7. Once you're done you can throw it away.
8. Laugh at perfection. It's boring and keeps you from being done.
9. People without dirty hands are wrong. Doing something makes you right.
10. Failure counts as done. So do mistakes.
11. Destruction is a variant of done.
12. If you have an idea and publish it on the Internet, that counts as a ghost of done.
13. Done is the engine of more.

Blatantly stolen from this source. Bre Pettis & Kio Stark are obviously geniuses.

I sometimes suffer from deer in the head lights syndrome. Before doing anything, I psych myself out thinking  "all the things that need to get done", all the things "I don't know" and "how will I make it perfect" thoughts. I read constantly about a topic but I never do...

The only way I can get myself out of that mode is to simply throw myself at the task/idea and start doing. Fail over and over, learning from each experience until one day I can look back and say, "Hey I actually do that pretty well now."

My hard drives at work, home and in my laptop are littered with useless half projects where I was attempting to get an idea or approach thought though. Travel down one path, fail, done. Travel down another path, fail, done.

Failing is how we learn. You never fail if you don't start. Stop reading this. Get excited and make things. Done, done done.

So I have been living with my Mac Book Pro for a couple months now. I have purposely tried to use OSX for day to day things to force myself to get used to the OS. Here is a nice list of the applications that I have found useful so far.

This list is in no way targeted at long time Mac fans. Instead it is intended for newb/converts like me who are getting used to a whole new environment of software.

Quick Silver – Awesome tool for launching applications or finding documents. Simply hit Ctrl+Space and start typing what it is you want.. QuickSilver will display a list of items that match what you are typing. Once you have typed a set of letters and selected something QuickSilver will learn what you wanted and begin suggesting that thing faster… for example I can type Ctrl-Space, VM, Enter and launch VM Ware…. It’s a cool app.

Adium – Multi-Service messaging client very similar to Pigden. Can connect to MSN, ICQ, AOL, Facebook, GTalk, MySpace and many others.

Colloquy – Pretty straight forward IRC client if you are into that sort of thing.

Remote Desktop Mac – This combined with with VPN connection to work is awesome. There is pretty much nothing I can't do now with my Mac and a network connection.

Twitterrific – Simple twitter client if you are into that sort of thing.

MonoDevelop – Mono is the open source implementation of the .NET framework. MonoDevelop a IDE for developing using Mono. If you ever wondered what it would be like without Visual Studio here you go.

Skype – Skype…

VMWare Fusion – Virtual Machine goodness…

XCode – The free IDE for developing on the Mac. Want to make a IPhone app? Here you go. Objective C is fun… really it is…

Bonus Tips: Be sure to enable Spaces via the Expose & Spaces menu. This lets you have the sliding desktop effect that I use all the time. A neat keyboard combo is Function+F8, this displays all your spaces on the screen and you can click one to go to that space. Expose is Function+F8 this will shrink all the windows on your screen and lay them out so that you can see them all. Then click the window you want and they all go back where they were with the one you selected in focus.

Bonus Bonus Tip: The World of Warcraft Mac client runs like a champ on my MBP. ;)
 

I have been getting hounded by our webmaster to supply a bio for our company bio page. Here is my first stab at it:

Bobby Johnson is a Senior Development Specialist and joined Alliance Enterprises in September 2008. Bobby is an Agile fanatic, Domain Driven Design enthusiast and Unit Testing maven who is not afraid to run with scissors. Bobby attended Southwest Missouri State University prior to bailing out to seek fame and fortune. He previously could not be contained by the Washington State Department of Labor & Industries or the Red Wind Casino.

I'll update when when the actual bio goes up.

UPDATE: Here is what actually hit the page:

Bobby Johnson is a Senior Development Specialist.  He joined Alliance Enterprises in September 2008. Bobby is involved with the implementation of the agile approach to development and also developing Unit Testing for the AWARE system.  Prior to joining Alliance, Bobby worked at the Washington State Department of Labor & Industries as a  Development Specialist.

Michael Feathers, the amazing author of Working Effectively with Legacy Code, posted recently about technical debt.

What happens to code when you don’t refactor?  Anyone with any experience knows the answer.  It gets messy.  It becomes hard to change and the rate at which you can add features slows to a crawl.

I was on a project that inherited a tremendous amount of technical debt. The motivating force for the original team was meeting a hard deadline. As the deadline approached development process crumbled. Hero developers shot from the hip. Corners were cut. Non-critical bugs piled up. Quality was sacrificed to meet the deadline.

The technical debt was put on the American Express.

At the end of the project, the resulting application had a week long eventful launch full of rapid critical bug fix releases. The application was eventually brought up to an acceptable level of performance through Herculean effort of very skilled and talented people.

The technical debt bill was left ignored.

The following project cycle a new team was introduced to the application. A feature set to be added was defined. A deadline was set. A new requirement was added. All new features would have a emphasis on quality. No defects would be added to the already limping system.

The technical debt went into Universal Default and the APR was bumped up to 29%.

The team began moving forward except this time the business actively using the system kept running into critical issues that the team had to quickly deal with. The short cuts taken by the previous team became direct roadblocks to the new features slowing the implementation down. Each new line of code had to make sacrifices to work around quirks in the code base.

The 800 pound technical debt collection gorilla started calling demanding payment.

After a year of use the sheer size of the technical debt in the database caused leaks to spring which cascaded outward through out the application. New releases were viewed with dread by the entire organization. The DBA's were not happy. The help desk was not happy. The users were not happy. Morale on the project was through the floor.

The 800 pound technical debt collection gorilla had frozen all assets and put a lean on the house.

You can put that debt on the card. You can ignore it and buy some time. But eventually that gorilla is going to find you, climb on your back and beat you down.

Photo Credit:  Ruben Bos