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 haven't had a lot to write about this month. I'm in the middle of this seemingly endless, painful cycle where the more we regression test, the more unimplemented requirements we uncover. That's right, regression testing is defining our requirement set . It's a symptom of this big rewrite I'm working on. The system has been around so long, that no one can remember every intricacy in the existing application. Regression testing is the only way to uncover the missing functionality. It's a nightmare! Compounding the problem is the difficulty in regression testing. There is a "certification" environment that is supposed to be an exact replica of production. But when we try to run production requests through our new application, the results are different. Our business users review these inconsistencies and often tell us that our responses are actually better than the production version. This is a good news/bad news type of thing. While it's...