James Carr

I took part in DesignFest my first day at OOPSLA, and it was much fun and very interesting seeing all of the subtle dynamics that were at work. One of the major ideas that I gleaned from the experience was this: a good design can only come about from how well the people involved can work together.

On the first day, I attended the day long session, and were given an interesting problem to whip up a design for. Right away I noticed that practically all of us were really not on the same page in how we tackle a problem, and throughout the day we were very disjointed and unfortunately I decided to ind of withdraw and rather than participate much, decided to just observe. Through this, I was really able to observe some of the flaws that lead to bad design.

1. Team Cohesiveness. The most contributing factor to the failure of my teams design is that we had very little cohesiveness. From the start we were in almost complete disagreement, and almost all of us were from radically opposing design concepts. This is the major flaw that broke our design, because how well can we design if we can’t agree?
2. Concern With Pre-optimization. The second factor was that my team was concearned with pre-optimization. When the “customer” came around asking if we had any questions, the first question was “how many ratings can a user enter”, to which the reply was somewhere around 10,000 (a high number aimed to be a pothole no doubt). This led the team to go with a database centric design rather than focusing on the model of the domain problem, and leads to another factor I saw as a contributor to bad design.
3. Database Driven Design. The fact of the matter is that when it came to designing the system, the team began designing the database tables first. This leads to a design that is heavily reliant on the database and that is driven by the database. Rather than Entities with behavior interacting with other entities in the domain, we were instead left with shallow objects that passed around references to database ids and heavily reliant on the underlying implementation. One interesting thing I noticed from this is that when the “customer” returned, developer interaction with the customer contained database related words like “inserting ratings”, “triggers”, etc.
4. Design Contained Too Much Technical Details. This is somewhat related to the previous factor, but also considers the fact that the design contained a lot of technical implementation details up front, which kind of felt “meshed in” with the model without a clear separation of concerns. It’s my belief that if we had began coding the design, we would have seen a system with domain logic in the UI, or UI related details in the model, and database related code seeping through both.
5. Big Batch Design Attempt. Lastly, the user stories (which were included and very nice if I may point out) were largely ignored… rather than tackling one at a time, all of the ideas and technical details behind them were attempted all at once, which made things even more chaotic. Another thing I noticed was that due to the User Stories only being used as hints to requirements, more requirements were actually added by developers, even ideas of a full security subsystem (not really specified).

The result was that we never really got past the first user story and what we did have was a largely chaotic, coupled, and incomplete mess.

The main contributing factor was that we never were able to come to agreement, and near the end there were even a few of us working on separate designs. The fact of the matter is that team interaction, communication, and the focus on people over processes is what can really make or break a project, and it doesn’t matter how good the developers are.

On a final note, I was impressed with the problems given at DesignFest. They were sprinkled with requirements that could be simple or VERY complex depending on how you viewed them, they had an on hand person playing the customer to interact, clarify requirements, and answer questions (but wandering around, and you needed to grab them to come over if you wanted to work with them). Another interesting aspect is that there was a bit of an agile focus, as the customer showed up and added/changed requirements at the last minute, as a test to see how flexible your design was. I was equally happy that they had clear and concise user stories, and if we had followed an iterative model, we could have quickly implemented each story one at a time.

I really wished I had brought my laptop, as I think it would have been interesting to setup fitnesse tests for each of the user stories.

Just got into Portland for OOPSLA last night after a very long flight. My flight stopped over in Pheonix to switch flights, and it turned out that the pilots for the next flight were coming in on a flight that had been delayed, so I had to wait for an hour and a half before heading off to Portland, and finally arrived around 11:30. After a small adventure being lost and trying to find my hotel, I finally found it and passed out for the night.

Anyway, looks like the PLOP bootcamp today was filled up unfortunately, so it looks like the day will be spent going to the convention center at 3pm to select classes, then touring Portland for the rest of the day. I’ll try to post some updates on the sessions at OOPSLA.

Recently I’ve been hard at work hacking up a new plugin for fitnesse to allow for live table editing, using xmlhttprequest to fetch raw pages and persist the data in fitnesse. For the moment, I’ve wanted to stick with pure javascript without writing custom responders or anything, but ran into a small hurdle. I could fetch the raw page content by simply appending “?raw” to the url for the test, but to save it I needed a ticketId and saveId, which were hidden input fields on the edit page. Not knowing any other way to get it, I decided to simply fetch the edit page and select the input values I needed and grab the contents of the textfield for the raw page contents.

And that’s where things got messy.

Since the content is HTML 4.01 and sent as text/html, xhr.responseXml is out of the question. So the choice was to simply load a document from the xhr.responseText string. This was easy in firefox as all I had to do was a simple

var doc = new DOMParser().parseFromString(xhr.responseText, "text/xml");

Which, although a bit of a stretch since it was not really xml, did in fact parse the html document. However, IE’s Microsoft.XMLDOM object wasn’t as forgiving:

var doc = new ActiveXObject("Microsoft.XMLDOM");
doc.async = false;
doc.loadXML(xhr.responseText);

This gave me a document object, but it was empty. After banging my head a bit and reading through specs and msdn, I decided to simply take the responseText and assign it to innerHTML on an element.

var div = document.createElement("div");
div.innerHTML = xhr.responseText;
div.getElementsByTagName("input");
...

Is it dirty? Yes. But does it work? Yes. Although the result is invalid html, the div is discarded after the data needed from the document is retrieved.

Today I received my copy of Implementing Lean Software Development: From Concept to Cash by Mary and Tom Poppendieck, and so far it has been a decent read.

The first chapter is rather interesting as it takes an approach of how we got to agile software development, startling by taking a tour of the evolution of industrial production, beginning in 1785 with Honore Blanc and his weapons that consisted of interchangeable parts, to Henry Ford and his assembly line production that emphasized interchangeable people, and ends with a quick discussion on Toyoda (and Toyota) and the production system developed there, which came to be known as The Toyota Production System.
Read More »