Loosely Coupled

This topic seems to be pretty popular lately. First I saw Martin Fowler's comment on technical debt last week. Then Jeff Atwood brought up the topic in this week's StackOverflow podcast (@53:30). Basically, technical debt is the price you pay down the road for a "less than optimal" design choice today. I particularly liked Atwood's metaphor that you know you've incurred technical debt when you give a long sigh every time you need to modify some part of the code base. You know that the changes are going to be painful (and expensive) to make. It's time to refactor. A few comments based on my experience. I've been noticing less technical debt in my own code since starting to follow a test driven development approach more religiously. Maybe there's something about this approach which makes your code more "real than theoretical" from the start. It helps you make better decisions without thinking about it too much. Maybe it's becaus...

I'm the type of person who constantly looks for ways to improve. No matter how well things go, I'm always striving to "plus" an experience - smooth out the rougher edges to make the next time even better. Sometimes the need to do this drives me a little nuts. It drives my wife really nuts! When things don't go well, this task can be a little overwhelming (and depressing). There are so many areas for improvement, it's hard to know where to begin. I've spent the last year or so, reexamining my software development experience - looking for trends in the tools and ideas that helped the teams I was on to be highly productive (and conversely where the lack of some practices led to a lack of productivity and frustration). Combined with many of the things I've read by Spolsky , Fowler , and the Poppendiecks . I've created a list of criteria I'd consider essential in an ideal software development environment. Talk to the target user...

I'm usually not in charge of scheduling. I've contributed to schedules, but someone else - usually someone from management - drives schedule creation. I also can't remember a situation where the schedule actually worked. What I mean by this is, a lot of time was spent to create schedules for 2-3 months into the future - then not really revisited (adjusted) for a month or more. By this time something invariably happens (priorities change, initial tasks take longer than expected, vacations/time off weren't accounted for, etc.). This throws the entire thing out of whack and quickly makes it obsolete. A month or more will pass, then the whole process starts again with the creation of another schedule. For the project I'm currently on we've spent a lot of time creating 2 schedules from scratch and are currently creating a third. The first two have been complete failures and I have low expectations for the third. It's frustrating to spend a lot of time and ...

Steve Yegge has this great post today about business requirements and building software that you'd personally use in a domain that you actually know . Great stuff! I need to figure out a way to print wallet size copies to hand out at requirement meetings.