I have been using Rhino.Mocks pretty much since I started being a mockist-type tester. I have been very happy with it for the most part, but a year or so ago, I got a glimpse of some tests using Moq. I thought the little bit I saw was very compelling. For a long time, I had been using:

   1: var _repository = MockRepository.GenerateMock<IRepository>();

   2: _repository.Expect(repo=>repo.SomeCall()).Return(SomeValue);

   3: var _controller = new SomeKindaController(_repository);

   4:  

   5: ... some exercising code

   6: _repository.AssertWasCalled(repo => repo.SomeCall());

I was happy with that syntax. I didn’t go looking for something else, but what I saw was:

   1: var _repository = new Mock();

And I thought, “That looks really nice!” The code was very expressive and easier to read that the Rhino.Mocks syntax. I have gotten so used to the Rhino.Mocks syntax that it made complete sense to me, but to developers I was mentoring in mocking, it was sometimes to obtuse.

SO I thought I would write some tests using Moq as my mocking tool. But I discovered something ugly once I got into it. The way Mocks are created makes Moq very easy to read, but that only gives you a Mock not the object itself, which is what you’ll need to pass to the exercising code. So this is what it ends up looking like:

   1: var _repository = new Mock<IRepository>();

   2: _repository.SetUp(repo=>repo.SomeCall).Returns(SomeValue);

   3: var _controller = new SomeKindaController(_repository.Object);

   4: .. some exercizing code

   5: _repository.Verify(repo => repo.SomeCall());

Two things jump out at me: 1) when I set up my mocked calls, do I set it on the Mock or the Mock’s “object”? and 2) What am I verifying on SomeCall? Just that it was called? that it is available to call? Dealing with 2 objects, a “Mock” and an “Object” made me have to consider naming conventions. Should I always call the mock _repositoryMock and the object _repository? So I went back to Rhino.Mocks. It is the most widely used framework, and show other how to use it is easier because there is one natural object to use, the _repository.

Then I came across a blog post from Patrik Hägne, and that led me to a post about FakeItEasy. I went to the Google Code site and when I saw the syntax, I got very excited. Then I read the wiki page where Patrik stated why he wrote FakeItEasy, and it mirrored my own experience. So I began to play with it a bit. So far, I am sold. the syntax is VERY easy to read and the fluent interface is super discoverable. It basically looks like this:

   1: var _repository = A.Fake<IRepository>();

   2: a.CallTo(repo=>repo.SomeMethod()).Returns(SomeValue);

   3: var _controller = new SomeKindaController(_repository);

   4: ... some exercising code

   5: A.CallTo(() => _repository.SOmeMethod()).MustHaveHappened();

Very nice. But is it mature? It’s only been around a couple of years, so will I be giving up some thing that I use a lot because it hasn’t been implemented yet? I doesn’t seem so. As I read more examples and posts from Patrik, he has some pretty complex scenarios. He even has support for VB.NET!

So if you are looking for a mocking framework that looks and feels very natural, try out FakeItEasy!

I am making it a point not to call them resolutions, because the word has become an institution and is beginning to have no meaning. That's why I end up not keeping my resolutions, I think.
So in the spirit of holding myself to my own commitments, I will make a plan and some realistic goals.

1.) Lose weight. Everyone has this on their list, but I am going to be conservative and specific. I currently weigh 393lbs. (yeah, I know). So I want to plan to lose 10lbs per month, that's 1lb. every three days, that shouldn't be difficult if I stick to my diet and exercise plan.
- How do I do this?
    - Diet: vegetarian. Since I already know I have high blood pressure and borderline high cholesterol, a meat-free diet is in order. I was vegan for a little over 2 years in 2006-2008, I think I can handle vegetarian.
    - Exercise: at least 3 times (preferably every day) a week for 30 minutes. It has to be something that gets my heart rate up, or burns in my muscles. I can walk for cardio to start and mild calisthenics (girly push-ups, crunches, etc.).
        - Move: I spend all my time behind the computer. I have recently started to use a slight variation of the Pomodoro Technique (my Pomodoros are 50 minutes instead of 25). During my 10 minutes every hour to answer emails, chats, etc., I will take a few minutes to stretch.
2.) Get my wife pregnant. We've been talking about it for years. Now that she is done with graduate school and I have a great job, now's the time. We'll be the oldest parents in the PTA most likely, but I don't care.
3.) Blog More. Another favorite among bloggers, but I do have about six drafts for blog posts started. The topics are there all I need to do is flesh out the post. This can be the first hour of any computer time I have after work. As soon as I am done exercising, shower and post.
4.) Speak less. Most people want to speak more. I want to concentrate on the places that I enjoy and that can really use the speakers (like local code camps), rather than trying to be some national speaker. I love speaking at conferences, but I need to spend some more time at home if we're going to get pregnant.
5.) Read more. I got a Kindle for Christmas and I am loving it so far. I have almost finished Treasure Island, and am getting ready to pick my next book. I will probably read a lot of classics for 2 reasons: (1) they teach deep lessons and (2) most are free for the Kindle.
6.) Find my religion. I was raised Southern Baptist, but I want to find my own way. I've been wanting to go to the local Unitarian Church, so I will make a point to go before the end of March. I also want to add a few religious books to my reading list. My boss bought me a copy of Lee Strobel's The Case for Christ: A Journalist's Personal Investigation of the Evidence for Jesus , and I have a copy of Bruce Feiler's Abraham: A Journey to the Heart of Three Faiths (P.S.) . I will start there.

Seems like a lot now that I spell it out like this. But these are only starters. I am forty years old. I cannot keep living like I am twenty anymore.

So here we go, 2011.

I was having a hell of a time tonight with my IIS on my development laptop. I don’t remember doing anything to change the IIS settings. I don’t use IIS that much on my dev machine. Usually Cassini is enough for testing my development efforts but tonight I needed to replicate a problem that seems to stem from x86 v x64 mismatch, so I went to create an IIS site pointed to my dev folder.

When I did, I got a “503.1 Service Unavailable Error”.

First thing I did is go over all my setting to make sure I didn’t screw something up when I set up the site. It was pointing to the right place, and the app pool settings seemed to be alright. However, when I got the 503.1 error and went back to my app pool list, I saw that the app pool I was using was stopped again. I must’ve started and ran it a dozen times to verify that I wasn’t seeing things. After having a colleague look at it and not finding an answer, I started poking around Google. I cam across a post from Phil Haack about the same error. His fix was not mine, however. When I ran his command on the CLI, I didn’t see the reserved routes for HTTP.SYS there.

