Comments on: Design for testability http://silkandspinach.net/2004/07/27/design-for-testability/ development, by example Tue, 07 Feb 2012 05:40:29 +0000 hourly 1 http://wordpress.com/ By: if… « silk and spinach http://silkandspinach.net/2004/07/27/design-for-testability/#comment-1223 Tue, 26 Jun 2007 08:16:56 +0000 http://silkandspinach.wordpress.com/2004/07/27/design-for-testability/#comment-1223 [...] solution. (One thing that would now ring alarm bells with me: the code failed Mike Feathers’ test, in that it was well-nigh impossible to write unit tests for any piece of the code. In fact, most [...]

]]> By: Kevin Rutherford http://silkandspinach.net/2004/07/27/design-for-testability/#comment-127 Tue, 27 Jul 2004 10:18:05 +0000 http://silkandspinach.wordpress.com/2004/07/27/design-for-testability/#comment-127 Hi Julian,
I agree with you – the analogy between the gemba and the codebase is striking, and potentially very powerful (the Agile NW group also discussed it at last week’s meeting). And I agree that the ‘invisibility’ of the code makes it hard to engineer the drama of kaikaku events.

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, and then collapse each loop into a single module/package

All except the last can create positive shockwaves…

]]> By: julian http://silkandspinach.net/2004/07/27/design-for-testability/#comment-126 Tue, 27 Jul 2004 02:04:04 +0000 http://silkandspinach.wordpress.com/2004/07/27/design-for-testability/#comment-126 When I was reading “Lean Thinking” by Womack a while ago, the source code as the production floor jumped out at me for the first time. It makes a very good analogy when comparing software development to traditional production systems.

It also explains why the kaikaku events (radical improvements) are harder for consultants doing software improvements vs manufacturing improvements. You can walk into a factory and /see/ the machines at work and discover waste. Its obvious where to start. Because the waste inherent in the source code (eg your example; how hard is it to develop tests) is harder to identify, its less obvious where to start the improvement programme. You are really forced to start with kaizen (continuous incremental improvement) until an understanding of the code is reached.

Basically: refactoring = kaizen.

-J

]]>