I went to the Chicago Area Ruby Group on Monday for Andy Lester's talk on project management. No crazy story this time because I took the train, although I did have to jog most of my way to the Thoughtworks building, which always seems to be my lot with the Metra schedule no matter where I'm going or when I need to get there. Note to self: If the appearance of composure is any priority, take cab ^^;;.

Half of Andy's presentation was about his alternative to the agile methods of project management. The other half was on technical debt, which I found rather interesting and fairly applicable to IBLP's IT operations. Here's a loose summary of his presentation (slides available at Andy's site).

Project Estimation and Tracking

1. Write it down. The project should be started with some sort of written document. Programmers like to begin coding right away because they think they know what the customer wants, but that's often not the case. A written agreement will help you avoid misunderstandings and will get any immediately obvious questions answered right in the beginning. Wikis are a good medium for these documents because of their collaborative and malleable nature. "It's not like in the 90's where one guy was Master of the Document."

2. Estimate. Give a rough idea of the time/money cost up front. This helps the customer to prioritize and prune, as well as feel in control of the project. Make sure they know that it's not a rigid commitment, because the next step will adjust your estimate.

3. Refine. Break up your estimate, perhaps into outline form for each task. You're doing design as you go, so keep notes. No subtask should be longer than 4 hours, because you can't estimate accurately above half a day. Doing it this way helps to distribute risk: Estimates are usually off by 100%, not 10%. You may need to take a day to sit and think about what you're getting into. You're paying up front in time to be able to know where the end point is. Remember that typing is not programming -- thinking and breaking down tasks is programming.

4. Plan and track your tasks. Write out your task plans Friday afternoon so everyone knows exactly what to do when they come in Monday morning. Try to finish each task before going on to the next one. Track your tasks so you always know what your status is, even in the middle of the week.

5. Adjust as necessary. Sometimes you'll need to shuffle the order, re-estimate, or break up tasks further. When handling new requests, say, "I can do it, but I'll need a day to tell you how long it will take." Customers need to know that nothing is free and that even the estimation of new features will take time. "Do you want the 30 second, half-hour, half-day, or half-week answer? That's what it'll be worth."

Always be aware of the status of your project. If you know you're not going to make a deadline, you should tell your boss or customer as soon as possible. Be honest with everyone, including with yourself.

Getting Out of Technical Debt

"Try to think of Peter Francis Geraci's face looming over you as we talk about this."

Identify your debts:

• Clutter -- disorganization and confusion
• Failing tests, unfixed bugs, unpatched security holes
• Fragile or ugly code -- this often means the code is not read, maintained, or understood
• Code without comments or outdated comments (an amiable audience member adds: Strive to write the kind of code that doesn't need comments, but do maintain your documentation.)
• Truck-sensitive knowledge (the truck-factor: How many people can get run over before your company collapses?)
• Code ownership -- this makes the code truck-sensitive, and a bottleneck
• No coding standards -- standards help minimize the arguments and the time wasted worrying about or fixing differing code styles
• Missing infrastructure -- do you have version control, bug tracking, backups, cron jobs to do your dirty work?
• Jerks on the team -- they may be a negative productivity factor
• Jerks in management -- well, that's beyond your control
• Not realizing you have tech debt, or ignoring it

Determine the cost of paying the debt. Think in terms of time, money, and risk. Create the justification to sell your boss/customer on your changes in corporate language. Quantify everything: What exactly is the improved turnaround, extra quality, and decreased risk worth? All cost assessments must include opportunity costs: What could be done if this change wasn't made?

"Land one plane at a time." Watch the corners and the center will take care of itself. Automate your corner-watching.

Avoid future debt by not incurring more debt. Take notes when you incur debt anyway.

"However," Andy concludes, "Sometimes you just have to do what the customer wants."