Finally, I looked in the event viewer (where I should have looked as soon as I saw that my app pool was stopping) and saw an error in there. For the IIS-W3SVC-WP Source I saw:

The worker process for application pool 'DefaultAppPool' encountered an error 'Cannot read configuration file due to insufficient permissions

' trying to read configuration data from file '\\?\C:\Windows\Microsoft.NET\Framework64\v4.0.30319\CONFIG\machine.config', line number '0'. The data field contains the error code.

So I went to that path and saw a little lock on the file icon. I opened up the security tab for file properties and saw that I was missing the IIS_IUSRS group. On a machine that was working correctly, I verified that it indeed had the IIS_IUSRS group set to Read and Read & Execute allowed. So I set mine up the same and voila!

Hopefully this helps somebody else, too.

Jack Dawson

Jack Dawson is the homeless drifter in Titanic. At one point in the movie he says, “I figure life’s a gift, and I don’t intend on wasting it.” He is happy to wander wherever life takes him. He works himself from place to place, making just enough money to make it to his next adventure.

The “Jack Dawson” developer clings on to any new technology as the ‘next big thing’, and will find ways to shoe-horn it in to places where it is not a fit. He is very appealing to the other developers because they want to try the newest techniques and tools too, He will only stay until the new technology either bores him or becomes problematic. Jack will also be hard to find once the technology has been implemented, because he will be on to the next shiny thing.

However, having a Jack Dawson on your team can be beneficial. Jack can be a great ally when attempting to convince a stodgy, corporate entity to upgrade. Jack usually has an encyclopedic recall of all the new features of the technology upgrade and is more than happy to interject them in any conversation.

Tom Smykowski

Tom is the neurotic employee in Office Space, and is deathly afraid of being fired. He will do only what is necessary to keep the status quo. He believes as long as nothing changes, his job is safe. He will scoff at anything new and be the naysayer during any change initiative.

Tom can be useful in off-setting Jack Dawson. Jack will constantly be pushing for change and Tom will constantly be fighting it. When you see that Jack is getting kind of bored with a new technology and Tom has finally stopped wetting himself at the mere mention of it, then it is probably the sweet spot of beginning to implement that new technology (providing it is the right tool for the job).

Ray Consella

Ray is the guy who built the Field of Dreams. He took a risk. Sometimes he screwed it up, but he knew he didn’t want to end up regretting not attempting it. He constantly doubted himself, but he knew he had to keep going. Granted, he was doing what the voices in his head were telling him to do, but my point is he was driven to do something that most people considered crazy. Even when his friends, his wife and even he told himself he was crazy, somewhere inside himself, he knew it was the right thing to do.

These are the innovators. These are the Bill Gates and Steve Jobs of the world. The take risks, they fail, they learn and the get better. Obviously, this kind of person thrives in start-ups and smaller companies, but that is due to their natural aversion to bureaucracy. They want to see their ideas put into motion quickly, and withdrawn quickly if it doesn’t work. Short feedback cycles are essential to Ray. He wants to know if his idea is working or not. He wants to modify or reverse his idea if it is not working or makes things worse.

These are the agilistas. May I always be one.

I’ve been absent from blogging for awhile. Part of it is due to the ultimate inertia of my life. Most of it is due to my inability to post my thoughts without turning it into an ‘According to Hoyle’ blog post. I have an idea, and I try to flesh it into an interesting article. Something that you might see posted in a magazine or something. It never lives up to my standards and I end up dropping it. How did I get to this? I started this blog for the intended purpose of archiving my ideas and solutions so that I could find them again. Me. I realize that maybe some people read this blog, but I am NOT a celebrity or God’s gift to programming. So why am I worried about making my posts ‘worthy of public consumption’?

Well, no more. If you are a reader of this blog, I thank you. But my content may change dramatically over the coming months, so be prepared. Hopefully you will still find my thoughts, ideas and solutions worth reading.

Thanks again,

Lee

I am a firm believer in learning best practices. I enjoy reading and studying SOLID and how to spot violations in the wild. I whole-heartedly concur with Separation of Concerns, Behavior-Driven development, lean software development and a hundred other things that have really cool buzz-wordy names and make me sound really smart. All these things only serve to enhance one binding truth about software development: it a thinking exercise.

You can master every GoF pattern, and be the master of every OR/M. You can spend endless nights studying OOP/OOD principles and make flash cards for recognizing SOLID violations. But if you are merely relying on your ability to recall these things while coding, you will misuse, misrepresent and munge everything up. These are all merely connectors for that big tool between your ears.

So if you think you can write software by simply following the advice of books and principles, think again.

~Lee

For those of you following the MVC releases, you will see something new in your File->New for MVC3 RC: _ViewStart.cshtml (_ViewStart.vbhtml for you VBers). This is a common place to dry out view dependencies. The most common view dependency is the MasterView it will use. To that end, the default _ViewStart page you get from a File->New MVC3 project has just the:

   1: @{

   2:     Layout = "~/Views/Shared/_Layout.cshtml";

   3: }

This seems to be done by convention. The view must be named “_viewstart.cshtml” or it will not be used. It also does not apply to partial views (since they are not really a page).

Hope this helps,

Lee

I just wanted to put up here a list of upcoming speaking engagements. Mostly, for my own sanity, but just in case you were wanted to see me put my mouth where your money is:

August 20th & 21st – St. Louis Day of Dot Net – St. Louis, MO

• Getting Started With Behavior-Driven Development
• NHibernate & Friends

September 8th-10th – Heartland Developer’s Conference – Omaha, NE

• NHibernate & Friends

October 21st & 22nd – Tyson Developer’s Conference – Springdale, AR

• ASP.NET MVC: How We Got Here

If you are looking for a speaker for your user group or conference, please contact me.

Thanks, and look for a more regular post from me soon.

I have been programming computer in some professional capacity for almost 13 years. In that time, I have written code in several capacities. I have been a permanent employee of a company that hired me to write internal applications, I have been a permanent employee of companies that have paid me to write applications for their clients. I have been a contractor and I have also been a consultant. On the surface, those might seem like the same thing; but consulting and contracting are very different engagements.

What’s The Difference, Kenneth?

