Three little stories, true stories, that I hope might enlighten, or at least, entertain ...
Truth and Consequences
I'm talking to an Agile coach last week, and he has a concern: He's working with two teams that are geographically dispersed. He is on-site with team A, which recently handed off an application to team B, about eight hundred miles away.
He's worried about Team B.
Here's the problem: When Team A wrote the application, they developed a fair amount of infrastructure. Automated developer-tests, continuous integration, a solid build-deploy process. My friend the Agile Coach is a little worried about how Team B is developing the software. In his words "They say they are doing unit tests, but I don't really know."
How can you know?
Here's an idea: Ask the developers to run the unit tests so you can watch.
That's it.
If they don't know how, they've got a problem.
If the tests throw up a big pile of errors, because the staff introduced dependencies in the codebase that the unit tests can't handle, you've got a problem.
If the tests run fine, count the number of assertions, come back in two months, and ask again.
My point: If you don't know, find out. It's not worth arguing about a fact.
Throw Away Code
So a programmer, who I will call Bob, develops a little script to solve today's problem right now. It's is "throw away code"; one-time code. Perhaps Bob takes some short-cuts, but it needs to be done right now, and everybody gets it. After all, it's just a quick SQL Update statement, to fill in blank Social Security Numbers with an autonumber field. No worries, after all, we're going to throw it away.
Perhaps you've lived through a situation like this. Let me ask you this: Do we ever actually throw it away? Or is this situation more likely:
Two month's later, Bob's manager comes back. There is a problem. New members who are inserted without a SSN are erroring out of the export. "Alls we need to do to fix this" he says, "is to run Bob's script again." And you do. All is well.
Except ...
The next month, the manager is back. Again. There's another problem. "We need to run Bob's script again, only we need to only run it for the last month's added members. So stick a variable in the database for last time the update run. And we need to run it on a schedule."
Yesterday's throwaway code is tomorrow's Mission-Critical Application.
When a piece of throwaway code aquires a name (typically "(name)'s script") and keeps getting re-run, beware.
At least one team I work with has decided that there is no such thing as throwaway code, and all production code needs to be developed "right."
Something to think about.
Schedule Magic
The team is working incredibly hard to hit the big deadline next week - the first of October. The project schedule even has a little wiggle room; you expect to have the new system in place September 27th, with a few days to monitor and fix and emergent defects.
Then, of course, something happens. Another delay. You'll have to ship even later, ever closer to the deadline.
One of the programmers asks: Wait a minute? Is the deadline really October first -- or is it September thirtieth at midnight?
It turns out this can make quite a difference.
Tomorrow
Three little stories; three generalities. All of them have exceptions, cases where they might not work. They are more like rules of thumb, or, perhaps, guidelines than hard and fast rules. I could talk about one of them in more depth if you'd like, or talk about something else -- or you could share your experience with Truth, Throw Away Applications, and Schedule Magic.
What do you think?