Ruby x Agile: The shift from machine-performance to human-performance

Posted by Sam Aaron on Aug 30, 2007

Community

Agile,

Ruby

Topics

Programming ,

Methodologies

Tags

ROI

This article is the second in the Ruby x Agile series, documenting a set of six short videos exploring the relationship between Ruby and Agile methodologies. Our first article covered why Ruby and Agile are a good combination.

The videos feature a discussion between Ruby creator Yukihiro Matsumoto (Fellow, NaCl), self confessed ‘Agile agitator’ Kenji Hiranabe (CEO, Change Vision, Inc.) and Ruby proponent Shintaroh Kakutani (Service Providing Div. Programmer, Eiwa System Management, Inc.)

This part of the series starts with a discussion of the perceived focus shift from optimising for CPU efficiency, to optimising for programmer efficiency:

“Previously, CPU time was indeed precious but now human time is more precious and the focus has shifted to making human activity easier.”

They discuss the relationship between that as society’s increasing dependence on IT, and the associated programming cost. They conclude that the notion of using human power to save CPU time will become prohibitively expensive, and that the solution isn’t to increase the number of programmers, but to use better tools and practices:

“If we shift focus and work on the human side [of computing], no such number of programmers would be needed. I think that this concept is present in movements such as XP/Agile or Rails.”

“There has been a shift from machine-performance to human-performance.”

However, Matz believes that the only area left today where CPU efficiency should be prioritised is super-computing.

The video concludes with a discussion of the differences between the processes involved with traditional and agile software development. They describe that the traditional workflow iteration consisting of market research and planning, order, deliver, release (illustrated in first figure) takes between a quarter of a year to three years to complete. They believe that if you break the synchronous ordering of these workflow units into smaller asynchronous chunks, (illustrated by the inner loop in the second figure) it is possible to complete a full iteration between 1 week and 3 months.

 

"This turn around takes a quarter to one year or more, perhaps even as much as three years."

 

“When we transfer from this model (first figure), to this model (second figure), then this is Agile itself. The key to this is the synchronisation or match between strength of language, process and business.”

 

When asked to clarify what he meant by the concept of the “inner loop”, Kenji replied with the following deconstruction:

• Agile (as a project) is a collaborative team of business and IT towards the shared goal, which represents “inner”.
• Agile (as a process) is a series of short iterations, which represents the loop.

For more information you can watch the corresponding video in this series. The videos are in Japanese with English subtitles.

• Older >