Software Development as an Economic-Cooperative Game

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.

Diagram

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.

Software Development.png

 

B4B – Reinventing the Customer-Supplier Relationship – Book Review

I just finished reading B4b: How Technology and Big Data Are Reinventing the Customer-Supplier Relationship and it helped me understand the company I’ve been working for and others in the industry.

One of the models the book puts forth is one of 4 levels of companies. A company can stay at one level or try and progress to next levels. The authors put emphasis on the need for adding levels with AND, instead of OR.

The four levels are organized by the complexity of the offer and the result the customer is expecting.

  • Level 1: Simple Offer
    • This is like a simple product company, where the manufacturer distributes product to re-sellers that distribute to end users. An example might be a company that sells toasters.
  • Level 2: Complex Offer
    • This is like an IT or enterprise software company that sells a complex system. This offer requires someone to manage the system after purchase. This level of company will sell the product to a customer, like a hospital, and then leave and let the hospital engineers maintain the system.
  • Level 3: Optimize
    • This level of company offers complex products, but adds additional services. An example might be a software vendor that sells a product with an annual maintenance contract. This vendor might remotely monitor the software or perform routine maintenance or other programs to make sure the customer is able to use the product.
  • Level 4: Outcome
    • This level of company offers customers outcomes. An example is a copier machine company that does not sell copiers, but puts copiers in office buildings and sells per page. People are not buying copiers, not buying maintence contracts, but are buying a copy. Another example is Amazon Web Services offering servers by the minute.

The book takes these categorizations of companies and spells out useful advice for each. The Level 4 companies require more automation and not just per-outcome pricing. The authors warn that if a Level 4 company tries to sell using Software-as-a-Service (SaaS) pricing without the necessary level of automation, then it will cost the company a lot more. This is because the company will have guaranteed an outcome, but without automation, the delivery of each unit will vary. We know this in IT because depending on the employee and depending on different factors, the time required to set up a server can vary.

A lot of small and medium size traditional IT and software vendors are doing Level 2 and Level 3 offers, where they offer complex products and selling annual maintenance contracts. The book makes the argument that because customers are getting introduced to Level 4 companies in the consumer space, that they will increasingly expect Level 4 companies, like Salesforce and Amazon in the commercial space.

B4B makes the case that many software vendors products offer way more features than are actually used by any individual customer. This gap between the customer’s usage and available capabilities is something that software vendors should take notice of. What ratio of your developers work is going to adding new features, that might not actually contribute to value-add for the customer? With this feature/usage gap, those developers have cover to use an increasingly larger portion of their work time to implement the underlying platform needs, to bring their company to Level 4 automated offers. This requires deep instrumentation and understanding how customers use the product.

Are APIs Semantics?

There is a blog post Thinking Outside-In: How APIs Fulfill the Original Promise of Service Oriented Architecture by Anders Jensen-Waud. A comment on LinkedIn referencing this article asked if “APIs by themselves begin to address semantic interoperability?” I don’t think so and my reason for thinking semantics is not defined in the API itself is as follows.

I have been creating APIs for hospitals for years and have found an API by itself doesn’t make something more likely to be semantically interoperable. I have found it’s more important to get the community that builds and uses the APIs to use the same vocabulary with the same context and out of that understanding APIs can be developed that are semantically congruent. Without those people sharing understanding then they each go off and develop their parts and after they have developed each part they come back to integrate it with the whole and found that even though they used the same property names or class structure, they used them with different intentions. For example, this really happened once. One team of API creators inside a company started with the same product goal as a second team in the same company, to track locations of things on a map. They each knew that they were going to use polygon data structures and each point in the polygon was going to have a X and Y property. Three months after each building their components, they came together to integrate their parts and they didn’t work, because they operated with different assumptions. One team’s processing logic used Cartesian points where the X,Y origin is in the bottom-left and the other team used Raster points, where the origin is in the top-left. No one identified semantics as a deliverable, because the teams ionly thought the code/API was the deliverable. The semantics should have also been a deliverable and occurred before the production of an API.

The insight I want to share is that semantics is a shared context and understanding. APIs and code itself are just symbolic processing. The symbols themselves do not inherently carry the meaning, but the common understanding among people can use the symbols in the same way.

