Books about Lean Manufacturing are full of stories of ‘kaikaku’ events – dramatic and theatrical process improvement kick-start episodes, designed to get the workforce shaken and stirred into believing that significant improvement is possible. Julian commented that software is ‘invisible’, so it’s very hard to see the workspace. I agree that the ‘invisibility’ of the code makes it hard to engineer the drama of kaikaku events, but there are a few obvious things one can do immediately when faced with trying to initiate process improvement. Here are some kaikaku activities I’ve been able to do (depending on the maturity – or otherwise – of the shop in question):
- ‘release’ the current code
- install the code into a CM repository
- get the build automated
- get the build time under an hour
- get just one test running every hour
- run a linter to identify unused code, and then remove it all
- run a dependency checker to identify loops among classes and packages, and then collapse each loop into a single module/package
Do you have any other successful kaizen kick-start tactics?
[Update: creating a daily build isn’t always a benefit just by itself…]
Further update, 13-feb-06:
The original content of this post was lost and corrupted sometime during 2005. But I was able to find it again today, thanks to the wonderful wayback machine
Running a “linter” could be expanded since such tools can check for a lot of things, especially duplication (i.e., Simian)
Pingback: the daily build « silk and spinach