Category Archives: Half-baked Ideas

Why Process Matters

Posted on by
Reply

I’ve been working on a talk for Smalltalks 2014 about Discovering Alexander’s Properties in Your Code and Life.

I don’t want it to be an esoteric review of Alexander’s properties.

That won’t satisfy my audience or me.

I want to impart information about how Alexander’s physical properties might translate to properties of our software code as well as illustrate poignant personal examples in the physical world.

But equally important, I want impress upon my audience that process is vital to making lively things (software and physical things). In his, The Process of Creating Life: Nature of Order, Book 2, Alexander states,

“Processes play a more fundamental role in determining the life or death of the building than does the ‘design’.”

Traditionally, building architects hand off their designs as a set of formal drawings for others others to build. Does this remind you of waterfall software development? There isn’t anything inherently wrong with constructing formal architectural drawings…but they never end up reflecting accurately what was built. Due to errors in design, situational decisions based on new discoveries made as things are built, better construction techniques, changing requirements, limitations in tools or materials, a building is never exactly constructed as an architect draws it up.

Builders know that. Good ones exercise their judgment as they make on the spot tactical re-design decisions. Architects who are deeply involved in the building process know that.

Alexander is rather unhappy with how buildings are typically created and suggests that any “living” process (whether it be for building design or software or any other complex process) incorporate the following ten characteristics.

He challenges us software makers to do better, too:

“The way forward in the next decades, towards programs with highly adapted human performance, will be through programs which are generated through unfolding, in some fashion comparable to what I have described for buildings.”

As software designers and implementers we know that nothing is ever built exactly as initially conceived. Not even close. Over the past decade or so we have made significant strides our processes and our tools that enable us to be more effective at adaptively and incrementally building software. My thoughts on some ways we have tackled these characteristics are interspersed in italics, below.

Characteristics of Living Processes

1.Step-by-step adaptive. Small increments with opportunity for feedback and correction.
Incremental delivery, retrospectives, stakeholder reviews
Repetitive incremental design cycles:
Design a little– implement–refactor rework refine–design…
Design/test cycles: Write specifications of behavior, write some code that correctly works according to the specification, test and adapt…
Tests and production code equally valued

2. Whatever the greater whole is always the main focus of attention and the driving force.
Working deployable software, minimally-marketable features

3. The entire process is governed and guided by the formation of living centers (that help each other)
Code with defined boundaries, separate responsibilities, and planned for interconnections

4. Steps take place in a specific sequence to control the unfolding.
We have a rhythm to our work. Whether it is test-first or test-frequent development, conversations with customers to define behavioral “specifications”, or other specific actions. In order to control unfolding we need to understand what we need to build, build it, then refine as we go. And we have tools that let us manage and incrementally build and record our changes.

5. Parts created must become locally unique.
Build the next thing so it fits with and expands the wholeness of what we are building. Consider our options. Refactor and rework our design. Make functions/classes/code cohesive. Bust up things that are too big into smaller elements. Revise.

6. The formation of generic centers is guided by patterns.
We have in mind a high-level software architecture that guides our design and implementation.

7. Congruent with feeling and governed by feeling.
Instead of just making a test pass, see if what you just wrote feels right (or if it feels like an ugly hack). Reflect on how and what we are building. Don’t be merely satisfied with making your code work. How do you feel about what you’ve just built? How do those using your software react to it? How do those who have to maintain and live with your code feel about it?

8. For buildings, the formation of structure is guided by the emergence of an aperiodic grid, which brings coherent geometric order
Software is structured, too…we’ve got to be aware of how we are structuring our code.

9.Oriented by a form language that provides concrete methods of implemented adapted structure through simple combinatory rules
We use accepted “schemas” to create coherent software systems. We have software architecture styles, framework support, and even pattern languages emerging…

10. Oriented by the simplicity transformation, and is pruned steadily
We can consistently refactor and rework our code with the goal of simplifying in order to enable building more functionality. We rebuild to create sustainable software structures. Even if we come back to some old working code and see how to simplify it, we can rework it taking into consideration what we’ve learned in the meantime.

Yet, let’s not be complacent. Agile or Lean or Clean Code or Scrum practices don’t address every process characteristic Alexander mentions. I am not sure that all these characteristics are important for building lively software. Alexander is not a builder of software systems, although he spent a lot of time talking with some pioneers and leaders of the software patterns movement.

