C. Keith Ray

C. Keith Ray is developing software for Sizeography and Upstart Technology. He writes code for multiple platforms and languages, including iOS® and Macintosh®.
Go to Sizeography and Upstart Technology to join our mailing lists and see more about our products. Keith's Résumé (pdf)

Thursday, August 21, 2008

SF Reading material for you and your iPhone

Jeffrey Carver has made the book Neptune Crossing, available for download. The HTML version appears to be quite readable on my iPhone when rotated for a horizontal aspect ratio.

Cory Doctorow has made several of his books available for download, the best being Little Brother. He is finding that free online releases of his books are enhancing the sales of his paper editions, rather than reducing sales.

Other authors are finding the same thing. Old out-of-print books made available for download can revive an author's readership, while new books simultaneously released on the web and in paper can generate more buzz than just the paper edition will.

A little bit more about Little Brother:  one of the blurbs sums it up well: 
Little Brother is a scarily realistic adventure about how homeland security technology could be abused to wrongfully imprison innocent Americans. A teenage hacker-turned-hero pits himself against the government to fight for his basic freedoms. This book is action-packed with tales of courage, technology, and demonstrations of digital disobedience as the technophile's civil protest.
Andrew "bunnie" Huang, author of Hacking the Xbox
Check it out.

Tuesday, August 19, 2008

Can someone do a meta-study on agile adoption

Get conference proceedings from Agile2008 and earlier. Check out all the experience reports and other papers about agile adoption. What do the success reports have in common? What do the failure reports have in common? What is a typical timeline for success for transforming a project team, a division, a company?

Friday, August 15, 2008

Clean Code

Clean Code (also known as "Simple Code" as defined by Kent Beck) is (paraphrased):
  • Correct: it passes all its tests and its tests are thorough (but not redundant) and correct.

  • Does not contain duplication: Duplicate logic is eliminated and localized in a few places – this may require using functional or object oriented concepts and design patterns. Duplicate data is minimized. Duplicate syntax is also minimized. No redundency.

  • Expresses its concepts: by using good class names, methods names, and other identifiers. Dependencies are expressed in interfaces. Methods and classes are short, readable, and have a single responsibility.

  • Contains no superfluous parts: it does not have dead code, unnecessary parameters, etc. No code left over from features that have been removed. No code for features that haven't been scheduled for implementation.
I find that more explanation is often needed, since some programmers will, for example, point at "expresses its concepts" by saying: this huge function in this huge class perfectly expresses the two dozen actions it performs.

Saturday, August 9, 2008

How I Learned...

richard durnall
 points to an article "How I Learned to Let My Workers Lead" by Ralph Stayer. Richard notes 
There is a deeper, less tangible philosophy embeded within Lean that focuses on people, the systems we place them in and the behaviours these systems encourage. [...]
The Stayer article explains the leap of faith we have to take as leaders to create new systems where the people can determine the process.
In Lean Ops we missed this deeper philosophy. We focussed on the tools and when they didn’t work we just tried harder to enforce the application of the tools. The irony! [...]"
This correlates with several lessons that I am still learning to embody within myself and organizations I interact with. 

An observation: The most well-known success story of "Lean", Toyota, shows that the corporate culture is more important than the practices. Attempts to imitate the practices without the culture of true empowerment have failed. And from what I've heard, many of their specific practices change over the course of time.

A few choice quotes from Ralph Stayer's article: 
If I was going to fix what I had made, I would have to start by fixing myself.
Of course, fixing himself and his company (which, since he was the founder, was a reflection of himself) was a long and circuitous course... The "end state" he envisioned for his company was:
[...] a flock of geese on the wing. I didn't want an organizational chart with traditional lines and boxes, but a "V" of individuals who knew the common goal, took turns leading, and adjusted their structure to the task at hand. [...] Most important, each individual bird is responsible for its own performance.
Note the difference from his "end state" and how he attempted to get there:
I spent those two years pursuing another mirage as well -- detailed strategic and tactical plans [...] We tried-to plan organizational structure two to three years before it would be needed -- who would be responsible for what and who would report to whom, all care fully diagramed in boxes and lines on charts. Later I realized that these structural changes had to grow from day-to-day working realities; no one could dictate them from above, and certainly not in advance.
Now that is one of the lessons I learned when I attended Jerry Weinberg's PSL and participated in the experiential simulations he designed. Everyone who attends tends to learn different lessons -- often, the lessons they most need to learn. Jerry creates an environment that enables us to observe problems, without him having to didactically explain what's going on. He was teaching this before "Agile" or "Lean" became buzzwords in the software development community.

Trying to assign decision-making (or not) responsibilities and define a team structure before beginning a project is a something like buying equipment and organizing a team for to play softball, without knowing that the sport you're actually going to be playing is basketball.

[...] The early 1980s taught me that I couldn't give responsibility. People had to expect it, want it, even demand it. So my end state needed redefining. The goal was not so much a state of shared responsibility as an environment where people insist on being responsible.

To bring people to that new Point B, I had to learn to be a better coach. It took me additional years to learn the art of coaching, by which, in a nutshell, I mean communicating a vision and then getting people to see their own behavior, harness their own frustrations, and own their own problems.
Coaching is an art I'm still working on. As an Agile coach, I can model the behavior I'd like to see in others, observe, communicate, offer feedback, ask for feedback, and sometimes give advice. It turns out that managers (even CEOs) have little more power than a coach does:
The debacle of ordering change and watching it fail to occur showed me my limitations. I had come to realize that I didn't directly control the performance of the people at Johnsonville, that as a manager I didn't really manage people. They managed themselves.[...]
Stayer describes how top management had the responsibility of checking the quality of the product (tasting the sausage) and he made the change that the workers who are responsible for creating the product would become responsible for checking quality, with the expectation that quality would remain high. 

The employees self-organized taking ownership for quality and defects, and to remedy the defects. This led to better quality and employees asked for more information and more responsibility including changing training, HR, and salary structures: paying for people taking on more responsibilities rather than simply job tenure. 
Check it out.

Friday, August 8, 2008

Friday, August 1, 2008

Industrial Logic at Agile 2008

My Industrial Logic colleagues will be out in force at the Agile 2008 conference.

In order of appearance...

Tuesday
  • Brian Foote: "Agility, Evolution, Emergence, And The Primordial Ooze"
  • Mike Hill: "Throwing the Agile Transition Party"
  • Brian Foote: "Big Ball of Mud"
  • Joshua Kerievsky : "Ten Terrific Transition Tips"
  • John Tangney: "Mastering Selenium"
Wednesday
  • Mike Hill: "Clean Code Clinic: Dealing with CRRAP - Microtesting Legacy Code"
  • Joshua Kerievsky, Gil Broza: "Crafting User Stories – Four Experts And The Audience Weigh In"
  • Joshua Kerievsky: "Refactoring Strategies & Tactics"
  • Gil Broza: "Agile Clinic - Bring Your Toughest Challenges"
Thursday
  • Gil Broza: "The Secrets of High-Performance Agile Implementations"
  • Keith Ray, Gil Broza: "Refactoring for Testable C++"
  • Brian Foote: "Patterns Poster Children"
  • Joshua Kerievsky: "Estimating Considered Wasteful: Introducing Micro-Releases"

Tuesday - Friday
  • Joshua Kerievsky, Mike Hill: "Programming with the Stars"