A lot of people, including contractors and consultants themselves, use these terms interchangeably. The problem is, people need to know the difference. Companies especially need to know in order to be able to hire the correct one. So here is the difference: Contractors can help an organization keep the lights on, but consultants can help you get more light for the same or less money.

Now on the outset, that may seem like you should always go with a consultant. That is not the case. Like anything else, there is a right tool for the job. Consultants are always going to cost more than contractors, and they should. Consultants bring more to the table. They bring ideas, expertise and a business acumen that contractors don’t. Contractors provide great helping hands when you need to power through something. Good contractors can even sometimes help you get it done faster or better. Consultants, on the other hand should always help you find a way to get it done better or faster. Consultants can still help you slog code, but their main purpose should be to help their clients improve their situation. Contractors are also (usually) hourly, temporary employees. If you need the same person in six months, they’re likely not going to be available because they are slogging code somewhere else.

What’s This Mean To Me?

If you’re a company looking for outside help, hopefully this will help you decide whether you need a contractor or a consultant. If you’re a programmer looking at a job as a consultant or a contractor, this might help you decide which one is for you. Consultants are rarely happy in contracting positions. Consultants have experience and ideas that they want to share, and the want to be part of the overall strategy of the project or projects. That doesn’t mean that contractors don’t have ideas or expertise, they are just more likely to be happy doing the heavy lifting work and letting someone else provide more high-level direction.

What do you think?

It’s our fault. Well, not completely, but we haven’t helped the situation any. All of what follows comes from my own experiences which, from talking to lots of other developers about it, seems to be pretty much par for the course.

Where We Started

When we first started estimating, we estimated pretty clearly. We would try to imagine something we’d done that was similar to the project being estimated and we’d toss it about in our heads a bit and see how much bigger or smaller we thought this new thing was, and add or subtract accordingly. We wouldn’t spend too much time on it, because we wanted to get to writing the software.

Eventually, we’d come across some huge problem that there was now way we could’ve known about ahead of time. Either we didn’t see this thing or, we didn’t realize that this particular version of a problem would be so… problematic. We usually call this “not knowing what we don’t know”. It’s unavoidable. We just can’t know. Until we wade in and start putting some code together, there are just some things we won’t know… and some things we don’t even know that we don’t know. Y’know?

So what happens? We go over budget. Project managers scream and dance the dance of the stressed-out project manager, and there is nothing we can do (or could’ve done) about it. We didn’t know. We thought about it for a bit and we didn’t see this herculean task sitting in the middle of our nice quiet project, and it has bitten us in the rear end. We now know how to handle this in the future, though. We will take some more time to pick around the requirements and discover all those things we don’t know. We’ll do some prototyping, we’ll read some blogs about similar projects, we’ll really grill the customer with questions during the requirements gathering phase. We’ll keeping asking “what else?” until the shove us down the stairs. We’ll take our time and uncover it all.

We Learned, But Good

The next time comes, and you know what happens? We do it. We grill the customer for weeks and prototype and read and research and we estimate everything down to the last button on the last form. Know what that gets us? It gets us three months of wasted time, and our estimate will still be off. Possibly off by a factor of four. WTF, mate? No way we could be surprised by something! We uncovered every particle. We turned every stone. How is it we still came across unknowns? Because we STILL didn’t know what we didn’t know. How could we? We didn’t know to ask.

The worst part is, we’ve now convinced the product that this is NOT an estimate. It is a solid number based on massive research and an endless number of questions that they answered. There is absolutely now way you don’t know everything there is to know about this project now. No way there is anything you haven’t uncovered. And their faith in that “Esti-Quote” goes through the roof. When the project goes over this time, they might even begin to question whether or not you know what you’re doing. Who could blame them? You drilled them for weeks about every little thing, and when they complained about all the questions, you told them you wanted to uncover everything so there would be no surprises. SO we set them up to faile

Guess, Then Plan

We had a chance. At the beginning we could have just said, “That’s just a gut-feeling estimate, based on my past experience with similar projects. There could still be surprises.”

If we spend SOME time doing SOME discovery and then bounce that against our own past experiences, we can come up with a fairly healthy estimate. We can then help the product owner understand that an estimate is a guess. Sure, it’s an educated guess, but it is still a guess. If we get it right it will be almost completely luck. Then, we help them to plan the development by taking that guess (yes, they still need the guess for planning purposes) and start measuring early and often to see if we still think we are right. We should adjust the estimate and alert the product owner as soon as we see problems (bad news does not age well) and we should be able to see any problems immediately if we are constantly measuring our pace.

In lean software, we start with that guess and begin measuring cycle times immediately. Then we can make projections based on those cycle times and compare them to our estimate. This constant feedback is the best way to ensure that there are no surprises at the END of the project. There sill still be surprises, but we’ll see them sooner and have a better understanding of how they will affect our overall timeline.

What do you think?

One of the things I routinely do when adding a new class library project, is remove all references and just add them back in as I need them. That is NOT a good idea for Visual Studio 2010. When I DID need System.Core, and went to add it back, this is what I got:

"A reference to 'System.Core' could not be added. This component is automatically referenced..."

After some Googling I found this article:

http://connect.microsoft.com/VisualStudio/feedback/details/525663/cannot-remove-system-core-dll-reference-from-a-vs2010-project

It tells you to add it back manually. Here is the part that needs back in the project file. After the last PropertyGroup node, add this node:

  <ItemGroup>
    <Reference Include="System.Core" />
  </ItemGroup>

You should be good to go again.

Hope this helps.

I’ve been doing the whole programming thing for awhile and reading and watching some of the best in the business. I have come to notice that the really great developers do a few things that (I think) makes them great. Now don’t get me wrong, I am not saying that I am one of these few. I still struggle with doing some of the things that makes one great at development. Coincidently, many of these things also make you a better person period.

Believe That Guidance Is Better Than Answers

This is one I have no problem with. I prefer guidance any time I am learning from another developer. Answers may get you going, but guidance will leave you stranded. At some point, you will come across a problem that can only be solved by thinking for yourself and this is where that guidance will really come in handy. You can use that guidance and extrapolate whatever technology to salve that problem (if it’s the right tool for solving that problem).

The problem is, lots of developers simply want someone to tell them, “Do this, then this, then set that, and write this.”

Favor thinking and learn the guidance of doing X and don’t ask someone to show you how to do X, if that makes sense.

Read, Read and Read

