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 haven't been doing too much development as I wait (and wait and wait) for our acceptance testing to complete. Here's a quick rundown of what I've been thinking about while waiting for that to complete.... I've been reading and participating in some of the discussions on StackOverflow . It's a great way to get a pulse on what others are thinking about and working on. I've also been able to pick up some things I never knew existed before. I've taken part in other question and answer type sites before and I had my doubts how helpful this would really be... I've been pleasantly surprised. I listened to these great podcasts on alternative energy. Grass as fuel?? Pretty cool. I've been thinking about maybe getting some solar panels for my house. I would never have thought that the Northeast would be a good place for these until I saw a cool episode of Nova sometime back where someone in Mass. had some installed on their house. Now maybe I...

I just listened to Kent Beck's presentation from this year's RailsConf for the second time (something I almost never do). One of the gems I loved about his presentation was when he described test driven development as "cheating" (at the 27:08 mark). Exactly! I feel a little foolish for not thinking about it about this way before. It is cheating! How many times in school did I wish I had the answers to tests before I took them? Or wished I even knew the questions? Answer: Every time. Why? Because it would've been so easy! Imagine all the time I would've saved, with assurance that my work would always be correct and complete. Extending this idea to software development should be a no brainer - figure out what the software should do ahead of time (and write tests for it). This way you know exactly what to code, when you are done, and that your solution is complete and correct. It's so easy (it feels like cheating).

Yesterday two people at the place I'm working gave notice that they'll be leaving the company. There has been a lot of turnover in the six months I've been here. Based on what I've seen, I'm not really surprised. Still, there always seems to be some head scratching by management and some longer tenured employees on why these people are leaving. Here's some of what I've seen. I've already mentioned the poor tooling and processes in place here - starting with Lotus Notes - so I won't rehash that here other than to mention the tooling shortfall has been brought to management's attention many times with no real action. Some people I sit near are in a constant state of emergency. Their production systems break daily (even nights and weekends) because the company's trading partners send messages that don't conform to their messaging API. Instead of rejecting these transactions, management's approach is to ignore the problem, askin...

I've been a fan of Joel on Software for some time. Recently Joel (Spolsky) started a new enterprise, stackoverflow.com , with Jeff Atwood. They've been releasing some entertaining and informative podcasts as part of this new endeavor. Good Stuff. Who knew you could wash your electronics?? ***** Joel has written a few books. One I haven't read yet is titled Smart and Gets Things Done: Joel Spolsky's Concise Guide to Finding the Best Technical Talent . While I'm sure this book is helpful, what I really need is a book that can help locate progressive companies which allow employees to work smartly and get things done. I don't know if it's endemic to the region I live or it's more widespread than I imagine, but none of the companies I encounter here are doing anything close to Agile development, few are working with Ruby, most are afraid of open source, none have heard of REST web services, and most are reactive problem solvers rather than proactive....