Tag Archives: software development processes

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.

The World’s Smallest Software Development Quiz

Posted on by
Reply

A couple of weeks ago a friend sent me a link to the World’s Smallest Political Quiz.
If you answer 10 questions on personal and economic issues (with possible answers being yes, no, and maybe), you’ll get rated on whether you are a Liberal, Centrist, Conservative, Libertarian, or Statist. I passed the link out to a few friends and family members and said I’d report my test score if they’d tell me theirs. Needless to say it was interesting. I’m married to a libertarian, have a centrist brother, and have raised two liberals. When I take the test (depending on my mood I answer questions differently) I’m either a liberal or a centrist. I lean towards supporting significant personal liberties but believe in the value of some “governmental controls” especially where environmental issues are concerned.

This political test got me thinking about concocting a similar test for software development processes to ascertain whether developers are agile, centrist, traditional, anarchic, or formal. I’ve been reading too much agile and traditionalist bashing on newsgroups lately. It’s time that software folks call a truce to name calling and make a concerted effort to understand what’s driving their differences and what values they may have in common (even though they are in different camps).

I see software situations where more formality is needed. I also see situations where agile approaches would definitely inspire teams. At some places, the development processes seem to work, but development still proceeds slowly. I’m not sure whether agile practices would speed things up. They live in a complex world with lots of rules and regulations. On the other hand, I’ve definitely seen places where testing for quality at the end of a long development cycle definitely hurts their delivery. And I’ve visited other places where any process or project documentation would be better than what they have now. Still other groups seem to thrive on rolling their own software without much thought to process at all. Maybe instead of centrist, I should be labeled “chameleon”. What works depends on circumstances and your group and organization’s leanings.

However, there seem to be two fundamental axes that divide software process beliefs: predictive versus reactive planning, and evolutionary design/development versus targetted (or planned) design/development. (I plan on exploring the differences I see between evolutionary design and incremental design in the future. But from my vantage point there is a big difference.)

What agile folks believe and more traditional folks believe isn’t that different in some areas. Both tend to value teamwork and process. Anarchists don’t. Neither do formalistsâ; they tend to value the formalisms over any process that gets them to those formalisms. It is just agilists don’t place high value on document or pre-work (be it design, extensive requirements gathering, prototyping), etc. The lines between code and design are very blurry. I’m still working on questions that will draw out more of these distinctions.

Comparing Design Notes over Coffee

Posted on by
3

My architect friend Ken and I had coffee the other day and caught each other up on the latest trends in our fields. Ken and his wife designed our house. Ken and I like to talk about meaningful design processes (me about software, Ken about buildings and homes) and learn from each other’s experiences.

I explained to Ken the new trend in software called agile development which emphasizes teamwork, close customer involvement, evolutionary design, programmers as designers, and incrementally delivering value to customers. On a typical agile team there isn’t much distinction between designing and programming. Design is viewed as something that is constantly happening while you are coding. In fact one view held by extremists that I find somewhat disturbing is to equate any design up front as being the same as Big Design Up Front which is equated with being wasteful. Since you will change your ideas during implementation anyway, why invest any time inventing pie-in-the-sky solutions? (In case you canâ’t tell, I take a more moderated view—it all depends on the situation and the context. I believe a little upfront design never hurts, and sometimes more is needed).

More traditional processes tend to divide development into phases: problem requirements are gathered and analyzed, solutions are designed and implemented. Although even that description is too simplistic. The Rational Unified Process talks about overlapping phases and delivering incrementally. So what’s the big difference between agile and more traditional approaches?

One big difference between agile and more traditional approaches is what stands between the developer and the problem. Traditional software development teams have analysts or business architects who gather requirements, write them down, and then work closely with developers/programmers who implement the software. These people hold the torch for what the user needs and wants (and can afford) throughout the process. The good analysts I know are skilled at talking with users and business experts and at translating their requirements into terms that developers understand. They bridge the complex world of the business and the detailed world of the programmer. On agile teams, developers work directly with their “customers”. Middlemen are eliminated. As little documentation as possible is created. There’s direct, open communication. The software design takes shapes in a very organic manner. Things are not planned out to the nth degree beforehand.

Ken noted that a similar trend in building architecture, especially the environmentally friendly architecture that he’s interested in. There’s the traditional design process which Christopher Alexander believes makes for lifeless buildings, and the more organic, buider-as-designer process (which is a haven for old hippies, according to Ken). It is into this world divided into disparate camps, that Ken wants to bring his creativity and vision. He’s worked in a big architectural firm and felt far removed from the customers’ needs. On the other hand, do-it-yourselfers tend to not want help. Where does such a passionate designer like Ken fit in and make a living? I told him he has to find a new market and educate potential customers on the benefits of taking responsibility and engaging in the design of their environmentally friendly homes with a designer like him.

I told him I find myself in a similar situation. But I haven’t had to create a totally new market. More often than not, I work with those who follow fairly traditional development processes. There I add value by talking about responsibility-driven design. I also help people who want to build flexible, well-designed systems get more skilled at articulating what they want and how to build it. I also try to bring a spark of agility to their processes—finding ways to simplify heavy-handed processes, streamline documentation, and communicate more effectively. I’d like to spend more time with agile teams helping them bring their design skills up another notch while programming like crazy. But so far, that opportunity hasn’t come along.

I’m always fascinated by the parallels between software and the architecture world that Ken and I find whenever we have time for a cup of coffee. My next challenge will be to absorb some of Christopher Alexander’s latest writing (but Ken has warned me that his four volumes are not light reading) before I have another conversation with Ken.