Jidoka in Software Development Emanuele Danovaro, Andrea Janes, Giancarlo Succi Center for Applied Software Engineering Free University of Bolzano/Bozen, Italy {emanuele.danovaro, andrea.janes,

2 Emanuele Danovaro, Andrea Janes, Giancarlo Succi: Jidoka in Software Engineering Agenda Lean Thinking A Jidoka Framework Overview Components Conclusions

3 Emanuele Danovaro, Andrea Janes, Giancarlo Succi: Jidoka in Software Engineering Lean Thinking Initiated by Toyota when Ford was dominating the market using mass production. Initial idea: produce cars of different type on the same production line with similar costs and quality as obtained using mass production.

Emanuele Danovaro, Andrea Janes, Giancarlo Succi: Jidoka in Software Engineering 4 The starting point Time

Emanuele Danovaro, Andrea Janes, Giancarlo Succi: Jidoka in Software Engineering 5 Lean Thinking Strategy 1: Removing Muda Time Set-up JIT delivery Stock

6 Emanuele Danovaro, Andrea Janes, Giancarlo Succi: Jidoka in Software Engineering Lean Thinking Strategy 2: Use Jidoka to ensure quality to ensure quality Machines that can detect a problem with the produced output and interrupt production automatically ("Quality at the source")

Emanuele Danovaro, Andrea Janes, Giancarlo Succi: Jidoka in Software Engineering 7 Examples for Lean Thinking in Software Engineering ?Agility Automatic Testing Refactoring

Emanuele Danovaro, Andrea Janes, Giancarlo Succi: Jidoka in Software Engineering 8 Jidoka Framework Plan Do Check Act

Emanuele Danovaro, Andrea Janes, Giancarlo Succi: Jidoka in Software Engineering 9 Part 1: Notifying stakeholders

10 Emanuele Danovaro, Andrea Janes, Giancarlo Succi: Jidoka in Software Engineering Interrupting software production Alerts shown in the development environment shown in the tray area Deny check-in Level of seriousness

Emanuele Danovaro, Andrea Janes, Giancarlo Succi: Jidoka in Software Engineering 11 Part 2: Identifying problems

12 Emanuele Danovaro, Andrea Janes, Giancarlo Succi: Jidoka in Software Engineering Stopping software production We need rules to decide whether a software artifact is ready to proceed to the next production step Rules use collected measurements to evaluate if a situation is critical or not evaluate which kind of alert to fire Define data collection needs

13 Emanuele Danovaro, Andrea Janes, Giancarlo Succi: Jidoka in Software Engineering Finding good rules Align rules to busines goals Create rules that are understood as useful by stakeholders Alignment involving stakeholders in setting the goals before actual implementation has been found to improve organizational performance GQM

14 Emanuele Danovaro, Andrea Janes, Giancarlo Succi: Jidoka in Software Engineering Examples for rules Bad smells in code Shotgun surgery (on a development level or also across the team) Workflow conformance Verify if software is developed test-first Verify if software is released within a maximum time frame

Emanuele Danovaro, Andrea Janes, Giancarlo Succi: Jidoka in Software Engineering 15 Part 3: Collecting data

Emanuele Danovaro, Andrea Janes, Giancarlo Succi: Jidoka in Software Engineering 16 Measurement Probes Inputs Activitie s Outputs

17 Emanuele Danovaro, Andrea Janes, Giancarlo Succi: Jidoka in Software Engineering Inputs Main cost driver typically effort Time spent editing artifacts like code or documentation We built probes that track the time spent within IDEs like Eclipse, Microsoft Visual Studio, Sun NetBeans, etc., and personal productivity suites like OpenOffice and Microsoft Office. We allow users also to enter effort manually

18 Emanuele Danovaro, Andrea Janes, Giancarlo Succi: Jidoka in Software Engineering Outputs Output consists of artifacts like code and documentation Properties can be observed to determine the quality: dynamically or statically dynamically: execute and report problems statically: verify source code quality using size, complexity, and object oriented metrics and report problems CruiseControl Source code metric tools

19 Emanuele Danovaro, Andrea Janes, Giancarlo Succi: Jidoka in Software Engineering Activities Identifying activities is not straightforward, it depends on the specific problem

20 Emanuele Danovaro, Andrea Janes, Giancarlo Succi: Jidoka in Software Engineering Activities We adopt a rule based approach to decide if an activity took place or not Rules can be updated "a posteriori" and all events can be re-evaluated again The output of this component is the sequence of identified activities, the respective timestamps and users.

21 Emanuele Danovaro, Andrea Janes, Giancarlo Succi: Jidoka in Software Engineering Conclusions The idea to continuously monitor software artifacts and to alert the developer of possible mistakes or problems is not new Which are the novelties?

22 Emanuele Danovaro, Andrea Janes, Giancarlo Succi: Jidoka in Software Engineering Conclusions Novelties We measure not only the artifacts produced but also the resources used as well as the activities performed We use rules to build quality into the process, i.e., to enforce these rules without the need of a person to constantly check them

23 Emanuele Danovaro, Andrea Janes, Giancarlo Succi: Jidoka in Software Engineering Conclusions Novelties (continued) We see a dominance of the "pull" paradigm (stakeholder uses tool to analyze software development process) We want to promote a "push" paradigm (tool autonomously analyzes software development process according to predefined rules and notifies stykeholders)

24 Emanuele Danovaro, Andrea Janes, Giancarlo Succi: Jidoka in Software Engineering Conclusions Further research is needed to Which types of knowledge can be build into the process in the Jidoka way Which are the best ways to interrupt software production

Thank you for you attention!