obie

"Nothing is more heartbreaking than realizing that a worker who is trying his hardest can’t cut it."

So true. I've had to fire a few people that met that criteria and it's really difficult to do.

In a startup situation, it might be advantageous to discontinue the full-time relationship but allow them to continue working part-time at their leisure (or according to some schedule) in exchange for continuing to vest their equity, but no cash.

Looks like it might have a sad ending -- the boy might have fallen out while the balloon was adrift.

The link to the source code (omitted in the article) is http://github.com/engineyard/rails_dev_directory

LOL, you just described the way that Rails first makes it into a lot of large organizations. Luckily, if you follow Rails conventions you should be pretty close to "production worthy" at step 6.

As for step 10, it's the rare system that doesn't suffer that two years into production.

Hook me up obie@hashrocket.com (thanks)

"Diving debt into reckless/prudent and deliberate/inadvertent implies a quadrant, and I've only discussed three cells. So is there such a thing as prudent-inadvertent debt? Although such a thing sounds odd, I believe that it is - and it's not just common but inevitable for teams that are excellent designers."

The concept of prudent-inadvertent debt was new to me but immediately made sense.

Bravo!

The burnout objection is laughable. Our consultants are required to bill 35 hours per week, which translates to an average of 7 hours of coding or less every day (there is billable work like meetings that is not writing production code).

We don't work weekends and we don't do overtime. Like, ever.

It's hard to do that on a client's dime, at least for me. (I know other consultancies do it all the time and it disgusts me.)

Absolutely. It took me four years of misstarts and agony (2000-2004) to really understand and get good at pair programming. During that time I mostly kept the faith about it since I was a zealous XP advocate, but had a large measure of doubt about its true effectiveness.

It took working with talented pair-programmers at ThoughtWorks to really make it click.

Thanks! :)

"Pair flow" is difficult to achieve, especially if you're new to pair programming. What you describe here is simply a dysfunctional pairing situation.

Happy to see this big step towards transparency. Don't like that it has waterfall concepts built in and excludes defense spending completely. But hey, it is progress and Fed CIO Vivek Kundra made progressive comments towards the importance of releasing early and often. To wit, the new dashboard site is a "beta" release.

We've been using Pivotal Tracker at Hashrocket for over six months and it's an integral part of our success. It's an opinionated tool in the way that it codifies a successful Agile workflow between developers and their project stakeholders. We couldn't live without it at this point.