Some process ideas of Alexander sound expensive and time consuming. Do we always need to reflect on how we feel about what we code? Sometimes we need to build quickly, not painstakingly. We need to prove its worth, and then refine our software. Our main thought may be on just simply making it work, not how it makes us or others feel. So how do we add liveliness to this quickly fashioned software? What’s a good process for that? Mike Feathers wrote about Working Effectively With Legacy Code, but there is a lot more to consider. Maybe that quickly fashioned software has tests, maybe it doesn’t, maybe some parts have a reasonable structure, and maybe other parts should be tossed.

We often build disposable and hopefully short-lived software. Problems crop up when that code gets rudely hacked to extend its capabilities and live past its expiration date.

There are most likely different processes for creating lively software, based on where you start, where you think you are headed, and how lively it needs to be (not everything needs to be fashioned with such care).

People are continually building new and better tools and libraries. There is a rich and growing ecosystem of innovative open source software. Process matters. I think we have a lot still to learn about building lively software. It is a heady time to be building complex software systems.

What Makes for Lively Centers?

Posted on by
Reply

In this blog I dig a bit deeper into what makes good, lively centers.

Let me introduce another property of lively centers: alternating repetition. Consider this photo I took of blooming plum trees in Kyoto.

The photo doesn’t do the scene justice. The flowering trees went on and on and on.

And on.

Forking off the thick trunks were ever thinner arching mossy green and dark branches covered with blossoms. Those blossoms seemed to float between branches forming a sea of pink. I could get lost in those trees.

Looking out over that landscape I felt peaceful, relaxed, and calm.

Earlier, walking the streets of Kyoto I snapped this photo (imagining the sign was inviting me to get with it, “chill out”, be calm and come inside to purchase whatever they were offering).

That sign made me laugh. It contrasts the difference between strong centers that reach out and grab me with the rather flat-affect of everyday more mundane centers. The sign made me curious, but not enough to go inside the shop.

Good alternating repetition doesn’t mean the same thing over and over again. It involves smaller sub-patterns of repeating structures. In preparing for our workshop on Alexander’s properties, I looked for an example of alternating repetition in my personal life. I jog. So it was easy to find alternating repetition in my running routine (Joe Yoder found it in his dancing).

I jog several times a week. I don’t do the same routine everyday. Once a week, typically on Thursdays, I do tempo training with my running coach. She makes me run harder than I’d like to normally do for either a specific distance or time, then has me run easily for a bit to recover. I repeat this hard run-easy jog recovery cycle 3 or 4 times a session. Other days I do my normal easy 3+ mile runs (outside when the weather permits) through town. On the weekends I do a longer run of an hour or more at a comfortable pace. I repeat this cycle each week, with variations due to the running season (winter is slower/less running than summertime) or whether I am recovering from an injury or getting back to running after traveling or recovering from a race.

Another property of strong centers is local symmetry. The photo of these shrines (again, taken in Kyoto) illustrates this.

The shapes of the rooflines, windows, and pedestals are similar, not identical. Slight variations make them more interesting.

Here is the welcoming Port wine and strawberry arrangement that my husband and I found in our Doro valley hotel room in Portugal.

Symmetrical. But berries are closer together on the right hand plate. The napkin folds differ. Perfect symmetry is less pleasing (at least to me) than near symmetry. Alexander claims that a hand-hewn quality strengthens centers (he calls this property “roughness”).

When I discover a strong system of centers I get an emotional kick. And there it is. You discover Alexander’s properties when you engage with the things in your life and form personal connections (rather than letting the scene just float by). Finding Alexander’s properties involves a bit of luck, developing a discriminating eye, and being on the alert for positive connections between what you are experiencing and/or making.

Making strong, lively centers is another matter altogether. Yet how hard can it be? Well…that is a topic for another blog post or two.

Discovering Lively Centers

Posted on by
Reply

Two weeks ago, Joe Yoder and I conducted a workshop on Discovering Alexander’s Properties in Your Life at AsianPLoP, the patterns conference held in Tokyo.

I’m still reeling from the many feelings that were stirred up as I prepared for this workshop. Inspired by the beauty we found in Kyoto, I included several photographs I took of that very beautiful place. Each property was illustrated with some image that resonated strongly resonated with us (whether taken in Kyoto or not, each photo had a strong personal connection).

