Developing some DLL…

“Developing some DLL in C# 3.0 to implement some functionality”

A bullet point on a resume. A disappointing bullet point.


“Any fool can write code…

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

I found this guy while researching the use of var following a spirited debate with co-workers. (In case you’re wondering, I’m pro-var. Viva la var!)

If you write tests after writing the code…

If you write tests after writing the code, you assume the test is OK because it passes, when it could be that you have bugs in your tests. Trust me—finding bugs in your tests is one of the most frustrating things you can imagine. It’s important that you don’t let your tests get to that state, and TDD is one of the best ways I know to keep that possibility close to zero.

Roy Osherove, The Art of Unit Testing

A co-worker just turned me on to the book The Art of Unit Testing by Roy Osherove, and I’ve quickly fallen in love. This quote is a little nugget from the first chapter.

“A late change in requirements…”

A late change in requirements is a competitive advantage
–Mary Poppendieck

My team works almost exclusively on small, custom projects. Each project begins with high-level requirements gathering, an estimation of effort, and a cost proposal. If the customer accepts the proposal, a contract is signed, and my team works with the customer to create a more detailed requirements document before beginning development.

The problem with this process is that it isn’t very agile, and, even though we complete the project by converting the requirements document into stories and banging them out in sprints, we sometimes fall into the same old waterfall-pitfalls. Requirements written at the beginning are not always the right requirements. Something that seems very important at the start might not make sense by the end. Or, there might be aspects that weren’t considered during requirements gathering, which can lead to important requirements that went undocumented.

At the end of any project, what matters most is that the customer feels good about the business value they’re getting from what they bought. If a project satisfies all of its requirements but ultimately provides no value to the customer, the project is a failure. Conversely, if a project meets only a subset of its requirements but delights its customer, it can be considered a success.

Realizing that requirements will change–and expecting them to–is an important strength of agile methodologies. As features are completed, review them with the customer and re-evaluate what comes next. Sometimes, you might find a feature is no longer needed. More likely, you’ll uncover a feature that was missed but will provide much greater value than what was originally proposed. Shifting requirements late in the game is how you can take advantage of a newly found feature like this, and that’s part of what makes agile so powerful.