daily weblogs

books

reference

java study group

web design

webinfo (links)

about

adventure

recipes

photos

about us

Meeting again for the first time this year, the powerful Java Study Group delved into chapter 2 of Alistair Cockburn's Agile Software Development: "Individuals". Everyone liked this chapter a lot, since it deals with the human aspect of software engineering, and has a lot of fun stories which clearly illustrate important truths.

We didn't bring study questions to the meeting as we usually do, but here's a good one: how do you detect the presence of concrete thinking in your developer group? (answer below).

The chapter 2 of Agile Software Development buy at amazon.comcovers a huge amount of territory, a wide range of human strengths and weaknesses.

There are also new terms of art and practice.

I particularly liked Cockburn's notion of "informance", which is a low-production-value simulated performance of your application, done in a way to give you information about how well it might work in reality. You might draw a picture of a computer screen, and have someone "play the role" of the computer as users tried to test it.

In addition, it was valuable to know when to undertake the most difficult task in a software project, organized according to Agile Programming principles. (Do the hardest thing first: projects that leave it until last often fail.)

A critical time period in most projects emerged from the discussion. The duration of the critical time period was variously described as three months, 12 weeks, one quarter-year, or 90 days. The name of this critical time period: Time to Project Completion.

Of the four time-period descriptions, only 12-week projects are completed on time. 90-day projects are a year late, three-month projects are cancelled early, and no one had any examples of quarter-year projects. We laughed a lot about this as a joking matter, but perhaps there is some truth in it.

Here's the answer to the study question posed above. One way you can detect concrete thinking in your group is to see if there is a plethora of modelled users. That is, in order to elucidate the "information architecture" of the application for the developers, has the team invented typical users and given them roles: The power user, the prototypical man-in-a-hurry. Another book, Christina Wodtke's Information Architecturebuy at amazon.com gives a completely worked-out example of how to use this type of concrete thinking to improve the information architecture of a website. ="JavaScript">