This episode considers a method-free approach to software engineering methodology, and a request to include the context of a software project in the attempts to sell techniques and processes. The episode is supported by members of the Chiron Codex Patreon (use this gift link for your first month free), so please do join the community or hit the Ko-Fi button to make a one-off donation. If you enjoy the episode, share it with at least one friend, colleague, or stranger.
Links
- The frog and the octopus: a conceptual model of software development
- What is Scrum?
- Scrum Guide
- A Software Chasm: Software Engineering and Scientific Computing
- The Essence of Software Engineering: The SEMAT Kernel
- Introduction to Communities of Practice
- Podcast Reading List
Transcript
Hello and welcome to episode 65 of the Structure and
Interpretation of Computer Programmers podcast. I’m Graham
Lee. The episode is sponsored by you, the software
engineering community. If you enjoy this podcast, please
share the link with your friends and colleagues. You can give
feedback on this episode by commenting on the post at
sicpers.info slash podcast, that’s s-i-c-p-e-r-s dot info
slash podcast, or by sending me an email, grahamlee at
acm.org.
There are many problems with software engineering
methodologies. Methodology, by the way, is the study of
method. So we’re in the realm of software engineering
metaphysics, thinking not so much about how the sausage gets
made, but about how people design, build, deploy and service
sausage-making machines. So a problem with software
engineering methodology is a problem of working out how to
define or apply a software engineering process, how to
instantiate the idea of software engineering in a specific
context.
And it’s identifying that context and tailoring a method to
the context that is one of the biggest problems. It’s
actually difficult to get people to tell you when a
particular approach to software engineering does or doesn’t
apply.
Oh, you can get someone to tell you, but rarely is that
someone one of the creators, the methodologists themselves.
You won’t find any scoping or context information in the
documentation for the methodology or framework. As an
experiment, look at “What is Scrum?” on scrum.org, or read
the Scrum guide at scrumguides.org, and now try to come up
with an answer to this question. When do the creators of
Scrum think it’s an appropriate tool to apply? Or this
question: in what contexts do the creators of Scrum think
that you should reach for an alternative approach?
Of course, you can search the internet for individual answers
to the question from people who have tried it and found that
it doesn’t work for them, or from advocates who definitely
think you should be using it for whatever it is that you’re
trying to do. That’s far from systematic, it’s far
from…methodological.
People who found that it doesn’t apply might have the wrong
context, or they might have the wrong skills, or might have
understood the process incorrectly. Scrum, particularly, is a
baseline process and a process improvement framework, and
most places I’ve seen that “do Scrum”, with my podcast scare
quote fingers, don’t have any experience at process maturity
or improvement. So they either do the baseline process
forever and complain that it’s stultifying, or they tweak it
into something that doesn’t work for them, and then complain
that it doesn’t work for them.
The result of this lack of contextual or scoping guidance is
you get these bags of apparently associated practices that
promise to control your software development work, and no
particular reason to choose one over another. Nobody explains
why Scrum has all the Scrum practices, and why XP has all the
XP practices. Further, they don’t explain why Scrum doesn’t
have the XP practices, and vice versa. Is there actually a
problem with having both a sprint retrospective and a
sustainable pace? What do the methodologists know about how
these practices combine that they don’t tell us?
The world would look very different if we had a context-aware
approach to selecting software methodologies. If you could
fill out a real or metaphorical checklist, and it would tell
you, “okay, so you’ve got a department of 25 engineers at a
growth stage fintech, working on a service for one big-ticket
customer. You use these practices.” Or it tells you, “with
your three PhD students, fixed term, fixed budget, creating
biophysical simulation software, you should do these things.”
There was meaningful discussion on this topic back in the
1990s and 2000s. Diane Kelly observed that the definition of
computer science as a distinct mathematical discipline
independent of the business of making software, –
incidentally, that’s a topic I’ve covered multiple times in
past episodes – that definition of computer science led to
computing experts favouring generic, domain-independent
techniques, methods, and paradigms. This, in turn, led to a
rise of one-size-fits-all, or domain-independent management
paradigms, which meant, to use her words, “a reorganisation
along the lines of all software is treated the same, all
developers are the same.”
In practice, scientists writing software for research aren’t
the same as Java coders toiling in feature factories. So
software engineering methodology, in fact, developed blinkers
in which people either worked the way methodologists
expected, or they were doing something different, which
placed them beyond the methodologist’s comprehension and
therefore beyond any help. A “chasm” opened up between the
domains where methodology worked and those where it didn’t
apply, which Kelly hoped that we could bridge by considering
domain-relevant or domain-specific methodologies. That, of
course, didn’t happen.
So now we come to the document at the core of this week’s
episode. In 2011’s “The Frog and the Octopus”, Philippe
Kruchten wants to abandon the “methodologies” (plural noun
that really means named software development processes), and
replace them with “methodology” (uncountable noun that means
the study of software development method). His goal is
nothing short of a unified model of software that applies to
any domain. To help us to get there, he separates software
engineering into the things that everybody does, which he
calls the frog, and the things that lend context specificity,
which he calls the octopus. And then he has a third category
that doesn’t have an animal name. We’ll get to that later.
This is the advert break. It starts now.
Your development team is slowed down, your customers are
frustrated, and your support team is constantly banging down
the door. Nobody can find the information they need, and they
struggle to talk to each other to work it out. Relationships
on the team have soured, with developers, QA, and ops
all-taking, and us-versus-them position. Your backlog grows
faster than the team delivers features. Retrospectives
involve more finger-pointing than decision-making. This
sounds like a case for Software Craftsmanship’s consulting
detective. That’s me. Discover your team’s friction points,
and create realistic action plans for improvement.
Restructure your delivery pipeline to bridge the quality gap,
automate improvements, and reduce rework. Then, take
ownership of the documentation, and curate a knowledge hub
that keeps information flowing throughout your organization,
empowering engineers, executives, partners, and customers
alike. Find out more, and book a free initial assessment at
sicpers.info.agency. That’s s-i-c-p-e-r-s dot i-n-f-o slash
agency. Together with me, Software Craftsmanship’s consulting
detective will crack the case.
That was the advert break. It’s over now.
The frog is the central concept of a “project”; an attempt to
achieve some goal by producing some output with some
resources and some people within some amount of time. In
fact, I’ve almost listed all of the nine categories in the
frog part of the model in that one sentence. To be more
explicit, we’re talking about:
- the intent: what somebody aims to achieve
- the product: what they expect to make in an effort to
achieve their intent - work: what people do to turn the intent into a product
- the people: who does the work
- time: the evolution of the other attributes
- quality: desirable parameters of the other attributes
and the values of those parameters - risk: uncertainty related to the other attributes
- value and cost: the resources unlocked by achieving
the intent or creating the product, and the resources
required to get the people to do the work that means the
intent is achieved or the product is created; and finally, - project, the metaphorical boundary that encapsulates all
of the above.
So are these attributes of the frog truly universal? I’d say
that this is one of those questions where you learn something
about the philosophy of the person who answers the question
from the way in which they answer it. You might say that a
hobby open source endeavour doesn’t really have any risk
because it’s just a hobby. It doesn’t have any cost because
it’s just a hobby. And it doesn’t have a project because
there’s no timescale, no stakeholders and no stated
deliverables.
Or you might say that those things are present. The main risk
is that the hobbyist finds a different hobby. The cost is the
opportunity cost of the time they put into their hobby. And
the various projects are anything from “I’m going to put in a
couple of hours on optimising spline reticulation this
evening”, to “I want to have these three features before I
release a v2, hopefully by the end of this year.”
Kruchten takes the latter position. All of those things are
present. And the fact that the software is part of a hobby
open source project is important context that modifies the
importance of some of the “frog” attributes of the software
endeavour.
In fact, there’s really nothing about software in the frog at
all, despite the number of times that Kruchten says
“software” in this section of the paper. Really, this is a
model of a generic knowledge-work project, which only doesn’t
translate to tangible production because there are no
facilities, materials, inventory or capital. But software
projects do have those things. What gives? Again, philosophy.
They’re not important enough, to Kruchten at least, to
materialise in the paper. They’re kind of hidden in the idea
of costs.
So that was the frog. Then there’s the octopus. This is all
of the context in which the project occurs, which gives it
its unique flavour. If, like me, you’re confused about the
frog imagery, you’re on safer ground with the octopus because
there are eight categories, or arms I suppose, of context.
Well, sort of. In fact, there are two components to the
octopus, one of which has five arms and the other eight. So
maybe it’s an octopus riding a starfish? I’m just going to go
and rewatch The Little Mermaid because it’s possible that
that’s actually a named character.
Anyway, Kruchten divides
the octopus into variations at the project level, of which there are eight, and at the organisation
level, of which there are five. The eight project level variables are:
- size. He says the overall size of the system under
development, but it isn’t clear if that means the size of the
product or the size of the intent. Maybe it’s both. Maybe
some organisations set out to create large software because
they think it’s better in some way, or they set out to create
small software for the same reason. - Architectural stability.
- Financial model.
- Team distribution.
- Rate of change, by which he means the volatility of the
business environment and the associated uncertainty, not the
rate at which people change the software. - The age of the system, through which we infer
that the product can vary between new features in an existing system, to novel product, to ground up
rewrite. - Criticality, i.e. how safety critical is the system. And;
- Governance.
I’m largely happy to go along with all of this, except that I
think it’s a bit arbitrary to separate criticality and
governance. Criticality is really about the magnitude of
risks to external stakeholders, and governance is the way
that you vary your work to address or to avoid or to ignore
those risks. You could take a completely freewheeling
approach to avionics software, thus fail at any compliance
goals, which would expose some huge risks, not least of which
being you probably wouldn’t be allowed to sell your product.
You could take a safety critical approach to developing a
casual mobile game, which would expose some other huge risks.
I suppose you do need eight arms for an octopus though, so
both are listed.
That then brings us on to the five arms of the organizational level factors:
- Business domain.
- Number of instances (of the deployed system).
- Organizational maturity.
- Level of innovation. And;
- Culture, which is further divided into social culture,
that’s the norms and values of the society in which the
workers are embedded. Corporate culture, which is the way the
organization thinks about things. And ethical culture, the
way the workers and managers think about responsibility to
other stakeholders.
So the big idea is that the way you do software depends on
all of these things in both the frog and the octopus. But the
most software methods or methodologies focus on the frog and
ignore the octopus. They pretend they have a
one-size-fits-all process that anyone who wants people to
make software can apply. The frog gives you a model you can
use to critique a project. “How do you measure the quality of
the product?” “What risks are associated with the people on
this project?” And so on. And the octopus gives you a model
you can use to critique the applicability of a practice,
process or tool to your specific context. “I have 10,000
people on three continents. Should I do a daily scrum?” “Does
the idea of minimal viable product make sense for my two-year
fixed-term fixed-budget research project?” And so on.
These methodological ideas reach peak maturity in an approach
that Kruchten worked on with Ivar Jacobsen, Bertrand Meyer
and others called SEMAT, S-E-M-A-T, Software Engineering
Methods and Tools. The SEMAT kernel recommends not thinking
about a methodology as a package of practices but about
software development as a system in which the main
interacting components are what the SEMAT methodologists call
the “alphas”: opportunity, stakeholders, requirements,
software system, team, work and way of working.
These seven alphas approximately map onto parts of the frog
and the rest of the process is about identifying your
particular challenges and opportunities, i.e. mapping your
octopus, and then thinking critically about how a given
intervention, adopting a technique, abandoning a technique,
selecting a tool and so on, would change the different alphas.
We have still to address the third unnamed part of the frog
and octopus model, that is the tacit-slash-explicit
dimension. How much the knowledge and ways of working in an
organisation are documented and follow the documentation, and
how much they are unstated shared cultural assumptions that
everyone “knows”.
The idea of tacit knowledge is a crucial part of the theory
of Communities of Practice. Communities of Practice is a
theory largely worked out by Etienne Wenger to explain how
people who have some shared interest in performing a
practice, whether it’s work related, a hobby practice, an
educational requirement, a form of religious worship or
something else, come together to collectively enthuse about
the practice and in doing so develop a shared understanding
of the practice and even shared rules about how to perform
the practice that don’t necessarily correlate with any formal
instructions, documentation or reporting structure in the
practice’s setting.
In the frog and octopus model, this forms another contextual
component. You need your people to have a shared model of the
intent, the product, the people and the work. How much of
that that do you infuse culturally, and how much do you share
in documentation, and how much is out of your hands because
people make it up in their communities of practice? What kind
of documentation should you use? Dashboard, wall of cards,
task tracker, wiki, bulletin board, chat forum, formal
processes, checklists, employee handbooks, something else.
Tacit/explicit knowledge is the least explored of the
dimensions, mostly because if you’re trying to sell a
technique or a product, it’s better if it’s tangible, and
saying “our product enhances the tacit knowledge of your
workers so they do things in ways that are out of your
control” doesn’t sell very well to managers. Perhaps it could
be one of the most interesting and impactful dimensions
though, especially in this age, of tools that build software
based on your explicit description of what you want,
completely ignorant of all tacit context.
A methodology that explicitly surfaces all ambiguity in
product requirements, ways of working, interpersonal
relationships, software design, quality expectations, and the
rest of the frog, right at the point that you try to feed all
of that information into a large language model, could be the
defining feature of post-2023 software engineering. Or it
could be a hugely onerous, wasteful, and bloated process, and
you’re better off leaning into the ambiguities and just
having your people take their coffee breaks together so that
whoever types a prompt into the model already has a good idea
what the customer was thinking. That second approach has
generally been considered a good idea for the last three
decades or more. Maybe it’s still a good idea today.
As ever, share your thoughts on this episode in the comments
on the sicpers.info website, that’s S-I-C-P-E-R-S.info, or
email grahamlee at acm.org. Recommend the podcast to your
friends, find more info at the Patreon page linked in the
show notes, and the reading list at se100.chironcodex.com,
and let’s talk soon.