Before I tell more about the workshop, I want to give a gentle introduction to Christopher Alexander’s ideas on properties of things that have life. Fundamental to Alexander’s ideas is the notion of “centers” arranged in space. According to Alexander, things that have life exhibit one or more of fifteen essential properties, which include, among other things, strong centers and boundaries.

Alexander’s notion of a “center” is simple to grasp—it is a coherent entity that exists in space. Individual centers are important (and they exist at different levels of scale), but more profound is how centers are arranged in space to form a more integral whole. Alexander writes,

“The system of these centers pays a vital role in determining what happens in the world. The system as a whole—that is to say, its pattern— is the thing which we generally think of when we speak about something as a whole. Although the system of centers is fluid, and changes from time to time as the configuration and arrangement and conditions all change. Still, at any given moment, these centers form a definite pattern. This pattern of all the centers appearing in a given part of space—constitutes the wholeness of that part of space. It is this structure, which is responsible for its degree of life.”

Here’s a photo I took in Hawaii for a talk I gave several years ago on the Nature of Order at another patterns conference. It illustrates the notion of a strong center:

I like this photo because it shows that the center of individual orchid flowers are accentuated and strengthened by the brown spots and five petals that form a star shape that surround. Not only is there a “center” to each flower (the stamen surrounding the pistil); there are several “centers” that surround that innermost center.

And here is the photo we showed at our Asian PLoP workshop to illustrate strong centers found on the roof line of an Imperial Palace building in Kyoto:

I leave it to you to find all the centers in this photo. The center cap on the top of the roofline accentuates the gold flower underneath. Underneath that is another circular center. Below that a symmetrical scroll. And there are centers (gold flowers) arranged along the roofline. Centers, when arranged in a pleasing fashion, complement and strengthen each other.

Centers are strengthened by boundaries that surround, enclose, separate, and connect them. Here’s a photo I took in Yellowstone Park of a crusty boundary at the edge of a bubbling hot springs:

The boundary between the hot spring and the land surrounding is fluid and ever changing (witnessed by the salty stains left from evaporation at the water’s edge).

The wood slats wrapped around this tree at the Imperial Palace in Kyoto, protect it from the wooden brace and form a boundary between the tree and the support:

After, explaining and illustrating Alexander’s fifteen properties, we asked attendees to form groups to brainstorm and discuss Alexandrian properties that they found in their own lives. One group focused on Alexandrian properties they found in the Tokyo metro and railway system; another on the properties of bento boxes; and a third on properties in education and learning. I was surprised by the diversity (and how profound some of the examples were, even though at first blush they seemed straightforward and simple).
But that is the topic of my next blog post.

To close this post I want to share two photos that whimsically illustrate “life” my camera eye unexpectedly caught in Kyoto. This first photo is obvious:

The second takes a little bit of searching to find the “owl-like” creature:

Is Kyoto a magical place? I think so. It was amazing to discover human-like or animal-like images in photos of trees. I had no idea that those shapes were there until I looked at my photographs. My eye must have been unconsciously drawn to those shapes (but truly, I didn’t see them until I looked at the photos). Even more startling to me is the liveliness of inanimate things—whether a hand crafted software module or a carefully placed garden pathway—that is more subtle and also profound. When we find strong centers surrounded by other strong centers in designed things, there is a pleasing sense of discovery and wonder.

Sustainable Design

Posted on by
4

In my most recent IEEE Column, Creating Sustainable Designs, I explore what it means to create software that can be maintained without too many growing pains. I have been intrigued by Christopher Alexander’s writings, particularly the first two volumes of the Nature of Order where he explains the properties of designed (or architected) things which have life and processes for creating life.

It is just as important to look at process of creating good software as it is to consider what properties make software habitable for those who have to maintain it and keep it alive. While I appreciate process (and I think the agile community has given us a lot to consider) I am more keenly interested in exploring what makes complex software “living”.

Alexander identifies these properties (or qualities) of living things: levels of scale, strong centers, boundaries, alternating repetition, positive space, good shape, local symmetries, deep interlock and ambiguity, contrast, gradients, roughness, echoes, the void, simplicity and inner calm, and non separateness.

