Loosely Coupled

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.

It's been almost a month since I last posted! I think it's partially due to the fact that I haven't had much interesting work to talk about. Mostly I've been frustrated in trying to convince my teammates why automated unit testing is important (and how to better use our horrible source control system). Most of the objections are the familiar "we'll be writing more test code than application code", "how can we test what we haven't written yet", "it takes too long", etc. I think I've finally convinced them of the benefits though, and we're starting to write automated tests! I'm hoping I can now introduce Test Driven Development and convince them to start writing their tests before the code. I came across a podcast last week from Net Objectives that does a much better job of explaining the benefits of Test Driven Development than I ever could. I thought it was great and I hope it's useful to others as well.