JIT

I first encountered JIT (short for Just In Time) when doing a course on SQA in 1993. JIT is an idea that originated in the Quality Assurance movement in Japan, in the area of inventory control in manufacturing (Toyota?). JIT was an idea that went against conventional thinking, which was to ensure you always had more than enough inventory (eg, of inputs into a manufacturing process). JIT took the opposite approach which was to have as little inventory as possible (or none at all) by relying on product arriving when needed (ie, just in time).

DIRE   

JIT is an example of the broader principle of DIRE which I will discuss one day soon.

The obvious advantage is that inventory costs are reduced. But there are other, not so obvious ones so let's list all those that I can think of:

1. Reduced storage costs for inventory
2. Greater visibility in the supply chain - this allows problems to be quickly found and fixed - see Visibility (below)
3. Parts are less likely to have deteriorated (rusty, stale, etc) - see Cost of Delay
4. Parts are less likely to be obsolete when needed - see Cost of Rework

In the software industry the first advantage is not at all important - a little bit of disk space costs a lot less than a warehouse full of car parts. However, the others are significant so I will give some examples.

Visibility

Traditionally software is created by building low-level components then gradually assembling them into more and more grandiose structures. Though design is usually done top-down, implementing the design is done bottom-up.

There are several problems with this approach. The main one, in this context, is that the creation of a low-level component will be isolated from its first use. Moreover, the initial use is unlikely to exercise all the features of the module. [Another problem is that the low-level module is typically over-designed and far more complex than is necessary for its intended purpose - see Reusability Futility.]

In other words a module is not even tried in a realistic environment until some time later, typically never fully used as intended. Eventually it's used and realized that it is too slow, has many bugs, or just doesn't do what's required. By then it is much harder to fix. In some cases it is easier just to start again.

A better way is to build everything at once. How can you possibly do that? It is usually fairly easy to build the minimal piece of software that actually works, without modules and just a basic design. Later, we can split parts off into modules and evolve the design. If it is truly minimal then every bit of the code will be used to satisfy the initial acceptance test. That way you know there are no surprises lurking in some piece of code that has not been exercised yet.

Cost of Delay

In manufacturing the JIT approach avoids the costs associated with parts deteriorating over time - what I call a "cost of delay". In software development the main cost of delay is due to forgetting how things work. As we saw above, introducing a delay between two "tightly-coupled" tasks interrupts one's train of thought.

This is a major problem in debugging. It's much easier to fix a bug if it's discovered while you are still working on the code. Fixing bugs months, weeks or even days later is tedious, time-consuming and error-prone. Further, you might have to do thorough regression testing to ensure that the change does not introduce new bugs - which is a cost of rework (see below). Also see (JIT Testing) for more on why it is better to test ASAP.

Cost of Rework

The design of manufactured goods changes occasionally to address design flaws, for reasons of fashion, and even to add enhancements. For example, if it is found that two parts do not fit together reliably then a change might be made to the way they are joined, such as adding a longer thread to joining two pipes. If the manufacturer has thousands of one of the parts in their warehouse then these will have to be thrown away and remade to the new specification.

In software development the problem of rework is much worse because things tend to change often. If you do something before it's needed you will probably have to redo it. I will now use the example of designing software (but the problem of rework can be found in other areas of software development such as the need for regression testing).

the "best" solution
to the problem
evolves
as developers
have more time
to consider alternatives

One of the most serious problems with the Waterfall methodology is the separation of the design and coding phases. Usually when it comes to implement the design it is no longer even close to what is really required. There are many reasons for this which I discussed in detail last October (see Change). In brief, the problem to be solved (ie, what is required) evolves over time as the customer gains more insight. Furthermore, the "best" solution to the problem evolves as developers have more time to consider alternatives.

Proponents of the Waterfall model say that the design is not cast in stone. Even so, the problem is that to maintain the design document according to the current best solution requires a continuous rework. Moreover, it is human nature for the designers not to want to throw away all or part of their original design upon which they labored so intently.

So with a large up-front design the alternatives are:

1. put a lot of effort into maintaining the design which requires to a lot of rework
2. put up with a bad design which causes major problems as the code is modified

Generally, in traditional waterfall projects the second option is used, not by any conscious choice, but because it is easier. This means that the design is obsolete before the code is written. In fact parts of the design may be obsolete before the design is finished. In Agile development this is addressed by postponing design until it is required - sometimes called JIT-Design.

Summary

The advantage of JIT is in bringing together activities that are related. In the manufacturing industry (where it was invented) this means bringing the activity of producing a product closer to the activity of producing its component parts.

In software development it is similar but it can be applied in more ways. One of the most important is taking the Agile approach of not having a separate design phase followed by a coding phase but instead using JIT-Design. A similar one is to test code as soon as possible, of which TDD is the extreme example.

JIT is one example of a more general principle that I have called DIRE (Don't Isolate Related Events or Entities). I will discuss DIRE in detail next week.