Home > Uncategorized > Circular model of development

Circular model of development

August 20th, 2008 Leave a comment Go to comments

The first thing that I want to establish is that I trying to think about software development within a context of something we might want to call agile. So, if agile is a decrease in cycle times, delivering functionality more frequently against bigger batches of work less often, then you can count me in as “doing” agile. I am interested in the types of activities that occur in those cycles. For example, the activities that occur as a result of acceptance testing, unit testing, incremental design, continuous integration.

The other aspect of what we might call agile is to shift the metaphor for software development around people. It is against the idea that software is developed through machine-like processes – repeatable, consistent, predictable. People instead can make decisions, negotiate and be creative in the face of routine and repeating circumstances. So, I am interested also in the types and effects of interactions that happen between people, but that is harder to understand and requires quite a different method of study than reading blogs, books and explication.

Kent Beck, in a white paper for Microsoft on Tools for Agility, argues that the consequences of smaller and more frequent is at least two fold. One, a decrease in cycle times means an increase in the number of transitions between activities. Two, these transitions change the requirements for effective development tools. While he is trying to predict tools needed for the future, I interested in how the current set of tools has already affected the software development cycles. These sorts of tools are xUnit family of test runners that have spawned tdd, bdd, stdd, att; Build server tools and scripting languages/tools that have spawned better build, configuration and deployment management.

It worthwhile going back to Beck’s paper to see his base models. He compares a model of large batch flows with a linear approach to the end point against the smaller batches with transitions galore.

Large batch development cycles

Figure 1: Large batch development cycles

Figure2: Small batch development cycles

In contrast, what I see happening within development cycles is a slight variation on Beck’s small batch development cycles. The small batch model avoids transitions between activities as clean, well boxed straight-lined demarcations progressing forward in a step-wise, linear fashion. Rather, activities transition is predictably messy moving around through known analysis, design and testing activities – but their order and number of iteration up-for-grabs.

But Beck’s model still separates coding from the other activities too much.  I want it to be central to all those “transitions galore”: code for me is both an input and output, a starting point for decision making and a deliverable of that decision making. For me, central to this cycle is code because it is working software that I want most of all.

Circular model of development

Figure 3: Circular cycles

What do I gain from this schematic over Beck’s when his also has a notion of circularity in analysis, design, test? It is a shift in emphasis.  The model emphasises circularity and the repetitious nature of transitions. There is not just the words transitions galore, but the two lines to and from each activity represent the potentially large number of movements around them in any one cycle. At the same, movement through to release is predictable. You have to have passed through all activities in the cycle. You also have a start and an end and implicitly every end is a starting point. This shift of emphasis also suggests that we need to be as attentive to the lines as the activities. It is not just that we need analyse, model and test. We need to attending to which activity to move next to. What have we done? What do we know? Do we know enough? What is the test data? What are the scenarios? How do we add value? Are we done? These are complex heuristics. Luckily software development teams have smart people.

The emphasis on code also takes for granted that we are producing working software and that analysis, modelling and testing are inextricably intertwined with coding. Whatever we do, we add value through code. And making is about thinking and talking, understanding and misunderstanding, acting and waiting. Using these cycles, creating software is a process of developing knowledge and, as you learn more, keeping on going back, rethinking your original propositions and thoughts and refactoring the code to meets its objective.  It is a creative process, somewhat like a feedback loop, and as such is unlikely to be linear.

A transition: focus on cycles over process

You might have noticed that I shift my language around from process to cycle almost interchangeably. Not quite. I use process alongside creating software and being creative. A quick look at dictionary.com comes up process as a systematic series of action directed to some end or a continuous action, operation, or series of change taking place in definite manner. Software then is a process: overall it is repeatable, systematic and has an output. This I would refer to more broadly as the software development process. I use cycle to mark the activities we use inside that process. Back at dictionary.com, cycle relates to any complete round or series of occurrences that repeats or is repeated. It also relates to regular rhythms over time (most notably seasons). To generate software we need cycles of activities. In this model, these cycles all support generating code. It is now time to look at what I mean by code.

What constitutes code?

