I have been reading the Cutter IT Journal from March 2003, when they ran a special issue on Critical Chain Project Management. I wanted to share this especially salient point. I don’t know how to help my clients understand this, particularly because my clients usually find themselves behind the eight-ball and in desperate need of this advice.

If we are serious about speed, we must understand what is required for people to “go faster.” We are not asking them to work faster! We are asking them to wait, to rest, and then work at full speed. And then rest again. Our strategy is to remove all the obstacles that cause them delay and to recognize that relay runners don’t run at full speed all day. They are not “fully utilized” because full utilization of resources is inefficient for speed. For our people to do tasks faster, we must reduce their workload and lower their utilization. This is not a sacrifice for the organization, it is the means for substantially greater project throughput. For our people to do tasks faster, we must reduce their workload and lower their utilization.

How do I help them understand? Click the Discuss link to give me your suggestions.

Discuss

I would like to announce the release of Amr Elssamadisy’s book Agile Adoption Patterns on Safari at O’Reilly. Amr invited me to write a foreword, but even if he hadn’t, I would heartily endorse his book.

Discuss

Friends, I have been carefully constructing a rather complex travel itinerary for August and September, and one of my prospective clients has gone rather dark on me. As a result, I have ten days of time available that I would like to offer to you at cost. You read that correctly: you can hire me to help your organization between September 1 and September 10 at the unusually low rate of covering reasonable travel costs for Sarah and me. As you might expect, some conditions apply.

• I will be in Amsterdam, Netherlands on August 31 and I need to fly to Chicago, USA on September 11, so you could hire me in the period in between for up to 9 days, as I’d prefer to have Monday as slack in our travel schedule.

• I would like to work out a fixed travel budget for our travel expenses, rather than submit receipts.

• We don’t need a fancy hotel, but prefer someplace with a kitchenette so we can prepare our own meals in the room.

• We need to eat well, so we prefer a hotel near a local market or good-quality grocery store with fresh produce that is either less than a 15-minute walk or easy to reach with public transport.

• I want fun work, which means a multi-disciplinary opportunity, including all aspects of your software delivery system, from the boardroom to the bullpen.

• If prospective client gets back to me by Friday and wants me during this time, then I need to give them priority.

If this interests you, please send email right now to the address in the top-left corner of the page with the subject “Crazy Joe’s September 2008 Consulting Special” or something like that, and I’ll get back to you.

Discuss

Proceed at your own risk.

Discuss

I recently read Jeff Patton’s column at StickyMinds. His latest article tells us the secret to automated acceptance tests. I responded, and I include that response here.

I like this article, Jeff, but I’d like to point out that programmers can automate more tests in advance without risking a ripple effect when a customer wants to move a field around.

We know that many designs exhibit high coupling between “the UI” and “the logic”, and teasing that coupling apart—mostly moving (business) logic out of the UI—is one step towards more flexibility, less ripple effect and more valuable automated end-to-end tests. We have all seen it. I invite programmers to take one more step.

Inside “the UI” I find two major kinds of code: UI toolkit client code and more general toolkit-neutral code. When I format a monetary amount as ”$12.50”, I can make that decision without involving the UI toolkit; but when I decide to display the text ”$12.50” as a label or in a text field, I need to involve the UI toolkit in that decision. I invite programmers to separate their UI into presentation logic (UI toolkit neutral) and rendering logic (UI toolkit specific). If you do this, you will have an “abstract UI” or “presentation layer” you can test without drawing a real UI. These tests run quickly because they run in memory without having to paint a screen or invoke a UI toolkit component of any kind. You don’t need end-to-end tests here. When someone decides to move a field around, none of your presentation layer tests need to change, and you avoid the ripple effect. Yes, your end-to-end tests change, but over time you’ll automate fewer of those, preferring instead to automate the presentation layer tests.

So programmers, do your worst! Introduce a true presentation layer into your design, starting with the next screen or page. You’ll thank yourself, and maybe me.

Discuss