August 2008 Entries

Recently I posted a comment to an article talking about only billing hourly and not entering into fixed bid contracts. I agree with the post (for the most part), but felt compelled to respond to one of the comments. I thought I would include this in my blog because I think it is an interesting topic.

The focus here is not how we estimate from an Agile approach (read Agile Estimating and Planning if you are looking for that). Here, I am addressing a specific argument that Agilists "can’t estimate how long a project will take, so you are not taking responsibility". This could not be further from the truth.

We all have experience estimating how long it will take to complete a project. Remember, these are estimates. The accuracy of an estimate depends on a number of things including the level of detail at requirements gathering and how much things change before the final delivery.

Just because you are Agile doesn't mean you do not estimate. From a long-term planning perspective you can still provide the customer with a time estimate. However, it is generally recommended to broaden the estimate the larger a project becomes. If it is a one year project, estimate that it will be completed Q3 2009. As you get closer to the end of the project, you can refine the target, like Sept 2009 or as you get even closer, a real date like Sept 26, 2009.

With a high-level time estimate, the customer can still budget for the project. You can give the customer a rate and a time estimate. Let them do the math. They will see that the project will cost them between $150,000 and $200,000. If you feel compelled to do so, do the math for them.

One of the purposes of Agile is to give the customer what he wants, not what he wanted. A waterfall approach without communication with the customer during development will lead to delivering a product the customer will not use. With Agile, because you are in constant contact with the customer, providing regular updates on the product, you will be able to adapt to the customers changing needs.

The beauty of an Agile project is that the customer is able to provide feedback continuously. Many times this means delivering a better product in less time. The customer gets exactly what he wants and saves money at the same time.

All that said, if you are a company without a lot of credibility (like a start-up), many times you don't get to call all of the shots. If the customer demands a fixed bid, perhaps you take it because you need the revenue. However, you can still apply Agile principles within a fixed bid project. Change management just becomes harder with a fixed bid.

So, can an Agilist estimate how long a project will take? Definitively, yes. Does and Agilist take responsibility for her estimates? Again, yes. However, she goes beyond that. She takes on the responsibility of giving the customer what he really wants.

I'd like to explore the definition of "broken". Here is a modest list of signs of broken code.

A test is failing (I know, painfully obvious)

The code doesn't do what the user expects. (Likely, you actually have a broken test or it's missing altogether.)

The code is hard to read, hard to enhance and brittle.

I think the first two bullets are obvious and the customer will see the value in fixing the code.

The final bullet leads us to refactoring. How do we know when we need to refactor? I won't get into the details, but, perhaps from a simplistic perspective, I refactor code to do two things: reduce duplication and reduce complexity. Jeremy Miller has a nice post on the subject.

Certainly, we do not want to fix something that is not broken. The point is that, perhaps we need to revisit what it means for code to be broken. The code is broken if we are constantly having to fix it after making a "minor" change. The code is broken if it takes us days to add something we expected to be relatively simple. The code is broken if J. Doe is the only one comfortable enhancing it.

It is important to note that the code is not broken in this sense until we are ready to make a change to the code. We should remember YAGNI when we are refactoring. Refactoring for something we are going to need just means we are likely to refactor the code again when it comes time to add something we actually do need.

Can you think of other signs of broken code? If there is ROI in regard to refactoring, where do we draw the line?

In Css and Custom Server Controls I talked briefly about a problem with the mark-up for my server controls being injected with &nbsp; after toggling to Design View. It was certainly something I could work around, but it was annoying nevertheless. I just couldn't see anything in my designer code that could cause the issue.

I wondered if this could possibly be the same issue I was experiencing. I had already installed SP1, so I went to one of my "problem" pages and toggled to Design View (I have mine set to default to Source View). I made a minor change while in Design View to trigger an update to the markup and switched back to Source View. No NBSPs! Now I can share my controls with the rest of the team without attaching a disclaimer. Woo-hoo!

Chandler is basically a personal organizer improving on Outlook, et al. You should check it out.

The book is an account of the beginnings of this open source project. Perhaps the best thing I got out of it is learning from the mistakes of others. Otherwise the book is a reflection of how lost the project seemed to be the first few years.

I've gone through a few iterations of AnkhSVN over the last couple of years. The first installment was quite unstable and was only good for viewing the status of your source from within the IDE. You would use the other features at your own risk.

However, Ankh looked extremely promising so I kept an eye out for updates. The last 1.x update I had installed was working rather well, though there were some limitations.

With the release of 2.0 most of those limitations are almost forgotten history. Some of the nice features in 2.0 include:

The pending changes window

Being able to rename a file within the IDE.

Being able to delete a file within the IDE.

Excellent online documentation

Previously, a lot of effort was involved if you wanted to rename, delete or move a file. Thanks to 2.0, that headache is over.

One complaint some developers (myself included) might have, is the fact that the project subfolders do not reflect the status of their children. So, if you have a collapsed folder, you may not realize that a source file within the folder has a modification. However, becoming more familiar with the pending changes window should more than make up for this "loss". In fact, the great guys at CollabNet give a logical explanation.

I've used Refactor!Pro on a previous project and liked it quite a bit. I assume a lot of these include the same basic features. Perhaps the difference is in the number of refactorings and additional features outside of refactoring.

ReSharper seems to be the most widely used. But, does it give the most bang for your buck? Does it meet the needs of a cost conscious start-up developer like myself?