Code for me is something that can checked into the source code repository and it usually should be plain text in origin. I want it in plain text because it is my real friend. I can track changes, do transformations. It tends not to be proprietary. Five examples of code:
  • objects/classes (eg .java, .rb, .cs)
  • executable specifications/acceptance criteria (eg FIT, StoryTests)
  • test data (eg
  • scripting (eg builds – CC.Net; TeamCity, deployment, reporting)
  • user documentation (eg html and binary formats like swf, docbook, doxygen, dot)
Five examples that aren’t code (but could be):
  • Word documents
  • Visio documents
  • Project plans
These documents don’t tend to be code for me – we use them for thinking but they so often have a large maintenance cost that I use them as in input to a cycle (start). There are times when they could be but I find they tend to be using the advanced facilities (eg Word as an XML document, Visio using the underlying object model).

Code then is central and all the activities of the cycle support this activity: analysis, modelling, testing, documenting. This is away from roles that do these activities. Everyone does these activities, all the time, to generate code. There are two major shifts that occur: First, not just the analysts do the analysing, the testers the testing, the technical writers the documenting or even the programmers doing all the coding. That is not say there are not primary responsibilities and that anyone can do anything – that’s just too nihilistic for me. I find in practice, there are generalists, ideally generalising specialists, and there are people who are good at some aspects of development and not others. It makes sense to me to work with what people want to be doing and are good at.

Second, more than just code as classes-and-objects (and more recently unit tests) are first class citizens of the software process. Specifications, tests and documentation all get a promotion. Promoting these artefacts to code means that people on those roles need real support to move through cycles. I like this because there is a current trend to support developers-as-programmers in their endeavours to create code either by making them as self-sufficient islands of work in the dev/analyst, I-can-do-everything role or making everyone sit around talking about the code. I’ve tried both and met resistance time and time again. So, rather than only focussing on the developer code, the forms of code require developers to support other people (the analysts, testers, technical writers). This is important because these roles aren’t going away, some people are good at specialising, sometimes it just plain makes sense.

Who contributes to the code? Can everyone?

I think that they can. Otherwise, I wonder if I really want them on a project. Put another way, they aren’t central to cycles which, and hence the people who, develop the software. They are part of the process (SDLC) not the cycles.

How does this model relate to different software approaches {methodologies}?

Approaches that don’t work iterative and incrementally I think would make this a difficult way to work. The roles are segregated and people are rewarded for reliably delivering irrelevant outcomes – their documents. [maybe a bit harsh] Just a note on some {methodologies} not covered that Fowler lists as agile in his new methodology bliki: Context-driven testing, Crystal, RUP. Fowler says,
One of the biggest issues with … any agile method, is how to do the essential local adaptation where you alter the process to fit the local conditions.


XP at the face of it is the easiest to relate to these cycles. At the heart of its principles, lies the centrality of cycles, code and communication. Pair programming is perhaps the most obvious practice to connect with. Programmers work in small, test-driven cycles talking to each all the way through. They rotate pairs spreading knowledge around the team. Because I have widen our net of the notion of code, who pairs also is extended. Analysts, testers, build-engineers now need to pair – and that is probably with our programmer, but not exclusively.

Cycles are encapsulated in:  Small releases to put a simple system into production early, and update it frequently on a very short cycle. With continuous integration teams integrate and build the software system multiple times per day. This keeps all the programmers on the same page, and enables very rapid progress, increased frequency tends to eliminate integration problems.

Code can be seen in collective ownership allowing for everyone to contribute to the code base. Here, I am alluding to a greater set of people understanding the anatomy of the code base and knowing which parts they really know they can contribute. The anatomy of the code base ranges from understand file types, their function (eg build, class, unit test, fixtures, configuration files) and organisation within folders through checkin processes, branching/tagging nomenclature. If everyone is required to own this discussions and changes tend to move through with less friction and environment-specific processes tend to be weeded out as they appear. This is supported by coding standard. For a team to work effectively in pairs, and to share ownership of all the code, everyone needs to contribute to the code in the same way, with rules that make sure the code communicates clearly.

Finally, communication. Testing focuses on validation of the software at all times – though unit and acceptance testing that fulfills the requirements reflected in the tests. Customers provide acceptance tests that enable them to be certain that the features they need are provided. So the on-site customer determines requirements, set priorities, and answer questions as the programmers have them. The effect of being there is that communication improves, with less hard-copy, up-front documentation – often one of the most expensive parts of a software project.


Let’s take done as a simple concept that Ken Schwaber was talking about in a interview lately. Done is something that’s potentially shippable. It is necessary so a team knows how many items to select and so it knows what development process goes through within a sprint to create something and so that there is no undone work left at the end of the project for the team to stabilise. But it raises the question, does the team know and agree on what counts as done. If it is only coding and testing, it is unlikely to really be done. Acceptance testing, documentation, scripting still may be still undone. So the “shippable it” is not yet in fact shippable.

I am interested in closing the gap between the done and  undone through making visible the different type of codes that are deliverables for the shippable it. If the team can agree/work out/work through what the code deliverables are my experience is that there is greater likelihood of having realistic list of deliverables that make a shippable it. If this is the case then we might find greater cooperation to get the code deliverables to an agree state/quality.

For example, if the shippable requires not only API documentation but also installation instructions, release notes, technical documentation and user documentation then I am still at a lose at how a team who creates silos for these roles could possible deliver within a 2-4 week sprint in a calm fashion. The user documentation alone is likely to lag development – I know I been there. So we need to think more strategically about how we combine activities to generate our shippable it.

This comes back to code-focussed solutions. Let me pose the best example I’ve seen in bits and pieces. Imagine the product must have user documentation for our web application. We have worked out that screencasts work just fine. Why couldn’t we enlist a team effort that (a) has acceptance tests (b) part of these tests run, says, selenium © using the test data/scenarios (d) and these tests are recorded/captured (e) and checked in as part of the solution (f) additional explanatory information is entered as people do exploratory testing (g) that is added to the tutorial page that is the container to the screen cast. To make this happen requires a team-effort on contributing to the code base. After a couple of runs at this it is likely that you generate all the major touch points in the code base to make this work – otherwise, the build server is likely to fall over, or the viewing version won’t work!

Lean Agile Kanban

{notes} Here I am going to focus on how to make value flow.
  • tasks are broken down from stories and are seen as unit of work to flow
  • everyone needs to agree on what is flowing – what those units of work that add value really are
  • with the flow established, then we can also apply Lean thinking to the whole process
  1. Specify value
  2. Identify value stream and eliminate waste
  3. Make value flow by pull
  4. Involve and empower employees
  5. Continuously improve
The challenge is balancing continuous flow with limiting WIP through a pull system
  • ideal system tell you about what to do next. No more, no less. Anymore is waste
  • allow specialisation at steps
  • stop regulating people and start regulating work
  • puts limits on multitasking
  • KanBan: {Everything is about the throughput of code – but this is problem if the code isn’t the bottleneck}


Categories: Uncategorized Tags:
  1. No comments yet.
  1. No trackbacks yet.