(See also Part 2 – Two dimensions: Just in time and Envisioning)
JIT – solution for incertitude and complexity
Driven forces that introduces JIT Life-cycle in software development
- Business side: often changes – it is too complex to perform (too much) ahead requirements gathering
- Development side: software solutions are mostly design (instead of production) it is too complex to manage big chunks
As a consequence of the degree of incertitude and complexity for both requirements and solution, the life-cycle (planning) that suit better will have a JIT model. Agile development has adopted from the start such approach in its principles and practices: often and small releases, iterative development.
JIT approach it is a solution for dealing with incertitude and complexity.
JIT approach it is a solution for dealing with incertitude and complexity. It is similar with the mathematical approach to solve non-linear problems: feedback based approaches (control theory). The main issue is that you cannot compute (in mathematics) something that is too complex. In software development that mean you cannot envision too much requirements, solution and plan because of incertitude and complexity.
You cannot “compute” something that is too complex
Agile is one of the development approaches that already use JIT for more aspects. We can observe that XP that use “small releases” approach, use also “simple design” principle/practice – they do not want to make guesses about possible solutions aspects, required by possible future change request.
Let reformulate some JIT aspects:
- do not make guesses about incertitude (what is difficult of impossible to clarify)
- do not try to “compute” too complex problems
Do not make guesses about incertitude
If these principles are not follow, we will have the same problems as in mathematics: huge deviations of the solution for small changes in the inputs. Translating to the software development that mean huge waste.
JIT and Agile
Some Agile principles and practices that already use JIT approach:
- “Responding to change over following a plan” (Agile Manifesto – value)
- “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” (Agile Manifesto – principle)
- “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale” (Agile Manifesto – principle)
- “Business people and developers must work together daily throughout the project.” (Agile Manifesto – principle)
- “Make frequent small releases.” (XP rule)
- “No functionality is added early.” (XP rule)
- Simple design (XP Practice)
- Model Storming (Agile Modeling / DAD – Disciplined Agile Delivery practice)
- Document late, document continuously (Agile Modeling / DAD practice)
- Active stakeholder participation (Agile Modeling / DAD practice)
- Just Barely Good Enough (Agile Modeling / DAD practice)
- Explicit support for JIT based life-cycles: Agile, Lean, Exploratory (DAD – Disciplined Agile Delivery)
- Inspect and Adapt (Scrum principle)
JIT – main difference versus manufacturing
We need to deal with the main difference versus manufacturing: JIT design versus JIT production. In manufacturing we repeat the solution (design) from the last life-cycle and in software development we need to find a new solution for the newer requirements (metaphor: the market request every time car with a new design). The major problem here is to integrate the previous simple design with the current simple design (there are not just additive). We need that:
- The existent design must be easy to extend
- Integration of “next” design must be quick, easy and clean
I have described a solution for this problem in a previous post, a solution that re-arrange some already know thinks from XP and Refactoring (as it was defined in the Martin Fowler book) – an Adaptive Design based on this rules:
- Use simple and clean design and then adapt for new changes (example of adapt “tool”: refactoring)
- Use design practices that increase the adaptability (Refactoring, TDD, Clean Code, Clean Architecture)
JIT production from manufacturing it is based on responsiveness of a highly automated production. JIT design from software development it is more difficult to be automated, but we need to find that solution for responsiveness – it is mandatory to have an Adaptive Design.
Summary
- JIT approach it is a solution for incertitude and complexity, that it is validated also in mathematics
- Software development main problems are related to incertitude and complexity, that mean JIT approach could be useful in various ways
- JIT rules: do not make guesses about incertitude, do not try to “compute” what it is too complex
- There are many Agile values, principles and practice that are based on JIT approach
- JIT Design require an Adaptive Design
Agile Design = Adaptive-Lean Design 