It can be easy picking to draw certain connections between certain “good” software design properties and Alexander’s list. For example, good shape, as others have pointed out can be a matter even as simple as properly indented a method. Or it can be more profound than that–leading you to break up a method into substeps and invoke helper methods, just to keep every step at a similar level of abstraction. I’m only giving you a taste to see whether you are interested in exploring these ideas further.

If you are, read my column, and also take a look at the C++ Report article by Jim Coplien on Space: The Final Frontier, which introduces Alexander’s notion of centers and how they relate to software structure, and peruse several very good blog entries by Regis Medina.

And if you are interested in exploring these ideas further, perhaps by taking a deep look into working code or frameworks or software that you consider to be particularly alive (or not)… let me know. I am considering finding a venue where software developers and designers and philosophers could concretely explore Alexander’s properties more thoroughly. I am not just satisfied to make those simple, easy connections and call it good. I want to challenge our best designs and see whether Alexander’s properties really do apply (or if we have some other properties that are more relevant).

It’s official…specs are “bad”

Posted on by
Reply

…according to Linus Torvalds. I have to chime in on Linus’ newsgroup posting and the attendent buzz it sparked on the net this week (and on the Linux Kernel mailing list). Linus stated:

So there’s two MAJOR reasons to avoid specs:
– they’re dangerously wrong. Reality is different, and anybody who thinks specs matter over reality should get out of kernel programming NOW. When reality and specs clash, the spec has zero meaning. Zilch. Nada. None.
It’s like real science: if you have a theory that doesn’t match experiments, it doesn’t matter _how_ much you like that theory. It’s wrong. You can use it as an approximation, but you MUST keep in mind that it’s an approximation.
Specs have an inevitably tendency to try to introduce abstractions levels and wording and documentation policies that make sense for a written spec. Trying to implement actual code off the spec leads to the code looking and working like CRAP.

He went on to conclude:

“But the spec says …” is pretty much always a sign of somebody who has just blocked out the fact that some device doesn’t. So don’t talk about specs. Talk about working code that is _readable_ and _works_. There’s an absolutely mindbogglingly huge difference between the two.

This posting launched an onslaught of discussion. Linus is right. Reality always differs from a specification of how software is supposed to behave. That’s a reflection on how difficult it is to write precise specifications of behavior and on how many decisions during implementation are left open. Still, I’m not willing to say “no specs, ever” even though I’m a signer of the Agile Manifesto and on the board of the Agile Alliance. We need to get better at recognizing what types of descriptions do add value and under what circumstances. And become more aware of when and where precision is needed (and when it drags us down).

Linus points out that specs often introduce abstractions and concepts that shouldn’t be directly implemented in code. I never expect to directly translate what someone writes into code without using my brain. I design and think before and during and after coding realizing that nothing substitutes for testing/proving out a design and implementation against the real environment it works in.

But that doesn’t mean specs have no value. Working, readable code isn’t the only thing that matters. It matters very much in the short and long term. But try understanding design rationale by just reading code. Or reading the test code. It’s difficult, if not impossible. I find value in design documentation that explains the tricky bits. This type of documentation is especially valuable when those coding aren’t going to hang around to offer explanations.

A spec is an approximation of what is desired. I certainly don’t expect it to tell me everything. There can be enormous value in writing descriptions of what software should do, especially when it is important to communicate design parameters and system behaviors instead of just providing an implementation. Most developers aren’t good at writing specs, let alone descriptions/discussions about their code and design choices. But that doesn’t mean they should stop writing them and resort to “organic code growth” in every situation. A firm believer in agile practices, I do’t insist in writing merely for fun or because it is expected. But if I need a spec, I write it. And if doesn’t reflect reality or is misunderstood, I change it if there is value in keeping it up to date. There may not be. And if that’s the case, I don’t update it. It depends on the project and the need. It helps if I write these descriptions for someone who wants to read them (and will actually use it rather than toss it aside). I’ve got to know my audience. That often takes experimentation. Maybe I need to include sample prototype code in addition to design notes/models/sketches. Maybe I don’t. Communicating ideas to a diverse audience is especially hard. But specs aren’t the problem. It’s that effectively communicating how something works or should work is more difficult than cutting code. I prefer working code over piles of outdated, difficult diagrams and explanations. But that doesn’t duck the issue. Specs aren’t inherently bad. Most spec writers would rather be doing something else. And that is a problem.