I see a lot of talk online about this tool being better than that tool. It may sound obvious, but the tools do NOT make the developer. A tool is only a tool. If I gave my mother the best set of Snap-On tools that money could buy, she still wouldn’t be able to changer her own oil. On the other hand, if you gave my cousin Scotty a crescent wrench from Wal-Mart, he could probably rebuild a short block 350 in a weekend. Again, this may sound obvious, but the tools are only a way to help a good developer get the job done easier. A more inexperienced developer may even have MORE trouble with a good tool. I think that some people believe that the right tool will help a less experienced developer do things right. Generally, they just make it easier for him to turn a 300-line program into a 3000-line program.

Tell me if this sounds familiar: 

Boss: "Hey man! So, it's time for our status meeting, huh? Okay. Let's get started."

You: "Well, we're working on the [deliverable] piece of [project]. We estimated it would take about 12 man-days."

Boss: "Uh-huh. How long have we been working on it?"

You: "About 8 man-days."

Boss: "And how much is left to do, do you think?"

You: "Probably 8 more man-days."

Boss: "What's the problem? Was there a hold-up, or a maintenance issue?"

You: "No. Once we got into [feature a], we saw some problems with the way it was implemented and we had to fix it to get the new stuff built. Also, when we estimated [feature b] we assumed the data was there, but it wasn't. [customer] also changed the requirements a bit regarding [feature c]."

Boss: "Okay, so you think we've got all the kinks worked out then?"

You: "As far as I can tell."

Boss: "So we're about 1/3 over budget. Can we safely say we'll be ready to test [deliverable] by [date 8 man-days from now]?"

You: "Barring anything huge, yeah."

If you've had that conversation more than twice, you've probably started adding 30% to your estimates, right? That’s what getting better at software estimation is about, right? You estimate, and you track your estimates and the actual time it took and you begin to learn how long it takes you (and your team) to build software. After years of this, you can start to gauge the skill level of the team and the complexity of the project compared to other projects and teams you’ve worked on and you become adept at answering the “estimate” question.

We then rail on about “esti-quotes”. How a customer takes an estimate, that’s just a gut feeling based on your experience, and starts planning delivery dates and budgets around it as if it were a quote. When we miss estimate, we try and adjust for it next time, but with each new project, team and technology comes new variables added to our esti-quoting ability, and anxiety around software estimation continues. But, what’re you gonna do?

Stop Getting Better at Estimating

“Quoi?”, you might say, “What’s wrong with that?” I know I’ve spent a good portion of my career trying to get better at estimating. But what if I DO get better? How will that help the business? They’ll be able to better plan delivery dates and budgets. That’s a good thing. What else? Anything? That’s all I can think of.

Now what if I used my actual times to get better at building software? What if I took all the features (even the ones where I was over estimate) and tried to find ways to build each one faster without sacrificing quality? What if I focused on building higher quality software without sacrificing speed? How might THAT benefit the business?

Is It Good for the Company?

If I build higher quality software (loosely coupled and highly cohesive with all the “bilities”), how does that affect the company? First, it will probably better solve the business problem for which it was intended. There will likely be less bugs to fix (lower maintenance cost). It will take less time to implement new functionality (lower maintenance cost). When there are bugs, they will be easier to find and fix (lower maintenance cost). Adding or replacing team members is less costly, because the code is easier to understand (lower maintenance cost). It will take less staff to maintain it than more poorly written software (lower maintenance cost). Are you seeing a pattern here? Lower Total Cost of Ownership. Is that better than being able to plan delivery dates and budget better?

Get Better At Writing Software

This was the epiphany I had yesterday after talking with a friend of mine about our approach to Kanban at work. We were talking about “getting better at it”, but I was talking about getting better at estimating and he was talking about getting better at building software. We talked past each other for about 15 minutes before a light went on in my head when he said, “So you may get better at “guessing” when software will be done, but so what? I’d rather get better at building software.”

I almost broke my face smiling. “You’re right.” I said, “I don’t want to work at the fair guessing peoples’ weight.”

I felt a burden lift off of me. I HATED trying to get better at estimating. I always felt like there was no structure to it. There isn’t. I can have 90 years of software experience and still “guess” wrong when someone asks me how long it will take to build [feature/deliverable/project].

If I get better at writing software (something I LOVE to do), then I will get better at delivering higher quality code faster. Who cares if I’m 1/3 over my estimate if I’m cranking out high quality code in half the time I was six months ago? And if I can prove I’m getting better, I’m “guessing” that’ll be okay with my customer. :0)

A friend of mine, Troy, showed me this a while ago, and I thought this is probably one of the best office tips EVAR.

Have you ever been designing at the white board and accidentally wrote on it with a permanent marker? We use sharpies all the time for User Stories and it happened to me and I thought I was forced to live with the blue blemish on my whiteboard forever. Not true.

Take a regular white board marker (preferably the same color as the permanent marker) and write right over the top of the permanent mark. Let it dry and then erase as normal. The white board marker’s marks lift off the permanent marks!

This is especially useful for Kanban Boards.

Hope this helps someone as much as it has helped me.

~Lee

