- A General System
- Detail Complexity Versus Systems Complexity
- Throughput Accounting for General Systems
- A System of Software Development
- A More Complex Software Development System
- The System Goal
- Financial Metrics for General Business Systems
- Financial Metrics for Software Development Systems
- Predicting the Future
- Framing the Problem
- Understanding Software Production in the Value Chain
- Throughput Accounting Versus Cost Accounting
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
A More Complex Software Development System
Figure 2-6 shows how a more complex system has more feedback loops. It may still be too simplistic, but it is intended as an example only. Throughout Section 1 all the example system diagrams are intended as templates for the purpose of explaining the theories for Agile management. The examples are also intended to be read as single piece flows, that is, they show the progress of a single idea and do not imply any form of aggregation of ideas or any particular software development lifecycle method.
)
Figure 2-6. Software development system.
Figure 2-6 shows that in order to achieve Throughput from the software development system, the idea must pass through three transformations and three sets of tests that can feed back to three different points in the system. It should be obvious from a glance at the diagram that the energy required in the system to produce Throughput from initial Investment is nonlinear with the level of input or output. Loops upon loops of feedback create the nonlinearity.
Stages of Transformation
Figure 2-6 shows a single idea passing through the system. Using Lean Production terminology, it shows a "single piece flow." A single unit of input is shown flowing through a series of transformations until it appears as output.
It is important to recognize that I am talking here about a series of transformations on an idea. I am not talking about phases in the software engineering lifecycle. This is an important distinction.
Much of the debate about which software engineering lifecycle method is best is centered in arguments about how things are done. I would like to suggest that what is done does not vary across different methods of how. In the abstract or general case, shown in Figure 2-6, what is done is simply this—ideas are gradually transformed into finished executable code through a series of transformation steps, which are, loosely, analysis, design, coding, and testing.
The debates over software engineering lifecycle methods revolve around:
-
How many ideas to aggregate together for transformation at any one time
-
Whether or not a single pass of transformations is required, or whether the process needs to be repeated through several iterations
-
Whether or not stages of transformation need to be visible or can be hidden
-
Whether or not tangible documentation needs to be provided for each stage in the transformation
-
What is the best method of performing a transformation
-
Which artifacts should be produced
-
Which language (written or visual) should be used.
Despite all of these variations in how to achieve Throughput, I contend that all the transformation stages—analysis, design, coding, and testing—are required and do happen. Sometimes, analysis is explicitly declared. Sometimes it is rolled into the design stage. Almost all methods acknowledge the testing stage. Occasionally, testing is left as an exercise for the customer. However, all the stages of transformation are present.
Methods that suggest that stages of the transformation are skipped are really saying that stages of the transformation are invisible. In the case in which a programmer simply writes some code, is analysis and design missed, or does the programmer simply do it in her head before typing in the code? Is it possible to just type in code, without first thinking the problem through? Would such random code lead to a properly finished product? The reality is that software developers must think things through. Whether or not they write it down, discuss it with colleagues, or simply do it, that process of thinking involved the transformation of an idea through several stages.
Section 2 will survey alternative software development methods and examine the economics of each. Regardless of the method used, the work presented here is built on the premise that finished code cannot be delivered without each idea being processed through a series of transformations. Whether or not the ideas are all processed through each stage together, that is, the Waterfall method or they are processed in small batches, that is, Feature Driven Development, or the number of ideas processed is bounded by a fixed time, that is, Rapid Application Development, is interesting and affects the economics of software development. However, it doesn't undermine the notion that all software starts as individual ideas that are transformed through stages in a system of software development.
Throughput Accounting Software Development
For the purposes of illustration, I return to the simpler model in Figure 2-7 that shows how to assign the basic attributes of I, OE, and T to software development.
)
Figure 2-7. Throughput accounting software development.
Unit of Inventory = Idea
Value of Inventory = Investment to Create the Idea
Investment = ValueInput
ValueOutput = Sales Price − Direct Costs4
Value Added = ValueOutput − ValueInput
Throughput5 = ValueOutput