1 Abstract
This document contains the complete software development process at Simple and Fast. The goal is to create software that just works for its entire service life, as quickly as possible.
2 Purpose of this process
Software development is notoriously hard to estimate. (Brooks 1991) Every team seems to find different solutions which work for them. In all such cases the key sources of variation in estimates, identified and tackled, have been:
- Large variability of encountered real-world inputs expected, resulting in “never-before encountered” or “impossible” scenarios being encountered surprisingly often. Such bugs, once fixed, become part of the resultant product, must be maintained. In brief, the system must have enough internal parameters and variety to accommodate huge variability in input. (Ashby 2015)
- Combinational explosion of interactions between parts making up the internals of the system. This is the difference between the programming systems product and the program mentioned by (Brooks 1991).
- Dependency on other software applications by other teams, which increases overhead when changes are needed, decreases the cohesiveness of understanding, and increases lead time accounted for in a planning timeline.
For each of these causes solutions, in terms of effectiveness, are:
- The complete specification of the interface being available for a program (all of its inputs and outputs), which simultaneously cuts down on the variability of inputs (since any specification completely eliminates most real-world inputs which may be provided, ideally before the program is developed.
- The subdivision of programs, such specified, into smaller programs, ideally in a way which takes advantage of the natural model in which the problem is expressed or natural (living) abstractions. This both limits possible interactions between programs and reduces cognitive load of the programming team in examining each part.
- Dependencies, of which there usually must be some, be fully specified such that for each is known the complete interface, responsible organization, the current source used in the project by version, at the lowest granularity (top of the dependency chain: aka it is enough to know that the Python Software Foundation is responsible for Python, without verifying Python’s dependencies).
These rules are far reaching. For example, the complete computer system which builds an application, and the complete computer system which runs the application, are two dependencies of the application simply by the fact that when it is prepared the whole complete computer system may be used to prepare it, and when it is run it may make use of all the facilities present on the running computer system. It is considerable work to verify that all in all only a minisicule part of the building system is needed, and this part portable to many such systems in the way to make the program useful.
TBD: specify operational definitions.
With these considerations in mind, this process seeks to prescribe a process which codifies the methods of reducing variability in software time estimates into development practices and operational definitions any team may use.
At its core, the process uses the Kanban methodology and example for tackling timelines.
Consistent quality is built into the process as a function of
- Simple, managed, dependencies.
- Functional deployments of version-controlled sources.
- Immediate CI/CD feedback.
- Tracking of work-in-progress (WIP) and flow with Kanban.
All key components of this process exist in template repositories to be used and shared. All projects should constantly update this RFD and those templates so that we may all improve together.
3 Terminology
This section is non-normative.
3.1 Application
An application is the complete final product delivered to fit the identified need. This final product is evaluated on two criteria:
- Does the interface the application presents to the customer meet the specification? If yes, the application is correct.
- Does the customer feel that the application meets their needs? If yes, it is a good product.
If the application is not both correct and a good product, in all cases the reason is because the specification is not representative of the customer’s needs.
From an engineering perspective, the customer interface could be one of:
- An application programming interface (API) which is a contract between us, the deliverers of the software, and software built by the customer, that our software will provide the following information or perform the following action when accessed in the prescribed manner. This API may be specified as a set of methods provided; in this case our application is a library. It may be specified as a RESTful API; in this case our application is a “web API.”
- A “user interface” consisting of a graphical screen with clickable elements paired with keyboard input and other human interface input/output devices. The possible variety presented by this type of interface is great, so the specification must describe the number of views; for each view, the number of interactable elements, their positions, and any effects that will occur.
- A user programming interface which is a contract between us, the deliverers of the software, and the customer which will use the software directly by examining its provided interface. This interface might be specified as a set of terminal commands; in this case our application is a “command line program.”
3.2 Customer
The customer is the end user of the application. They could be internal or external to Simple and Fast.
3.3 Specification
The specification is a document, written in English, which lays out all the requirements of the application. It is understood that the specification cannot capture all of what makes a good application: however, in terms of communication there is nothing more efficient than reading a well-written specification as a summary of customer needs.
The specification contains all of the final application (largest enclosing abstraction) inputs and outputs. This forms its interface to its customer. The specification should also have a block diagram of the application’s internals, and any internal specifications which might be known before development. This allows us to quantify how easy to application will be to use by customers, whether that is organizational customers or another internal team.
4 Key parts of the template repository
The specification