If you don’t like reading, you’re probably NOT going to make it into the Great Developer group. Great developers read books, they read magazines and they read code. Open source playgrounds like SourceForge, CodePlex and GitHub, have made it extremely easy to download code from developers you admire and see how they do stuff. Chances are, if you read their blog too, they’ll even explain WHY they did what they did (see “Guidance” above). MSDN and Code Magazine have not only code samples, but explanations of how to use certain technologies and sometimes even when NOT to use that same technology. Books are also out on just about every topic. I still favor the less technology centric books. For instance, I generally don’t buy books like, “Getting Started with Jiminy Jappets”. I look for titles like, “How To Write More Effective Code” (again, see guidance). The Addison-Wesley Signature Series is a great example of these types of books. They teach technology-agnostic concepts. Head First Design Patterns is another great guidance book. It teaches the "Gang Of Four" Design Patterns in a very easy-to-understand, picture-heavy way (I LIKE pictures).

Hang Your Balls Out There

Even though the advice came from a 3rd-shift Kinko’s attendant, doesn’t mean it’s not sound advice. Write some code and put it out for others to read, criticize and castigate you for. Understand that there are some real jerks out there who are absolute geniuses. Don’t be afraid to get some great advice wrapped in some really nasty language. Try to take what’s good about it and leave what’s not. I have a tough time with this myself. I don’t really have any code out there that is available for review (other than my demo code). It takes some guts to do, but in the end, there is no substitute for getting a community of developers to critique your code and give you ways to improve.

Get Involved

Speaking of community, the local and online user groups and discussion forums are a great place to hear about technologies and techniques you might never come across otherwise. Mostly because you might not know to look. But, once you sit down with a bunch of other developers and start discussing what you’re interested in, you may open up a whole new perspective on it. Don’t just go to the UG meetings and watch the presentations either, get out there and talk, socialize. I realize geeks weren’t meant to necessarily be social creatures, but if you’re amongst other geeks, it’s much easier. I’ve learned more in the last 3-4 years that I have been involved in the community that I did in my previous 8 years of coding without it. Socializing works, even if socialism doesn’t.

Continuous Improvement

Lean proponents might call this “Kaizen”, but I call it progress. We all know, especially in the technology realm, if you’re not moving ahead, you’re falling behind. It may seem like drinking from a fire hose, but step back and pick out the technologies that speak to you. The ones that may you’re little heart go pitter-patter. Concentrate on those. If you’re still overloaded, pick the best of the best. Just know that if you’re not looking at the code you wrote last week or at least last year with some embarrassment, you’re probably stagnating. That’s about all I can say about that, cause I am all out of clichés to throw at it. :0)

Write Code

Great painters paint, great writers write, and great developers develop. The most sure-fire way to improve your coding ability is to continue writing code. Don’t just write code that your work throws on you, pick that technology you love or are curious to know more about and walk through some blog demo examples. Take the language you use everyday and try to get it to do something crazy. Who knows, you might create the next Google search algorithm!

All in all, being a great developer is about finding yourself in all this code. If it is just a job to you, you will probably never be one of the “Great Developers”, but you’re probably okay with that. If, on the other hand, you do aspire to greatness, get out there and GET it. No one’s going hand it to you.

I just got back (a few hours ago) from Minneapolis, where I was speaking at the Twin Cities Code Camp 8. I’d never been to a Twin Cities Code Camp, and I have always heard such great things, so I submitted and got accepted to speak.

The conference (what I got to see) was great. My talk was pretty short on people, but there are many reasons for that. First, I spoke opposite Donn Felker (speaking about developing for Android) and Keith Dahlby (speaking about Dynamic .NET). So of course, my talk is going to be empty. How could I compete with that? Plus, my talk was about software process improvement, specifically about how our process has evolved. Maybe not the smartest idea to submit to talk about software process at a developer’s conference. The people who DID attend however, seemed to really enjoy the talk. There was good interaction and good, thoughtful questions. So the attendees seemed engaged.

I actually did get a chance to go to one session. I went and saw Javier Lozano talk about Open source tools for ASP.NET MVC. I am hip-deep in MVC stuff right now and getting up to speed on MVC 2 as well. I learned about MVC Turbine, Javier’s Open Source project. I will definitely be adding it to my MVC arsenal. Thanks Javier!

I did forget my AC adapter for my laptop and got a little lost in Minneapolis on my way to get one from MicroCenter Saturday morning, but other than that, it was a great trip. It’s a long drive, but seeing all the guys and getting two Nut & Honey rolls from Roly Poly in Eden Prarie for lunch on Saturday made the trip totally worth it.

I look forward to seeing what Jason & Chris come up with for next year! Thanks for having me guys!

Hey all. I am still here. Still kickin’. I’ve been swamped with work and community stuff. But I wanted to post about some of the things going on. Just finished up Twin Cities Code Camp 8, and had a blast! Always good to see these guys.

First of all, up-coming speaking engagements:

Iowa Code Camp – May 1st in Iowa City, IA [more info]

DevLink – August 5-7 in Nashville, TN [more info]

Plus I am organizing a second developer’s conference in Kansas City.

Kansas City Developer’s Conference (KCDC) – June 19th in Kansas City [more info]

I will also be doing Lunch & Learns for my company in April and May at JCCC:

April 29th, May 12th and May 27th at Johnson County Community College in Kansas City.

So May, June and August are covered. I may just take July off, I could use a break after KCDC is over.

I don’t really want to make an “End of 2009, beginning of 2010” post. Mostly because we’re almost in February, but also because I’m sure both of my readers could care less. I do, however, want to mention what I’ve been up to (mostly as just a shout out to all the cool events and people). Last year became SUPER busy right at the end, and so far this year, it’s been exciting too.

I have been traveling quite a bit around the Midwest, speaking at user groups and Code Camps. I did HDC last October, then Iowa Code Camp the first week in November. Then I took a short break for Thanksgiving and helped a little with the SharePoint Saturday KC in December, and watched as a great friend left Kansas City for good (miss you Becky). So far, I have started the year off with Jefferson City .Net User Group and Tonight’s Kansas City User Group. I still have Dubuque .NET UG and Wichita .Net UG in March.

WOW! Sounds like I’ve been busy (feels like it too). But I’ve had an absolute blast. The people I’ve meet are fantastic! I got a chance to meet lots of really smart people and talk to them about things they are passionate about. I’ve learned a lot about programming and about presenting.

