I was reading “The End of Software Engineering and the Start of Economic-Cooperative Gaming” by Alistair Cockburn. These two paragraphs frame software development in a different way as an economic-cooperative game, rather than the commonplace software engineering frame.
“Software development is a resource-limited, goal-directed, cooperative game, whose moves consist of invention and communication. The people, who are inventing, manipulating and communicating information across multiple heads, must share their information in order to produce the solution.
This means the speed of the project is proportional to the speed at which information moves between people’s heads. Every obstacle to detecting and moving information between heads slows the project. Understanding and attending to this issue is essential to playing the game effectively.”
Software Development is more than coding.
There are definitely coders out there. But the act of coding or writing syntax to create a program does not make you a software developer. A true software developer is playing this game and as a professional, they’re asking what do I need to become to play the game at the next level. The software developer’s abilities include programming, but also include learning to make these time and capability tradeoffs and communicating more effectively for shared understanding.
One of the main thesis in the post is that invention and communication increase proportional to the speed information moves between people. More specifically than just information, how fast shared understanding moves between peoples heads. This explains why:
- Delivering the system soon and inexpensively competes with creating an advantageous position for the next game. [Alistair]
- Creating inexpensive markers competes with creating them to work for a wider range of new people. [Alistair]
- Keeping the team intact competes with introducing new people. [Alistair]
- Using a smaller number of highly qualified people (with lower communication costs) competes with using more people of more average capability. [Alistair]
Why I enjoy playing the game of software development.
People will usually equate me saying I love software development to me being a “tech guy” and liking to “write code” or being a “programmer”. These are parts of the craft, but I view myself as participating in the business as a whole. Not all businesses think of software developers as integrated with the business as a whole. Some view software development as a manufacturing task, so it would not be integrated and could be delegated to an outsourcing company.
I have drawn a graphic of how I view Alistair’s observation at the bottom of the page. I think with this understanding of software development, it helped pull back the curtain of why I like certain aspects of software development, mainly those experienced through the frame of an economic-cooperative game. When software development is framed only about engineering or just the syntax, or the machine, then I lose interest. When I want to learn a new programming language or pattern, I typically create a project for myself to work through so I can go through the game with the new technology.
Software development is not experienced by an individual as programming, although programming languages are part of the skillset. To me, it is like the game of basketball is not experienced as players running up and down a court for 2 hours, although running is a skillset required. My enthusiasm for the game, is more about playing the economic-cooperative game and not so much about a coding language. Another analogy is how an author is telling a story (software), not spending all day typing.
A software developer’s contribution to the business is beyond manufacturing code.
Looking at software development through the lens of this type of economic cooperative game also introduces a pathway for everyone contributing to a business to understand how software developers participate, beyond code. Meaning how software developers participate in business beyond production, beyond manufacturing code. Many businesses are going through a digital transformation, where they are increasingly becoming software businesses. Software businesses need good software developers to contribute to the business. They will influence how the business is experienced by customers. A digitally transformed business looking for good coders, is like a basketball team looking for good runners. Finding a good runner might not make your basketball team any better.
The diagram shows the span of delivering multiple software goals (releases) across time (Time 1, 2 and 3) and the tradeoffs between being goal oriented during Time 1 while having to balance what to keep in mind for Time 2, but still delivering during Time 1 to meet your goal and you always have limited resources, which makes the tradeoff necessary. So you can put in a better platform in Time 1 to support Time 2, but it will keep you from doing other things in Time 1. Or you can create “throw away code” in Time 1 and realize your Time 1 goal faster, but that decision might make your Time 2 goal smaller or stretch out longer because you have to rework it instead of continuing to build on top of something already useful in the stack. Then you have the coding patterns like the Strategy Pattern to help, but you also have meta patterns, something that’s not in code, but still considered part of the software you are creating, like the domain concepts, that can help or hurt with this game too.