Obviously, my Tip of the Day is not meant to be a DAILY thing, so I thought I’d just rename to R# Tip. This is a pretty common one, but it’s possible some people aren’t aware of it.

For simple navigation, using ctrl+t or ctrl+shift+t can be invaluable. If you need to navigate to the file containing the Floogle type ctrl+t can get you there in a hurry. Hit ctrl+t and then type the name of the type you want to navigate to. You can also use capitalizxation to get you there faster. For instance, if you wanted the FloogleDTO to show up at the top, you could type the capitals and get there (e.g. type FDTO and the FloogleDTO type will be the only one matching).

But, if you need to get to a FILE and not a type name, use ctrl+shift+t and type the name of the file, same as you typed the name of the type before.

Try it out!

~Lee

With the flat response from the series so far, I thought I’d stir the pot a little. Again, I am not trying to start a flame war, I just want to share my opinion and start a conversation about it.

I’ll start by saying that I am VERY comfortable using SQL. PL/SQL, T-SQL and even a bit of MySQL (ack). But after using NHibernate for the last year or so, I can honestly say that if I never write another sproc, I’ll be totally OK with that. I don’t think sprocs are evil, or ruin your application, for me it’s about testability. I like the fact that I can write a test that can check my query logic and never have to touch the database. I like the fact that I can test all four basic CRUD operations with one line of code! Most of all, I like doing it in C#.

There are times when there is no good substitute for a good sproc. But for most applications, I don’t see the point. SPECIALLY for CRUD operations.

What do YOU think?

It’s true, I swear. It’s very simple to test if you can (C)reate, (R)ead, (U)pdate and (D)elete objects using NHibernate, and Fluent NHibernate makes it one (fluent) line of code!

Suppose we have an Employee object and we want to check that we can CRUD it AND reference to the Company (object) they work for in the mapping. It might look like this:

   1:  new PersistenceSpecification<Employee>(Session)

   2:      .CheckProperty(x => x.FirstName, "Dave")

   3:      .CheckProperty(x => x.LastName, "Jones")

   4:      .CheckProperty(x => x.MiddleInitial, "L")

   5:      .CheckProperty(x => x.DateOfBirth, new DateTime(2008, 11, 1))

   6:      .CheckProperty(x => x.Sex, _sex)

   7:      .CheckReference(x => x.Company, new Company{ CompanyID = 999, Name = "Wonder Wheels" })

   8:      .VerifyTheMappings(); 

Okay, it may not LOOK like one line of code, but I swear it is. One, long, fluent line of code.

Super sweet. If you’ve found better ways, post a comment, I LOVE to learn better ways.

~L

That’s right, I said it, I’ve been doing it, and I abso-effin-lutely love it.

A few months ago my co-worker, Troy, posted a question on Stack Overflow. We were doing integration testing on a project we were working on, and as the object graph grew larger, the code required to test query logic became painful. Since I am a sissy and don’t like pain, Troy asked the question on SO about how we might do it less painfully, and we got this answer, and it totally changed our TDD/BDD lives.

The answer came from Garry Shutler, here and I’ll just sort of re-iterate it.

We created a base Interface for our repositories IRepository<T>, with a method IQueryable<T> All(). like so:

   1:  public interface IRepository<T>

   2:  {

   3:      IQueryable<T> All();

   4:      // whatever else you want

   5:  }

   1:  public IQueryable<T> All()

   2:  {

   3:      return session.Linq<T>();

   4:  }

We can then mock the IRepository<T>:

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

   1:  _repository.Stub(repo => repo.All()).Return(TestCustomers.All().AsQueryable());

   1:  [Test]

   2:  public void should_return_customers_matching_first_name_last_name_and_dob()

   3:  {

   4:      Assert.That(_returnedMatches.Contains(_firstNameLastNameDOBMatch));

   5:  }

Many thanks to Garry for all the time he saved us, I immediately subscribed to his blog and have not been disappointed. I hope this helps someone as much as it has helped us.

~L

1) OK, so Coders4Charities went well. The .NET User Group Meeting went well. Now it’s time to take a (small) break.

2) Most who know me probably already know, but I’ve been assigned as regional mentor for INETA membership for Missouri and Kansas. That will be consuming some of my time to get my head around who my UG leaders are and what they need from me, as well as helping fledgling UGs get started.

3) I won Fourth Place in Community Credit for the month of April! I get a sweet pin clock.

4) I will be speaking at the Twin Cities Developer's Guild on May 12th (Yikes next Tuesday) about BDD and I will be helping deliver some Mix 09 content at the Jefferson City .Net User Group on June 9th.

5) Today was my dog, Frieda’s 5th birthday, so we went to the park, got her a hamburger and Stacey made her a carrot cake. I know, we spoil her, don’t look at me like that.

6) I started my foray into Ruby programming tonight. I am mostly interested, because I am a freak for anything BDD, and RSpec is the gold standard to me of Context-Specification style BDD. Haven’t dived into Cucumber yet, but that’s coming soon. I am really liking the syntax of Ruby. It is easy to learn the basics and I am already creating classes and small programs. Now I just need a small project to sink my teeth into and drive the design out with behaviors using RSpec.

That’s about all for now. More information to come an all the new happenings. Stay tuned, dear readers!

~Lee

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