I am currently working on a couple of projects that I hope will be helpful to everyone. I can’t say too much right now, but I should be announcing the fruits of those labors soon.

Until then, I hope to see you all around the community.

KAIZEN!

I consider myself extremely fortunate. I go to work everyday and do something I LOVE to do and I get paid quite well for it. Everyone should be that lucky. But about once a year I go through what I call, "Code Burn Out". I still enjoy what I do, I just don't come home and work on my own stuff. I don't spend all my time reading about software development and practicing to make myself better. I spend very little time on Twitter, and I don't even get on my computer very much after normal working hours.

Now you may say, "That's good. You should do that all the time. That's a great way to create a work-life balance and not get burnt out in the first place."

The thing is, programming was a hobby of mine long before it became my profession. I've tried other hobbies and haven't found any others that really stimulate me like software development. I just know I will hit a "slump" about once a year. It usually lasts for about 2-3 weeks. The problem is, this year it lasted for a month and a half.

Of course, I did have extra busy year. I got the chance to travel and speak quite a bit (Thanks to all who allowed me to speak at their events) and helping to run my local user group and organizing the first (ever I think) Kansas City Day of Dot Net. Maybe that's why it lasted so much longer this year. But after about 3 weeks I started to try to think of ways to break out of that funk. I finally did it, and wanted to share in case someone else can benefit. There are several things you can do to get those development "juices" flowing again.

Buy A New Piece Of Hardware

I bought a second monitor. I had dual 24" monitors for about 4 months until one of the monitors started flaking out. Of course, the 90-day warranty was expired, so I just started using one monitor at home. Granted it's a BIG monitor, so I wasn't TOO upset by it. But I recen5tly went and got a second monitor to bring back the duals and it has definitely gotten my spirits up.

Build Something Small, But Challenging

Nothing breeds enthusiasm like success. If you find TDD challenging, test-drive out a calculator app, or a simple website. If you find expression trees challenging, try building a small app that pieces together expression trees. Make sure it is something you can build in a weekend or two and make sure you have plenty of help resources.

Find A Beta (or Alpha) Technology And Give It A Go

If you are the type that likes learning without a net, picking up some Beta or Alpha software that you can try out and learn about can really build that 'Espirit De Code'. This approach can have multiple benefits. Not only will you break out of your funk, but you may be able to help others learn about that technology once it goes live. You also get to submit bug reports and help the developers of the software you are using and possibly even shape the direction of that software. How cool is that?

Get By With A Little Help From Your Friends

Finally, you can just talk to your colleagues about things you're mutually interested in. I work with a guy who is passionate about ALM and Lean software development, and I am too. So talking with him about new techniques, ways to implement lean process in life as well as software really gets both of us going. That kind of interaction can not only kindle passion in your OWN development, but others' lives as well.

I, like many developers, was raised on the idea of getting the database complete before writing the code. The database was the foundation of our application, and building a house without a finished foundation is insane. Also, don’t even THINK about changing the foundation once the house-building has begun. If you MUST change the foundation once development has begun, you’d better have a damn good reason.

When I started to learn about agile and lean software development, I learned about emergent design. Build only what you need for the small piece of the application you are currently building. That includes database, domain objects, services, DAL, everything. It felt very weird to be building membership stuff with no idea of how the rest of the database was going to look. Of course, there is an overall IDEA of what the design MIGHT look like, but until you need it, don’t build it.

There are two main reasons I think emergent design results in better designed software:

You Are Only Thinking About The Thing You Are Building Right Now

On the surface, this might seem like a bad thing. Focusing on the piece that you are currently building helps you to focus on the needs of the functionality you are adding and refrain from building “hooks” into a module for functionality that may never be added, or maybe added in a totally different way. Thinking about future modules (or already implemented modules for that matter) can influence the way you design this small piece of the application as well. Focusing on the fact that other modules need to “use” this module is different than thinking that module x needs to use this module. That thought can lead you to build in coupling between the current module and module x.

You Are Forced To Constantly Change The Application

Again, this may seem like a negative, but changing small pieces constantly makes the application easier to change. If I have to constantly change a module here and a module there every time I add new functionality, I am forcing myself to make each module easier to change. It allows me to see where pieces of my design become brittle and hard to change. This refactoring to ease change leads to loosely coupled, highly cohesive systems, which is what we’re are trying to design.

Use The Force, Luke

In the beginning, it may take some faith and some suspension of disbelief, but once you start seeing designs that are loosely coupled, highly cohesive and easier and easier to change, you’ll start to understand what the original XP Masters were talking about. Just stick to your principles, of writing a spec (test) before you build each granular piece, write the simplest thing that will make that spec pass and then refactor to clean up duplicate or complex code.

Got your attention? Good. It really doesn’t.

Developer’s, in general, are always afraid to let other developers see they’re code. They are afraid they won’t measure up. Since 90% (or better) of the world’s developers are male, maybe that insecurity of what’s under the covers carries over into development. Maybe we just DEFINE ourselves too much by our profession and our coding prowess. I am as guilty as anyone. I am always afraid someone will look at code I’ve written and think that I am a fraud. They’ll look at my tests and get the idea that I don’t know what I am doing.

There are two main problems with this approach:

Un-Critiqued Code Doesn’t Get Any Better

If you are truly serious about getting better at coding, the best and surest way is to let other people thrash it. Let others download it, play with it, give you feedback and send you patches. You have to have a thick skin, because some criticism will be blunt and sometimes just plain hurtful. Understand that even underneath the crap-crusted exterior of a complete flame, may be a small golden nugget of information that might change the way you code for the better. Don’t be afraid to wipe the poo away.

They’re Going To Do It To You Anyway

Every group has it’s assholes. The development community has quite a few, and they are a flatulent bunch. They will blow wind about every aspect of your approach from the initial architecture to the final execution. Again, take all that in, wipe off the muck and see if there is anything useful. If not, feel free to ignore them, if so, in a year you’ll be seeing that same asshole commenting somewhere else on the blogosphere about someone else’s raggedy approach. Be assured that they are not moving forward as fast as you, if they are only giving advice and never taking it.

Be True To Yourself

So back to my original statement: “It doesn’t matter if you don’t know what you’re doing.” Put your code out in the world as your approach not trying to purport yourself as an expert, and you’ll see that you get a lot of great advice from lots of great people who were once right where you are now. Even if all you do is ask another coder you know or work with to review your code, you’ll reap whirlwinds of benefit.

