Posts
1150
Comments
891
Trackbacks
1
A potential downside of Continuous Improvement

Something that the alt.net kool-aid drinkers and Software Kraftsmen people talk about is the notion of ‘Continuous Improvement.’  I will go ahead and shock some people by stating for the record that I am generally in favor of continuous improvement (I know, who knew?).

An obvious potential downside of Continuous Improvement is that people sometimes confuse ‘Change’ with Continuous Improvement.  Doing something different because you’ve read a blog post of why doing Y instead of X is better, doesn’t actually mean Y is better than X.

But, let’s leave that aside.  Let’s assume that you have decided as a developer to do Y instead of X, and Y really is better than X. 

When you are in a mindset of continually improving, it can be very difficult to resist the urge to refactor a code base that does X to do Y.  You look at how you did X, and you just know it would be better to change it to do Y.  Since refactoring is a key part of being a decent developer, learning when you need to resist refactoring is important.

I wrote a code base a few months ago, doing X.  In the interim, I’ve come to believe that doing Y is better.  In the abstract ideal, refactoring the code base to do Y is the right thing to do.  But doing X worked.  Refactoring it to Y won’t make the code base meet its functional requirements better (since they are already met).  It might, in certain scenarios, make potential future work easier to do.  The time it takes to refactor a currently working system has to be balanced with an estimate of what improvements in future potential work will actually occur, and, in my experience, this is hard to do.   Why?

Within Kanban, and other concepts, there’s a notion of ‘local optimization’, where (paraphrasing crudely), it is easy to make the mistake of thinking that improving the development process is an overall improvement.  As developers, it’s hard to think otherwise.  Whenever you discover a development improvement, it can be very invigorating.

But consider…suppose it takes a week to develop a code module, and then takes a week to validate that code module through your QA process.  If you find a development improvement that allows you to develop a code module in a day instead of a week, what can happen is that you’ve now increased the flow of development work into their queue.  Suppose, as often happens, that someone is tracking the time it takes for completed development work to be validated by QA.  You’ve now screwed up that tracking, and so some management report that used to report a smooth transition between development and QA now reports that QA isn’t doing their job (or whatever).  By making things better, you’ve made things worse.

Developers like to reduce friction (well, some do).  It’s hard to suggest that they shouldn’t.  But, you have to keep in mind the overall software development flow.  Ideally, since your development of code modules now takes a day instead of a week, those developers should work on helping the QA team improve their processes so that validation can be reduced to a day as well.

Work on continuous improvement.  Learn to differentiate between doing something different and improving.  Figure out how it impacts all parts of the overall software development flow, and adjust accordingly.

posted on Wednesday, October 13, 2010 10:43 PM Print
Comments
No comments posted yet.

Post Comment

Title *
Name *
Email
Url
Comment *  
Please add 1 and 6 and type the answer here: