Loosely Coupled

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...

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.

I started this podcast project so I could learn some things I haven't had time to experiment with in my "real" job. Things like playing more with Ruby, trying out Behavior-Driven Development, and experimenting with Agile practices (plus I really wanted a better podcatcher program and I needed something to do over the winter). While I haven't produced much real code yet, I've created some simple prototypes and wanted to comment on some things I've been looking at. Reading an RSS feed My first prototype was a very simple Ruby program to read and parse an RSS feed. I had found some code here using the standard Ruby RSS Parser so that's where I started. At first I thought it was broken, but after about a minute and a half it returned. This wasn't going to cut it, so I started to look for alternatives and quickly found the feed-normalizer gem. Some quick coding and the total time to access the RSS feed was reduced to about 10 seconds. Not bad...

I've made embarrassingly little progress on my podcatcher so far. My plan was to entirely read Lean Software Development before getting started, but it's taking me a while to get through the book - in a good way. I seldom read more than 5 or 7 pages before I find myself reflecting on current or past projects. This knowledge could've saved me time on previous work by making the most important & well defined features a priority - delaying discussion and decisions on the "nice to have" features until later. Some of these ideas I've stumbled on by accident or heard about from others, but it's great to have them validated and expanded into this set of lean thinking tools. I'm sure this is a book I'll reread many times in the coming years. Anyway, I want to revisit my requirements list for the podcatcher, prioritize the features, and define the features for my first sprint. Here are the requirements for the podcatcher from a previous post, ro...

Making resolutions is tradition on New Year's Eve.... evaluate areas you'd like to improve (or new skills you'd like to acquire), and set goals to improve in those areas. Here are two work-related resolutions I'm going to focus on entering 2008. Make JCAPS Usable If you've been following my posts, you're aware that I've been frustrated with Sun's JCAPS product. The tool is simply not ready for prime time and it's hurting my productivity. In addition to the problems I've already outlined , developing in JCAPS' eDesigner makes me "feel dirty". You need to go outside to tool to create modules of shared code (jars). This limitation makes it hard to implement classes that follow even the simplest design patterns or integrate with third party frameworks, like Spring . I feel myself falling into bad coding habits. I'd like to find a compromise. What I'd like to do, is move my code out of the JCAPS JCD and into a sep...

If you haven't seen some of the Rails vs. _____ (Java, ColdFusion, .Net) links, I made available in the " Related Articles " section, you should check them out. They're really clever. The guys over at RailsEnvy do a great job with these. They've also released a presentation about testing , introducing me to Behavior Driven Development which is like Test Driven Development , but with purpose. Instead of testing individual functions, Behavior Driven Development tests specific user actions and the result of these actions. The result of creating these behavior driven tests is a specification for how your application will perform... with a final application behaving in this manner after all tests pass. For Ruby, there is a framework called RSpec which can help facilitate this process. For a while I've wanted to adopt a more test driven approach to my development. There are a lot of benefits: you only build what you need (don't overbuild), you know ...