OK, I’ve been remiss in my duties as a blogger I know. Can you forgive me? Both of you? C’mon! It was only a couple of weeks. I promise to be more diligent in my posts in the future. So… we cool? Ok.

I am really posting to let you both know that I will be speaking at Iowa Code Camp tomorrow. I have two talks. One on BDD, of course, and one on The Opinionated Web Solution. This is a new talk that is about arranging web projects in a solutions.

If you happen to be in the Des Moines area, drop by.

~Lee

I’ve been a little scarce lately as I prepare for HDC (I’m doing a lightening round), finishing up a project for a client (rollout in a week), and help out some with Sharepoint Saturday, Kansas City (December 12th).

Be sure that I will continue my series on building a dev shop and things should get more back to normal after next weekend.

Stay tuned…

Recently, I read some posts about Duct Tape programming from Joel Spolsky, Michael C. Neel, Jak Charlton, “Uncle” Bob Martin and Jeffrey Palermo. I have followed these posts closely. While the intent is good, I think the delivery suffers.

The whole thing started with Spolsky (as it often does) creating a post that (I think) was meant to say, “Hey stop pontificating on sweet new techniques and start shipping software!” Excellent point. Do that. Don’t worry anymore what other developers might think about the code you’ve written, or you developer “Image” and start delivering business value. Spolsky’s Duct Tape Programmer uses Duct Tape and WD-40 to get the job done, and it reminded me of another archetype I’d been exposed to earlier in my life.

The Backyard Mechanic

The Backyard Mechanic, if you’re not familiar with the term, is a term used to describe those guys who have been around cars all their lives. They rebuilt their first Chevy short-block 350 at age ten, and have always smelled like axle grease. I like these guys. With the exception of the rebuild, I am one of these guys (it was my Dad’s Ford 302 and I was 13). If I am ever broke down on the side of the 395 between Barstow and Tahoe, I want this guy riding shotgun. He will get me to the next town. He will make sure I get there. But I would NEVER pay these guys to work on my car, not even myself. Why? Because the “Git-R-Done” tips and tricks they use are simply patches. They know how to compress a brake caliper with a crowbar and a piece of wood, but a brake tool work much better and won’t run the risk of breaking (no pun intended) your knuckles if your hand slips. If I am overheating because of a leak in a radiator hose, I can put duct tape on the hose and piss in the radiator to get me to the next town. But I certainly don’t want to run my car on piss & Duct Tape on a daily basis. I guess my point is, when people PAY you for a job, they expect quality. They also expect you to get their car fixed as soon as possible, and I guess that’s Spolsky’s point.

Ship The F___ing Thing!

In Jak Charlton’s post, he talks about the alignment of business and IT and, to me, that is a more important point. In the “Project Triangle”, (Time, Quality and Functionality) you can only focus on two sides at once. The point is, it is not up to IT to make those decisions; it is up to the business. Developers need to align their development goals with the business goals of their customer. It sounds obvious, but it doesn’t seem to happen as often as it should. If the business decides to focus on functionality and time, the programmers should focus on functionality and time as well. But the business should be making an informed decision when they decide to let quality slip. They should know what it means to let quality slip and THEY SHOULD DECIDE that quality is less important than functionality and schedule. They should be made aware that the second version of this product might require a complete rewrite (let’s hope not), but they should be aware of that and walk into that decision informed and with their eyes wide open.

Quality Saves Time (And Not Just In The Long Run)

This doesn’t mean scrap the idea of quality programming all together. What it means is that, given the choice between time, functionality and quality, time and functionality win and we understand quality may suffer. From what I’ve seen, quality software actually saves developers time. Now, writing fifteen layers of abstraction and creating a new development framework for your project does not constitute quality. That’s architectural masturbation. Following the SOLID OO programming principles at the very least can certainly save you time, and not just in the long run. The fact that quality code is easier to change and enhance, means that as you build feature 2, 3 and 4, it will be easier and easier to do without having to re-factor chunks of existing code to do it. Techniques like Test-Driven or Behavior-Driven Development were developed out of a need to deliver software quickly without letting sacrificing quality. When done correctly, not only does TDD speed things up, it gives you a low-level regression suite that helps you ensure you didn’t break anything WITHOUT having to go manually test everything again (a MAJOR time expenditure). ORMs save a tremendous amount of SQL writing, not because it’s hard to do, but because it’s time consuming, and if you’re looking to ship fast without sacrificing quality, a battle-tested ORM (like NHibernate or SubSonic) can be a great fit. Finally, quality saves time just be cutting re-work. Doing it right the first time, means you shouldn’t have to go back and redo it a second time, which should save you time as well. All this is real time savings in the first version, not some hopeful future-vision of time savings down the road.

Quality Is A Requirement

Ultimately, quality should be a customer requirement. I don’t mean as in it’s required, I mean as in the customer should specify the expectation of quality. When gathering requirements, it might not be a bad idea to ask, “..and how high should the quality be?”

It sounds like a dumb question, and it will need some qualifying when you ask it, but it can help. Telling the customer about the project triangle, if they don’t know about it, and explaining how each side influences the outcome of the project can be invaluable. The way I tend to breach the subject is, “If I am building software for an EKG machine, I probably need to ENSURE the highest quality, even if it takes a while, but when building a corporate website, if the outgoing email from the contact us form says ‘Thanks for your fedback’, no one is going to die.”

If you don’t make the customer specify which side of the triangle is the least important to them and help them understand what letting each one slip means, you’re telling them you’re going to deliver 100% on all three sides, and your project is doomed. For the most part, businesses understand what letting the timeline or the functionality slip means, but as developers we need to make them understand what letting quality slip means to them. Otherwise, they will not understand why it takes you twice as long to make changes to the codebase after version one, if you don’t.

Finally

I guess my biggest point is don’t start by sacrificing quality. Duct Tape and WD-40 are awesome tools and every developer (and mechanic) should keep some in his toolbox. But that shouldn’t be the first tool you grab. When time and functionality are the most important things, I would start by looking to tried-and-tested tools (like an ORM or a scaffolding framework) to help get thing delivered quickly without sacrificing quality. Then once you have exhausted all of those avenues, reach for the Duct Tape to limp the thing home (until you can fix it properly).

That’s all of my rant for now. It is my opinion, I am entitled to it, and dog-gone-it people like me.

