13 November 2007

ANN: Agile Ottawa Event with Mike Milinkovich

The Agile Ottawa group is pleased to announce a special meeting featuring Mike Milinkovich, the Executive Director of the Eclipse Foundation.

When: Wednesday, December 5th at 7:00 PM

Where: The "Theater" at BitHeads, 1309 Carling Ave. (Westgate Mall),
at the entrance on the East side of the building

What: "How Eclipse Does It"

Abstract: The Eclipse community has a truly enviable track record of shipping high-quality software releases on schedule. For the past five years, the Eclipse open source community has hit its release dates. And it does this in an environment that involves contributions from many different organizations from around the world. How does Eclipse do it?

If you or your organization deals with large-scale and/or distributed development and still want to be agile, this talk is for you! Please spread the word around to anyone you feel would be interested.

The venue has seating for approximately 80 people, but please RSVP to me anyway so that we have an idea of the number of attendees to expect.

See you then!

7 November 2007

Simple Design Illustrated

I've been asked quite a number of times about the agile principle of Simplicity and the associated XP practice of Simple Design in XP. People ask, "What is simple?" I suppose it's all quite subjective and relative and contextual. This week, however, I endured a rather stark lesson about simplicity myself! I've been at this software development gig for 20 years professionally now, and I'm pretty good at it. I've learned quite a bit about relational and object modeling over the years, and I leveraged my knowledge and experience when designing the persistence mechanism for a system on which I'm working.

Initially, I did the simplest thing that could possibly work, and simply wrote and read serialized Java classes to and from disk. This worked fine, but the Customer for the system needs to be able to track relatively detailed metrics about the system's usage, which was difficult at best with the "simple" solution.

So, I thought, we're going to need to persist this information to a database!! Suddenly, simple serialized Java classes became Hibernate configuration Hell between two independent classes with a many-to-many relationship. I figured that I was just scaling more of the ORM learning cliff when I simply couldn't get the association to work - it was griping about duplicate keys in an association table. After a couple of days of assuming it was my fault, I discovered that there was a bug in Hibernate that created a unique key where it had no business creating one. Removing that key made everything work... at least in my tests.

Ah yes, the differences between tests and the real, integrated application. The bar may have been green, but the application would still barf at times with issues about the Hibernate session having more than one instance... blah... blah... blah... I'll skip the rest of the gory details. In the end, I had spent about 2 calendar weeks working part-time on implementing this solution, and it still wasn't working. I was (and still am) frustrated, and kept saying to myself that it just shouldn't be that difficult.

In the shower yesterday morning, feeling rather defeated, I stepped back (figuratively - it's a small shower stall!) from the situation and asked myself what the Customer really needed. They needed to track activity and run reports. I thought about what activities were to be tracked, and realized that it all fit very nicely into a single table.

I finished up in the shower, and 1.5 hours later had the single-table-based solution working, tests included. It still has serialized Java classes for some data, although those will likely become XML-based quite soon (using XStream, which appears to be very simple!).

So, I had spent about 20 hours trying to implement the "standard" solution, and it never worked properly. I spent 1.5 hours on a much, much simpler solution that does everything that the Customer requires, and it's in production as of 9:30 PM tonight.

In a nutshell, my 20 years of experience using traditional techniques and assumptions came back to bite me on the backside. And that, my friends, is tonight's lesson in Simplicity and Simple Design. I just wish I had learned it a couple of weeks earlier!

5 November 2007

The Perils of Working at Home (...or No Good Deed Goes Unpunished!)

I'm working at home today. Yes, I'm really working. I like working here - it's a quiet or loud as I want, I don't have to shave, and I can wear sweatpants all day if I like!

An added benefit is that I can get a few things done during "down time", which would be those moments of chit-chat if I were in the office. Today, for example, I decided to do some laundry. I tossed in a load right before a 1:00 PM conference call, and by the time the call was done so was the washer. Great, I thought, I'll quickly fold what's in the dryer and throw in the load from the washer.

Not so fast!

When I entered the laundry room, I discovered that the laundry tub was quite full of water that had drained from the washer. Um, that's not supposed to happen! Normally, the water happily re-enters the hydrological cycle without any intervention on my part. Except today. When I'm working at home.

So, a good 40 minutes was lost finding the drain snake, snaking the drain, pulling up unspeakable filth and finally clearing the drain.

So, please feel free to choose a moral for this story:

1) Don't work at home!

2) When working at home, don't bother with household tasks.

3) Remind your significant other that hay and shavings from the rabbit's cage shouldn't be washed down the drain in the laundry room.

4) Any combination of (3) and the other options.

I think I'll empty the dishwasher now... :)

30 October 2007

The Engineering in "Software Engineering"

A recent thread in the Agile Modeling Yahoo Group has reminded me of the misconceptions surrounding Software Engineering. Let me make this clear, and I'll say it slowly and out loud for those of you at the back:


Did you hear that? Want me to repeat it?

Ron Jeffries, in response to Jeff Langr, wrote,

Otherwise, they prefer lots of small iterations of the scientific method. Do you think there are similarities between that and TDD?

