part of the balancing act in agile is understanding the timing of when a decision must be made, and its impact on the project’s success.

a discussion came up in the Agile Usability forum… it had to do with the UEX team wanting to ensure understanding of 3 content templates ahead of time (for a content-rich web site project), and the dev team advocating for a “just in time” approach.

my suggestion… if it is costly to decide on the content templates late in the game, explain it to the dev folks.

or conversely, have the dev folks explain how the template choice has no impact on the timing of dev and cost.

bottom line, talk! have people prove to each other one way or the other…

sometimes, we “architects” can design systems in such a way as to squeeze formerly “costly” aspects of a traditional system/approach into trivial aspects. sometimes.

In a post on agile usability forum, William Pietri wrote about outsourced team challenges.

“Having helped shepherd one offshore project onto an agile path, I now merely think it’s much, much harder and a fair bit less effective than getting everybody in the same room.”

You have to qualify “being in the same room is more effective” — there are lots of assumptions going on in that statement

Though I know what William meant, here are some points to consider:

• being in the same room and in a culture that does not value communicative development techniques has little benefit. except, it probably slows the project down due to chit chat
• being further apart can have the unintended consequence of engendering greater degrees of communication — because you have to.
• being further apart can lead to beneficial practices such as:
  • teams designing to interfaces,
  • following more general architectural visions,
  • following the pattern of a thin slice of working code,
  • making more of an effort to keep the team communicating daily across continents,
  • etc.

With a discussion on Agile Modeling forum about organizations seeming to have issues with properly applying agile ideas, I proposed the following:

agile is:

• more a state of mind, than a set of steps
• a technique designed to reduce the gap in time between doing something

  on the project and seeing the result

• a way to better shepherd your resources to meet your goals
• a philosophy that requires more — not less — use of gray matter at

  every step of the way

agile modeling, agile processes, agile coding… they all fit in there

somewhere

here is a *null* hypothesis. let’s see if we can disprove it:

“agile requires being smarter than average. therefore, agile only

succeeds in projects that have people that are smarter and more

experienced than the average developer/business. ”

Not sure what to dub this… But here’s the situation. I have been doing some EJB/JSP/JSTL coding. Partly looking at some existing source and refactoring, and designing and coding a better mousetrap myself.

One chunk of source code was full of code in triplicate (including repeating all of the fields in multiple JSPs), or code that was 99% the same as a base class/action. Mind you, this code is for handling displaying, editing, and creating new objects for a 50+ class model. If it were for one or two classes, I almost could care less how it was written.

Maybe I am old school. Maybe it is from years of C++ and early Java. Maybe I am lazy. I don’t know. But to me, I look to eliminate these design smells and reduce repetitive code. It is also a factor in making the code easier to understand and maintain down the road. I scratch my head wondering why the developer thought that this was the easiest and best solution. I would beat myself with a stick if, as I got into implementing a design of mine, it turned out to be a nightmare. I’d go back and try to improve it. A matter of pride? Not at all. A matter of trying to do it more efficiently (or call me lazy).

While refactoring is a way to catch this, it is also a matter of when to refactor. Doing it after 50 things are already triplicated is much more difficult (and budget busting) than catching it early on in the design and testing phase.

This work was done in a distributed team. Name of the game here — if the developer had no pair — is to have a point in the process where the code design is reviewed. Another pair of eyes might have spotted this early on.

On the Straight-Talking Java forum, Miles Parker mentioned helping friends with “computer” issues.

I rarely dread calls more than from not-so-tech-savvy friends and family. Not because I don’t want to help, on the contrary. But more because of the myriad ways that Windows and Windows apps can become spectacularly fouled up down in the bowels of the machine.

Sometimes the issue is trying to figure out what happened that caused their entire year of their small business financials to disappear. Coincidentally after Windows did an auto-update — and I suspect auto re-boot during a long-running backup process. (BTW: data was lost.)

Or how my own out-facing network address made it to the spam blocker list which in turn caused my own outbound email to sporadically fail with strange messages! Thanks girls… glad you found those wonderful trojan viruses that were spamming from one of your machines! I made the firewall and virus protection tighter.

Now on to migrate over a desktop PC to an iMac — xfer email address book, personal files, etc. Should be loads of fun. After all, I just made a first pass at exporting Address Book from Outlook and it said the Export feature was not installed. Yikes, I’ll have to break out the original install disks.

I’ll let you know how it goes!

So, what might you have eaten for lunch? How about during college? Or late-night coding sessions? I still eat Ramen noodles!

Momofuku Ando ring a bell? Didn’t with me either. How about “Ramen Noodles?”

At the age of 96, Momofuku died this past Friday (6 Jan 07). And to think, the day before he had Chicken Ramen for lunch with Nissin employees!

So, next time you grab that 3-minute meal while you are waiting for a compile or contemplating that next great solution, say a short prayer of thanks to Momofuku and send best wishes to his family.

Three passes at building as simple of a system as we could to allow for a dynamic JSP based on a 2-dimensional menu matrix… Tabs across the top, selecting one and you get various left nav tabs. Select a left nav and you get a list of those objects and the data for the first one in the list. The idea was to maintain the menu system in a database table to allow ease of change. First implementation was very bulky and expensive — too many files!

Many late nights… 103 deg fever for Lee. After second failed attempt, Lee says “I’m out of ideas.”

That scared me… Lee out of ideas? He’s one of the best we have! He’s one of “our guys.” You know the kind. Ask him anything, and he can offer help or a solution or just get it done!

I kept trying to bring the solution back to simplesville. So the next morning I set out with pen and paper and went back to the drawing board. We have a two-pronged object model, with a 1..* between the two top core objects. Then simply other “stuff” hanging off of those root objects via associations. The menu system is merely a way to ease the navigation through the various parts of the system.

Turns out Lee was also mulling it over during the day. At about 4 o’clock, we chatted on the phone. “You go first,” he said. So I explained my approach. We were on the same wavelength. At about 8 o’clock, we meet in IRC chat a bit. I go off to do some other parts of the app, Lee starts in on the ideas we had discussed.

A few hours later, he’s got it working! One small slice, mind you… But Lee cracked the puzzle! We’re using older EJB and struts 1.0, so we were not able to iterate over the bean to automate the JSPs.

Got it down to a pattern for {1 EJB, 1 form bean, one JSP, and one action} per class. And all CRUD functionality is possible.

Third time’s a charm, as they say (whoever they are — let me know if you know).