Well, here we are again. Last time, we talked about project structure and came up with the one we’ll use for this series. Next we’ll talk tools. We’ll talk tools like Tim Taylor talks tools: with lots of grunts for my favorites and only a little explanation about what the tools do.) This is mostly because there is LOTS of material on the interwebs about all of these tools. I tend to favor the tools that are the most widely used for two main reasons: they have been battle tested by the largest crowd and two, they usually have the largest volume of content written about how to use them; some more useful than others. Having said that, let me also say that my choice of a specific tool doesn’t mean that the others in that space don’t have value. Most of the tools I will mention are all well respected by the well respected and each has its own strengths and weaknesses. If you are in charge of picking a developer stack, do your homework, but you could start with the stack I use and change fairly easily, if the particular tool doesn’t fit your needs. I will also easily swap one tool for another, if it will make the development process easier. ALT.NET… respect.

Getting on with it, there are several practices that I engage in on almost ALL projects that have tools that make them easier to do. The most important thing about a tool is that it should stay out of your way. Once you’ve set the tool in your stack it should grease the wheels of development. If it doesn’t, it’s either not the right tool, or you’re not using it correctly.

ORM or OR/M or O/RM (not sure where the slash goes)

An object-relational mapper is a tool that allow you to map your object model to your relational database (thanks again, Captain Obvious). Basically you tell your ORM that your Person object is stored in your People table and that it’s FirstName property maps to the FirstName field in that table and so on. Linq To SQL is an ORM. There are tons of them out there now. From free stuff (Subsonic, NHibernate and Castle ActiveRecord) to paid ones (LLBLGenPro and Telerik OpenAccess ORM come to mind). One of the things that will help in a transition to an ORM is adopting the idea that the relational database is merely a way to persist your object data. I have used only two and a half in the past: Nhibernate, netTiers and SubSonic. I say two and a half because I have not used SubSonic extensively or on a production project.. yet. It looks very promising. I choose NHibernate because of its many ways to map objects and it’s humongous user base. If I am hiring developers I can actually ask for NHibernate experience and probably see some.

IoC Container

IoC is inversion on control (so the C doesn’t stand for container and make for doubled-up words like GCO Carpet Outlet – Georgia Carpet Outlet Carpet Outlet). An IoC container helps to inject dependencies and works a bit like a factory method on steroids. If I have a dependency on a type, I can inject that dependency by inverting the control over that dependency to someone outside myself. If that made no sense, that’s ok, here’s how it works.

I need a laptop to make my presentation at the conference, but instead of lugging around my laptop (cause she’s a big girl), I can ask the conference to provide me with that laptop and bring only my presentation on a thumb drive. I am inverting the control of that dependency to the conference coordinators, and telling them it must have PowerPoint and Visual Studio 2008 on it. I “depend” on that contract. When I get there, I just ask for my lappy and plug my thumb drive in and away I go. This loosens the coupling to my machine. I don’t HAVE to have MY MACHNE to do the presentation. When I need a laptop for a talk, I just find one with PowerPoint and VS2008 and I get that dependency handed (injected) to me.

There are many free IoC Containers out there as well (StructureMap, NInject, Unity and Castle Windsor just to name a few). I chose StructureMap because of the large number of resources I found when doing research on Inversion of Control and Dependency Injection. (Also, Jeremy Miller is from Missouri, even if he lives in Texas now). I also feel very comfortable with the way you register you dependencies in StructureMap, although that could just be because that’s the tool I used to learn about Dependency Injection with.

BDD and the Infinite Melancholy

When driving a project, I try to drive it from the requirements (again, shaddap Captain Obvious). What I mean is, I try to codify those requirements so that they are executable. This makes them verifiable at every step of the project. Instead of “winging it” and hoping the change I just made doesn’t break something I developed yesterday or last week, I write the “specifications” in executable format, so I can use that as my checklist of what the system can do. I can also all the specs at any time to make sure everything still works as required by the customer.

For BDD, I choose Machine.Specification or MSpec. The syntax is very strange for C# developers at first, but I find the English-y way the code reads to be very compelling, and the report that it generates is a top-notch artifact to pass on to stakeholders. There are also other BDD frameworks out there (NBehave, NSpecify and you can even use RSpec (Ruby) to spec out your .Net code if you are so inclined.) Also, there are a few extensions to traditional unit-testing frameworks out there that allow you to work in a Behavio(u)r-Driven way (SpecUnit.NET, DevelopWithPassion.BDD and recently Gary Shutler has done a series on building your own BDD framework.)

Mock Me? Mock YOU, PAL!

If you’re going to do TDD/BDD, you’re going to need to mock. It’s that simple. If I tried to drive my design with BDD without using mocking or IoC, I would stab myself in the neck with a spork. Mocking is simply a technique of using “fakes” or “stand-ins” to isolate sections of your application in order to drive out their design. Remember, using BDD requires writing your spec first, THEN writing code to make it complete. By that very definition, you’ll be dependent on code that you haven’t developed yet and that you’re NOT going to develop yet. Mocking is the only way to get this done.

Again, there are free mocking solutions out there (Moq, NMock and RhinoMocks) and paid solutions (TypeMock). I’ve never used TypeMock, but I have heard that it can mock just about anything and if you’re trying to do TDD in SharePoint (I’ve heard) it’s the only way. I choose RhinoMocks, again because of the active user base and Oren Eini’s inability to stop coding/blogging/teaching for one second.

Architectural Pattern (MVSomething)

I started using a model-view-presenter pattern a couple of years ago, after I read an article from Jean-Paul Boodhoo in the MSDN Magazine in August of 2006 and a blog post from David Hayden about the Unity IoC container where he used Unity to wire together his Views and their presenters. It was an easy transition for me, because it felt a lot like web forms. At the time, ASP.NET MVC was in early preview releases and we had a significant investment in Telerik controls which (at the time) relied on ViewState to do some of their magic, and ASP.NET MVC doesn’t have ViewState available. I used MVP happily on several projects and still use it when a project requires ViewState or must be written in earlier version of ASP.NET.

ASP.NET MVC is the new kid on the block, but is making a huge impression. On me, as well. I have just begun to really dig into ASP.NET MVC, but the Sharp Architecture project can give some good guidance on how to set up, arrange and even test an MVC app. This is ultimately the one I have chosen for the project in this series, because it is very powerful and something I really want to get more familiar with.

