Got your attention? Good. I’ll say it again: Waterfall is the perfect methodology.

It attempts perfection from the outset. Perfect requirements, perfect design, perfect development and perfect delivery in a perfect world. If you live in that world where requirements don’t ever change, then you should probably use a waterfall type methodology for developing your software; and you should drop me a line (although they probably won’t let you have anything sharp like a pencil to write with there).

For most of us, life is imperfect. Our development consists of false-starts, unsure or uninvolved customers, unskilled development teams and even less skilled project managers. Sometimes it’s amazing we’re able to pull it off. Our lives are a constant magic show; hoping to pull the rabbit out of the hat just one more time, while the audience sits in amazement secretly hoping (on some sadistic level) we fail. For most of us, that’s our lives. Perhaps not all of those things all of the time, but at least one of those things in play at all times. So how can any waterfall-ish-type methodology hope to help us deal with all that strife? Easy, it can’t. The very purpose of agile-type software methodologies is to help us deal with that imperfection.

Now I cut my teeth on waterfall-style development. Every time a deadline would pass or a budget would be blown we blamed ourselves. We thought, “We failed to follow the methodology correctly. We should have done more (insert methodology step here).” Boom. Process inflation. Pretty soon, we were writing more paper documents than actual code, and we were convinced this was a good thing. Fifteen pages of documentation for a fifteen-line program, and two-weeks to deliver. Sounds horrible, right? But that’s where we lived.

This week I started my first (small) project where we are attempting a Kanban/lean approach. It was absolutely liberating. Although we had less-than-stellar customer interaction, we had a point of contact we could bug whenever we needed to. We had only two developers, but we were both committed to the lean ideology. We set our sites on as little process as possible, and whenever we were unsure about something, we took a 15 minutes to hash it out and make a first-stab decision. It was phenomenal. We put up our first MMF (Minimum Marketable Feature) and broke it out into simple tasks. We didn’t spend a lot of time on the tasks, because we left ourselves open to being able to add or scrap a task when we needed to. At any time, you could come by the project board and see what we were working on, what was next and what was left to do to get this MMF delivered. We also allowed ourselves to say, “Hey, this process sucks, let’s try something else.” We stepped on each other’s toes a little and we fixed it as soon as it happened, quickly and without dwelling on the problem.

I also let myself deliver less than optimal code for some things. They were things that I knew we’d need to touch again, but it didn’t violate the SOLID principles, and as we got more information, we could rework that section to include new information with minimal effort.

And the work just flowed. We coded like monkeys with our asses on fire, and it felt good. We will get feedback on Monday from the users and see what changes need to be made and deliver that MMF. Then, we’ll pull the next MMF from the list, and start working it. I look forward to sharing more as we learn more, but this last week has been one of the most enjoyable in a long time. Thanks Troy!

~Lee

Today I have been using a ReSharper keyboard shortcut to rearrange chunks of code. I needed to move a method above another method in a class. With the cursor at the beginning of the line inside the chunk I want to move, I hit: Ctrl+Shift+Alt+UpArrow and it moves the entire method up one section (above the method before it).

So.. given:

public string SomeMethod()
{
    Here.Is.SomeCode.ToBe(Superseded);
}
public string MyMethod()
{
    Here.Is.SomeCode(that).Saves(Something);
}

I put my cursor at the line beginning where of the line in MyMethod. THat's the LINE beginning all the way up against the edge of the text editor window (the HOME key should get you there). Then hit Ctrl+Shift+Alt+UpArrow and it moves MyMethod up above SomeMethod.

R# finds code chunks separated by curly braces in C#, and moves them together. So code like this:

public string AnotherMethod()
{
    ForEach(var thing in things)
    {
        GottaDo.Dome(thing);
        ThenSomething<Else>(here);
    }
    var things = new List<Thing>();
}

I can move the Foreach loop below the declaration by putting my cursor at the LINE beginning of either line in the ForEach loop and hit: Ctrl+Shift+Alt+DownArrow and it will move the ForEach loop down as a unit.

This little shortcut has been extremely helpful for rearranging code today. Hope it helps someone else too.

~Lee

I hope everyone had a good Easter/Passover/Whatever holiday. It was good to spend some time with family. I am booked every weekend for the next few weeks so it was a good opportunity to have some family downtime. It is also a good time to reconnect with your own spirituality, whatever that is. Through the daily craziness we sometimes forget to connect with our own faith, and yesterday definitely did that for me. It’s a bit like a refreshing breeze on a super-hot July day.

This isn’t my usual tech-focused blog entry, but I just thought I’d post this in preparation for a long few weeks ahead. Once more into the breach, dear friends!

~Lee

Twitter has become quite the phenomenon lately. I even heard it mentioned on a Leno episode. As a developer, it helps me to watch conversations (sometimes arguments) between great developer to help understand the pros and cons of different technologies. It also helps to get inside(-ish) information about technologies that I’m interested in. I thought I’d put together a list of people that .Net developers might have good reason to follow on Twitter. This is REALLY not a “this one better than that one” list. I follow 477 people and every one of them provides some value (i.e. they’re local, I KNOW them, I am interested in some of the same things, etc). No offense to brilliant people who didn’t make the list (not like any list I make that someone didn’t get on would be reason to take offense). These people are based on their involvement in .NET stuff and how much they tweet.

• Scott Reynolds  - @scottcreynolds
• Jeremy Miller - @jeremydmiller
• Aaron Jensen - @aaronjensen
• Scott Bellware - @bellware
• Phil Haack - @haacked
• Scott Hanselman - @shanselman
• Steven Harman - @stevenharman
• Chad Myers - @chadmyers
• Shawn Wildermuth - @ShawnWildermuth
• “Uncle” Bob Martin - @unclebobmartin

That’s not so say there is NO value in following others (like @jbogard, @colin_jack, @RoyOsherove or @BradWilson), you certainly will. Mostly, these ten are the ones I see tweeting most often and having discussions that I follow and get information out of. Chances are, if you start following these people and watching their conversations, you’ll be led to follow others who converse with them.

~Lee

Believe nothing you read on the Internet today…

In the limelight these days you hear a lot of jabber about MVP, MVC, MVVM, MVKVM, MVMLK, MVMTV and any other MV… you can think of for ASP.NET. These architectural patterns are great but the most stable, testable and maintainable code is still written in traditional web forms development. Microsoft created web forms development to be a practical and easy to understand way to separate your concerns. By separating your business logic code into the code-behind, you make it easy for designers to run with the design of the UI without crossing wires with your business logic code. Using one of the MV* architectural patterns complicates you application unnecessarily. It leads to Inversion of Control and Interface segregation which is only going to complicate, what should be a really simple concept. The MV* patterns are simply a wave of people trying to coin something to gain some kind of name recognition.  Developers that use these patterns are usually the same developers who use ORM for their applications DAL. Basically, ORMs are for developers who don’t have the requisite SQL skills to write sprocs for their data access. Using sprocs is the most definitive separation of concerns. You actually separate you’re data access into a whole other application! Furthermore, Behavior Driven Development is simply the impatient man’s unit testing. It’s mainly for those who don’t have the patience to wait until all the requirements are gathered for a project and all the development is done. While I’m on the subject… damn, I just can’t do it. I just can’t continue with a straight face.

Happy April Fool’s Day!

~Lee