Posts for category: process

Jay Fields Explains It Better

This piece by Jay Fields came into my RSS feeder mere minutes after I posted the last couple of pieces. It’s Fields’ thoughts on the same Joel Spolsky piece I just wrote about.

As you might expect if you’re familiar with Fields’ writing, it’s somewhat more detailed and nuanced than what I wrote. In particular, fields makes one point more clearly than I did:

Joel doesn’t come out and say it, but I got the impression he’s ready to throw the baby out with the bath water. Unit testing 100% of your code is a terrible goal, but that doesn’t mean unit testing is a bad idea. Unit testing is very helpful, when done in a way that provides a positive return on investment

Unit testing 100% is not something you should do just for the sake of doing it, and how close you can get depends on tools, domain, and the like

Fields also says this:

Often, teams don’t know what will make them more effective at delivering. I think the underlying problem is: People don’t know why they are doing the things they do.

He’s supporting being mindful of why you do what you do, which is always a good idea, and also being pragmatic about fitting test procedures to your project.

The last three headers of Fields’ post are “If It Hurts, You’re Doing It Wrong”, “Test Should Make You More Effective”, and “Tests Are Tools”. All good mantras.