Them Model-View-ViewModel pattern is the newest kid on the block and permeates the WPF stack (WPF Windows and Silverlight Apps). It is especially effective where two-way binding for your View to your View-Model is possible.

Quite a lot has already been written about all of these patterns, and rather than rehash them, I will just give links in the references area.

A-budee—A-budee—A-That’s all folks

I knew this was going to be a long post. We covered a lot of topics very lightly, but I felt it was important to give a short background on why and what we’ll use in this exemplary series. I’ll leave it at this for now, with some links below for more exploration. Then, next time, we’ll actually create the base project and set up it’s continuous build on our TeamCity CI Server!

Link-age

MVP – MVC – MVVM

http://msdn.microsoft.com/en-us/magazine/cc188690.aspx

http://davidhayden.com/blog/dave/archive/2008/02/19/ASPNETModelViewPresenterUnityIoCMicrosoftPatternsPractices.aspx

http://weblogs.asp.net/scottgu/archive/tags/MVC/default.aspx

http://haacked.com/Tags/aspnetmvc/default.aspx

http://code.google.com/p/sharp-architecture/

Mocking

http://martinfowler.com/articles/mocksArentStubs.html

http://weblogs.asp.net/rosherove/archive/2007/04/26/choosing-a-mock-object-framework.aspx

http://ayende.com/projects/rhino-mocks.aspx

http://devlicio.us/blogs/tim_barcz/archive/2009/03/19/choosing-a-mocking-framework.aspx

BDD

http://code.google.com/p/nbehave/

http://nspecify.sourceforge.net/

http://github.com/machine/machine.specifications

http://blog.robustsoftware.co.uk/search/label/BDD%20from%20scratch

http://www.lostechies.com/blogs/derickbailey/archive/tags/Behavior+Driven+Development/default.aspx

http://blog.scottbellware.com/

Inversion of Control / Dependency Injection

http://structuremap.sourceforge.net/Default.htm

http://ninject.org/

http://www.hanselman.com/blog/ListOfNETDependencyInjectionContainersIOC.aspx

ORM

http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

http://nhforge.org/Default.aspx

http://subsonicproject.com/

I might have made a decent lawyer. If I’d been born without any self respect and complete absence of morality, I might’ve become a lawyer. I love to argue. I love it. I like pitting my ideas against another’s. I like that at any moment I might have an epiphany and change my perspective or opinions about something. That’s learning. Basically, in technical arguing, I’ve seen basically three scenarios.

The Salesman

First is the useless scenario. Someone has a bone to pick or an agenda to push. This is the most frustrating scenario. In that case, I am not arguing your perspective against mine, and there is no way you will ever concede defeat, because you have a prize that you are after.

The Amicable Divorce

The Second scenario is that we agree to disagree. To me this isn’t much more useful than the first. I still may learn something and later when researching your points, I may find golden nuggets of information that I can learn from, but generally, this means that one of us couldn’t convince the other, but were just not comfortable conceding the point. If I do this, I generally assume that I am wrong and quickly start researching your points so I can figure out where I am wrong if I am right, I will be better equipped to convince you (or someone) next time.

Teach You, Teach Me

The last scenario is: We argue, one of us concedes the point and we end up learning something. That’s my favorite. I love to learn and I love to teach. Even more than I love to argue. (And I argue with myself in the shower just to keep in practice).

Ultimately, I like learning more than anything else, and arguing is a really good way to learn something. The problem is, you have to argue your point fervently, while keeping your mind open to the possibility that you’re wrong and be ready to stop on a dime and say, “Hey, I think you may be right!” The flip side of that is, being ready for the other person to say that you may be right without being a jerk about it.

Danger, Will Robinson, Danger

First, Be ready to answer all questions, and don’t EVER be afraid to say you don’t know something. Faking your way through an answer or an argument is a surefire way to get someone not to trust your arguments, and possibly lose interest in arguing with you altogether.

It is also important to be aware of your arguing style and warn others, however. I have a very animated arguing style, and I am six-foot-five and 350lbs. Seeing me wave my arms and raise my voice may throw people off, but I am truly harmless, and I am NOT using this style as a tactic to win an argument. (At least not a technical argument.)

So feel free to argue with me, and if you prove me wrong, I learned something and I owe you one.

Alright dear readers (both of you), I told you last time that I would answer that age-old question, “How many projects should I have in my solution?” The answer is: only as many as you need. I know, I know, but it’s not a copout, really it’s not. I’ve really found that is it easier to start with fewer projects and break them out when you need to, than trying to combine projects later on. Does that mean that one project with everything in it is right? Yes. If that is all you need.

I realize it sounds like I am being wishy-washy, but I promise I am not. For the sake of being opinionated (because “as many as you need” is hard-to-follow advice if you are looking for guidance), I will say I normally find that I have three projects. I tend to call them Web.UI, Core and Specifications. For this series we’ll be building a web project, but you could just as easily swap the Web.UI project for a WPF.UI project. Now, if you don’t consider the Specifications project as part of the “According to Hoyle” project, then I only have two projects. 

The thing that I will do is namespace everything within the project n a way that makes it easy to break them into their own project if I need to. So I had my data interfaces in a data folder (with that namespace) and inside that a folder for each type of implementation (e.g. an NHibernate folder, a SubSonic folder and an Entity Framework folder). This sill allow me to make a new project called Core.Data.NHibernate and move those files over and hopefully not break anything (I haven’t needed to do that yet).

I have been using this project structure for a while and am pretty happy with it. It came from stealing little ideas from respected developers around the community, and hashing it out with my co-worker, Troy. He is the one who kept reminding me that I didn’t need all those projects in the solution, and eventually we whittled it down to these three.

One thing that I will also do, is have my Specifications project a folder above the location where the Core and Web.UI projects are in the file system. I stole this Idea from Sharp Architecture and it makes for good, solid separation of the Specifications from the rest of the production code.

I hope this gets you ideas flowing for your own solutions and gives you a jumping-off point for deciding just what your solution needs in it. This should also be a good way to get the (civilized) conversation going about your won project structure within your team.

Next time, we’ll talk about tools. We’ll briefly discuss why you would use each tool and what comparable tools are out there. We’ll look at application architectural patterns (MVC vs MVP vs MVVM vs Web Forms), ORM tools, IOC containers, mocking and testing frameworks and some helper libraries that might make it easier to do some things within your own project.