What Kind of Software Business are You In?

Strategy is about making choices between what to do and what not to do. Richard Rummelt says good strategy is a “coherent response to – and approach for overcoming – the obstacles to progress.” How do you define progress?

Some people use activity as a synonym for progress. However, progress is knowing the result and working towards it. If you substitute a result for a different result and say that you will resume working toward the original result after completing the substitute result, then you are no longer making progress on the original result. Substituting vaporware for programming the real thing to meet a deadline is no longer making progress on the original result.

Activity measures inputs, but results are the measure of outputs. Progress is measured by completed outputs. Software is invisible. Software is executed as code made by programmers, but its purpose fulfilled when used by the customer for the results it provides the business.

Software can be sold as something to help realize a solution, in which the intellectual property characteristic of software might be second priority to realizing the solution for the end customer. In this case, the seller might not be a software intellectual property company, but more of a systems integrator building custom “glue code” between other software companies systems to realize a specific implemented solution for a single customer. These kinds of software companies use skilled personnel and their time to achieve the output of individual solutions. Because these companies do not produce intellectual property that can propagate in a way that’s decoupled from their personnel’s interaction, then this software business is managing a personnel system to reach customer implementation milestones. This kind of software company leverages code to be used in the most specific of ways to the customer.

Software can also be sold as intellectual property, letting external system integrators leverage the intellectual property to realize a solution. These kinds of software companies make different decisions. They prioritize for distributing their intellectual property in a way that is decoupled from their personnel’s time. The skilled personnel and their time in these companies is spent on creating and honing the intellectual property so it will have a balanced set of characteristics. These characteristics are distribution, maintainability across multiple customers and environments and leveraging code to be used in the most high value scenarios.

Progress in one of these businesses means something different than progress in the other type of business. Both types of companies act in the same world. The difference is in how they approach the world and the marketplace. Both kinds of companies might use software modules, but how they use them is different.

If your business is the tight systems integrator for other software products, then you will need to manage more people to scale. Creating line of business applications for large customers, by integrating other peoples intellectual property will mean that it will be considered a waste to focus energy on the distribution characteristics of your software. This is because it is assumed this solution is so tightly coupled and paid for by the large business, that it will not be distributed to any other business. This type of business does not benefit from the type of $0 incremental unit cost characteristic of software intellectual companies.

If your business is the intellectual property creator, then you will need to manage people and make sure they are producing software with a different set of characteristics. Distribution technology is important because in software business you must distribute inexpensively and in a guaranteed installation process to realize the main benefit for being a software distributor. That benefit is that each additional unit sold is near zero cost to distribute. Producing the software is the main cost and selling/distributing it to just one more customer is near $0 cost. That means software gets cheaper the more customers you sell to.

Parts of a System and Your Fit

In a business that makes software, it is well known that one tactic for making large software is to break the problem and work down in to parts. Then the work is assigned to different people. What is less well known, in my opinion, is that when a problem is broken down and divided among people there still needs to be understanding of the system among each of the parts. In essence, the people that start out with the big problem divide and assign tasks, but it is important to remember to also assign understanding of the system as a whole to each part.

Sometimes taking the time and effort for each part to understand the system as a whole is considered waste. It takes time that cannot directly be quantified as producing code. The code that is produced by the individual will be for their part, so why do they need understanding of anything other than their tiny little problem?

The parts need to be able to answer the questions:

  • What am I a part of?
  • How do I interact with the other parts?
  • Is the problem for my part designed correctly so that I may create the correct solution for the system? Read more about designing problems before designing solutions.

Interaction is not contained nicely within a part. Interaction should also be viewed from the perspective of the customer and not entirely from the perspective of the discipline of engineering.

For example, there is a large system that was developed at a company I know of where the mobile application used a red icon to represent a sale and the corresponding web site that displayed aggregated reports of sales used a red icon to represent that a sale was NOT made. Each part was certified to have accomplished their task individually correctly. In this case, the mobile application was considered a part of the system and assigned to an engineer and the web application was considered a part and assigned to a different engineer. Each was certified by the people testing to have accomplished their task correctly. Yet, the result was pure confusion if there was any user that was to use the mobile app and the web site.

