October 09, 2007

The Office

I've had an office a few times in my career but recently I got the office.

It was a sign of status, a symbol that I was one of the heavies at the firm.

A former boss even strolled in, checked the room out, and said "wow, nice pad." Unsaid was that it was better than his.

Good, right?

No!

Offices put barriers -- real and imagined -- to communication with the rest of the department. In the just 5 days I've been in the isolation chamber called an office there have been a handful of incidents that just would not have happend had I been sitting on the floor. My favorite is when a colleague sent me an IM asking if he could come in and ask a question!

Feedburner founder Dick Costolo remarks why an open floor plan (without offices) is preferred. Agilists like their software team to be seated in a common area where people can comingle and communicate without barriers.

I wholeheartedly agree. I'm an Agilist, and will leave the office for the team area.

Posted at 07:04 AM | Permanent Link | Comments (1)

February 07, 2007

Ignored test are OK; too many ignored tests too long are a smell

I'm sometimes startled by zealots that insist that tests should never be ignored. Ignored tests are OK; too many ignored tests or long-ignored tests are a smell.

Tests marked as ignored are very useful: they remind you of work you need to do and allow you to check in work-in-progress without breaking the build.

The number of ignored tests is directly proportional to your code volatility. The greater the amount of work being done on your codebase the greater number of ignored tests are to be expected.

ignore1.GIF

This implies that as you approach the end of your project ignroed tests should decrease. After the system is feature complete there should be very few ignored tests. Before going into production all tests should be enabled.

Long-Ignored Tests Are A Smell

Tests that have been ignored for more than a few days are a smell. Obsolete tests, unclear requirements, or just bad code hygene will lead to long-ignored tests.

To combat this I put the date on which I ignored the tests in the Ignore attribute and give precidence to those tests that have been left alone the longest.

[Test]
[Ignore("Garrett: 20 Dec. waiting for requirements on final file format")]
public void ValidateOutputFileFormat() ...

Too Many Ignored Tests Are A Smell

If a large refactoring or requirements change requires a huge number of tests to be ignored it is typically a sign of either two things: tests which test the implementation rather than the contract of a class (behavioral mocking is a big culprit here) or tests which are not fine-grained enough.

Posted at 07:16 AM | Permanent Link | Comments (1)

November 07, 2006

Time to go home? Leave a broken test

I often have to take a few minutes at the beginning of each day to remember where I left off yesterday. I've tried things like leaving a note to myself to remind me of the details of my work in progress.

The most effective thing I've found, though, is leaving a broken test.

It's simple and effective if you're test-driving code. For example, let's say I'm writing a class that encapsulates whether a password meets a password policy. I'm hungry, tired and want to go home in time to go for a run:

[Test]
public void ValidPasswordMustHaveANumber()
{
    Password password = new Password( "PasswordWithNoNumber" );

Assert.IsFalse( validator.IsValid( password ), "passwords without a number are invalid" );
}

When I come in the next morning I'll run the tests and see:
Assertion failed: passwords without a number are invalid.

Then I'll remember where I left the previous day.

Posted at 07:50 AM | Permanent Link | Comments (5)

November 01, 2006

Please Find Posted This Blog Entry

A poorly constructed and tired phrase in email writing is:

Please find attached the document that you requested…”

This phrase is verbose, passive, and imprecise. Strunk and White cringe every time it is used.

It is imprecise: Who attached the document? You? Me? The Document Fairy? The phrase doesn't convey the actor.

It is verbose: The alternative, “I’ve attached,” is shorter.

It is passive: It uses third person passive voice.

Don’t use this phrase. Replace it with the straightforward and concise “I’ve attached the document…” It should be included in chapter 5 of the next edition of Elements of Style.

Posted at 07:48 AM | Permanent Link | Comments (1)

October 31, 2006

Agile is a means to an end, not the end itself

Agile software practices are a tool. They're a means to an end, not an end themselves.

The goal of any project team is delivering business functionality with high quality and low cost. The manner in which you achieve these goals varies depending on the people you have on the team, the company's management structure and style, and the project's goals.

Just because the team is pair programming, adaptively planning, and driving development with tests does not mean it will achieve the business goal. If the team is programming solo and doing big up front design it does not mean the team will fail.

I advocate Agile practices; they are generally a better way to get software written.

Too often, however, Agile zealots insist that their ideas on how a project should be run must be unquestionably followed. They disregard the client's wishes, processes and management style. They do not consider the team members' abilities and wishes.

These zealots end up damaging the project more than they help. They strain relationships with the client and are too quick to change project practices.

Remember, you must always ask yourself: is this practice I am suggesting going to allow us to deliver more business value faster, cheaper, and with better quality? If the answer is yes, then talk to your teammates about making the change.

If they aren't appropriate, don't advocate the practice just because "it is Agile."

Posted at 07:14 AM | Permanent Link | Comments (2)