I do think that. When people think "engineering" they mostly turn their thoughts to construction, and use the analogy to decide how to "construct" software. That is almost completely incorrect. Software creation is mostly design, not construction. And engineering //design// is highly iterative in nature. It goes from sketch to
sketch ... on and on. The diagrams get more and more precise, but most of that is because the real thing is hard to build, and because the design has to be communicated to some other batch of people who will be largely clueless. The analogy does not hold in most software development, perhaps almost none.

I agree wholeheartedly with Ron - when you're building software, you're designing it. It is NOT the construction phase.

In the aviation industry, the term "design iteration" is used very frequently to describe the process of creating a new aircraft. That process is driven by feedback from many factors involved for a given aircraft, for example aerodynamic efficiency or "saleability" of a commercial aircraft. You can design a very efficient aircraft, but if no one wants to buy it you're hosed (i.e. Boeing's Sonic Cruiser!). The ability to design entire aircraft on silicon rather than paper has allowed engineers to perform vastly more iterations than before, allowing more elaborate designs than was previously possible..

This process equates very much to how we build software using an agile process. We start with a business problem to be solved and factor in the constraints from the problem domain, software and hardware infrastructure, and whether the software built is acceptable to the Customer. Improvements in hardware and our software tools have allowed us to make substantial changes to systems very quickly in order integrate feedback.

Once aluminum is cut or composites are in the autoclave, it becomes very expensive to refactor an aircraft. If a design flaw is caught early in the static or flight testing process, it's expensive to fix, but less expensive than fixing an entire fleet of production aircraft. An example here is the Boeing 777, which experienced a serious aerodynamic flutter of the nose landing gear door on the first test flight. Some redesign was necessary to strengthen the door (which had been optimized to save weight), and the updated design was incorporated into the aircraft already on the production line and all subsequent aircraft.

In software, once a system is shipped it becomes much more expensive to incorporate design changes. For example, a desktop application with thousands of installations costs a lot of money to patch. A buggy application in a cell phone is another example.

Again, the notion of "construction" in software is when the physical application is distributed, not in the creation of the software itself. That's the design process.

20 June 2007

Fun with Eclipse RCP

Lately I've been working with the Eclipse Rich Client Platform (RCP) on a small pilot project to replace an existing Java Swing UI for a current client. There certainly is an initial learning cliff, but now that I'm starting to grok the whole platform I'm more impressed every day at RCP's elegance.

Yesterday, Wayne Beaton from the Eclipse Foundation came and spoke to the team (one of the benefits of living in Ottawa!). It was a great talk and filled in the gaps in my knowledge of the Eclipse platform. Wayne was also able to provide some of the history behind RCP, and one of the key points was that the platform evolved out of the tool, and not the other way around. There's a lesson to be learned there!

At any rate, one of the key points I took away from the talk was just how modular applications are when using the Eclipse model and OSGi framework. I'm reasonably good at separating concerns within an application's architecture, but I can't hold a candle to what the contributors to Eclipse do! I can see how that would provide the ultimate in flexibility and a way to constantly add/update/replace functionality over time without necessarily replacing the entire application. This is very, very interesting in environments where there is a significant cost incurred by pushing a monolithic application to production. If you can update incrementally, you may spend more over a long period of time, however each individual update costs considerably less and has less impact on the users.

So, all in all after working with RCP for the past few weeks I'm quite impressed and two of us have been able to become quite productive with it in a relatively short time period.

10 April 2007


On April 2nd, the submission system for the Agile 2007 Conference sent out the acceptance and rejection notices to those who submitted proposals for conference sessions. Initially, some people received over 200 e-mail messages containing notifications for submitters other than themselves. Later in the day, the problem was identified and corrected. While this would seem like an embarrassing hiccup in most cases, this problem occurred in the software used by a conference promoting agile methods - methods that emphasize software quality!

Joshua Kerievsky called out the conference organizers about the level of testing of the submission software, which ruffled some feathers.

I have to agree with Joshua. We talk the talk about how software built using agile methods is of much, much higher quality, but then the Agile 2007 organizers farm out the development of the submission system to a group that, according to Ron Jeffries, didn't use agile at all. The debate then became centered around whether the debate was appropriate for the XP Yahoo group or not, even involving the moderators.

Well, I'm sorry, but I believe it was very appropriate. We can't just pick and choose when we should be agile. Like it or not, the organizers of a conference espousing agile methods have to hold themselves to a higher standard. Anything less diminishes their ability to talk about the benefits of agile development, and damages the credibility of all of us that do.

For my part, while I can't participate in the organization of next year's conference, I have volunteered to work on the submission system. I have written e-mail distribution code before... with tests. If there are problems with that system, I fully expect to be called out for them.

That's called accountability, which is what we've been saying for years is another aspect of development that's emphasized by XP.

23 March 2007

Transitions - Epilogue

Last August in Transitions, I spoke of leaving the consulting world to work with Industrial Logic of Berkeley, California. After over 6 months of working with some of the best people in the business, I have had to 'come back' to Mayford Technologies for family reasons.

I have nothing but admiration for Joshua Kerievsky and the other great people at IL, and I wish I could have continued to work with them.