What was lacking, was the mobile developer asking what they were building was a part of and the web developer asking what they were building was a part of. As engineers, they understood that the two sets of code were going to share a database. Yet, this fundamentally misses the point of understanding the system. Just because a database is completed and represents the entire set of data, does not mean it is the system. Even when implemented, the system is more a concept than any specific piece of technology. This is lost on some engineers that jump directly to implementations, pointing to specific tables of data.

If the question had been asked of each person who was responsible for building the parts, “What is this a part of?” and “How will this part interact with the other parts?” instead of saying “I have my part, I’m face down in implementing my part and I don’t need to waste my time with seeing what the other parts are up to.” then maybe a better system would have been developed from the perspective of the people who will be using the system. Something is always part of a larger system and to dismiss this in pursuit of optimum efficiency, getting your part out the door fast, is quick but not smart.

Successful software is the right software, not the fastest developed software.

Not Reinventing the Wheel to Reduce Costs

Sometimes someone within an organization will task the software development team with developing new software features and prescribe a solution that “does not reinvent the wheel”. Many software consultancy companies create software based on the problem-solution paradigm. There is one major customer that has a specific problem, the consultant analyzes the requirements of this customer and formulates a solution.

With the goal of saving costs the consultancy will try to resell this solution to multiple customers, what the consultancy terms “productizing” the application. I believe it is wrong to classify a consultancy’s output as a resalable product like a cog in a machine. The nature of this customer/consultancy relationship is that the next customer will have requirements that are analyzed and the software will need to be changed, which is at odds with profitability because the goal with the second customer initially was to resell an existing solution. To continue to attempt to save on costs the consultancy that is now analyzing the requirements of the second customer will task the software development team with new requirements, prescribing reusable parts of a prior solution and pushing not to reinvent the wheel. What is meant by this is to leverage existing code. However, the second customer’s problem is different than the first customer’s problem, new requirements have been captured the resulting system that needs to solve the second customer’s problem needs to be examined first as a system and not individual swappable parts. After all, what was initially created for the first customer was a solution to a specific problem inside the context of one customer, not a general-purpose reusable framework. Inevitably the second customer has unique demands that end up contradicting the first customer’s and this makes the system grow more complex.

Another way to approach this is if you want to create a product, then analyze different potential customers at the beginning and synthesize a product that addresses those customer pain points. Generate your own frame of looking at the problem (your way of adding value) and spend energy building the framework you will use to build the product, even though the framework has no individual customer yet. A part of a product’s value is how it frames the problem, not just that you can buy a cog. Analyzing customer requirements individually and transmuting these directly into development tasks will not create a product, even though it might result in a solution for a specific customer. A consultancy is not wrong, but terms and business processes that work in product companies might actually be greedy shortcuts in a consultancy that end up misunderstanding and prioritizing future customers solutions.

I’ll give an example to demonstrate how creating a solution for one specific customer is in conflict with creating a resalable product. If you are creating a solution for a specific customer’s problem then you will continuously be trying to keep that one happy satisfied and solving their problems. No two customers are exactly the same. However, if you are building a product then it is acceptable that some potential customers might not be ready to use your product because they are too small or potential customers have outgrown your offering and are ready to move on to other solutions outside of what you offer. In this case, you might lose a customer through no fault of your own and your product is still a success. In a consultancy you have failed if you lose a customer. In a product company you are trying to create customers that are a fit for your product and you are inviting customers to frame their problem so it fits your product solution.

Another example is a consultancy does not want a customer to solve their own problems. Demand for the consultancy increases when the customer has more problems they want solved. This orients the consultancy around expanding to solve more of fewer customer’s problems because the path of least resistance is to sell more solutions to someone who is already paying you. On the other side, a company selling a product can align with insight selling where customers armed with data from websites and research done by themselves have been heavily influenced in knowing what solutions can be used to solve their problems.

Not reinventing the wheel cannot be prescribed because a consultancy wants to reduce costs. Not reinventing the wheel is a constraint on the input and is decided by how the business operates before it gets to the software development team.