+972 52-548-6969
Reducing the Cost of Change
The concept of reducing the cost of change is a one of the core values of agile practitioners. In essence, it boils down to being able to make changes when we want them. Practices such as TDD and Iterations enable us to actually make changes without attaching a high price point for them. Some tools make change much easier than others. Using NHibernate, I can evolve my data model (and notice that I am explicitly talking about data models, not domain models. This is using NHibernate just for DTO mapping) much more rapidly than if I am using SP or code gen. If I have a real domain model, then that is even easier, in most cases.
But it is neither the tools not the practices that actually enable change. They are not even significantly responsible for reducing the cost of change. Beyond anything else, it is the will of the team to accept the pain of making the change and actually doing this.
I recently had a meeting in which I presented a demo of my current project. During the meeting, we hashed together what the application is doing, and in what way it is supposed to work. By that afternoon, I was able to get it to work using the new model. It involved breaking the entire application to pieces and restructuring it from the fragments. That wasn't pleasant, and it took me half a day of just trying, but it was done.
When I demoed it to the client in the same afternoon, he was quite pleased. I am not sure that I managed to covey the actual reason that I was able to affect such a change in the application. It doesn't have anything to do with technology, it has to do with a mindset. I would have been able to do the same if the application was written using ASP Classic with Stored Procedures, not as easily, maybe, but within roughly the same time frame.
That mindset, at least for me, starts from the first line of code. I treat each piece of the project as utterly disposable. Since I don't really care how each individual piece works, I am able to roughly sketch a fair amount of the application very rapidly, and then focus on each of the items in isolation, and replace that with a much better implementation. I think that I stated before that I tend to rewrite most of my application core at least two or three times before I am happy with them.
When you have disposable pieces, it is no big deal if you mess up and need to start over, because the whole project is structured in a way that allows you to do so. Going back to using my current project as an example, the algorithm used for the core part of the system is crap. I thought it up while being on a coffee break, and it is enough to demonstrate what the software is supposed to be doing. I don't really care, because the moment that I do need the real algorithm, I can drop it in (need to change the implementation of a single method).
But it is not just preparing ahead. It is also just plain willingness to do the work. About a year or two ago we (Castle Team) wanted to be make document all the public API for Castle Active Record. If I recall correctly, I did it by asking the compiler to break the build if we didn't have an appropriate XML comment for all out public types and members. There were some 800 build errors. And the only way to fix them was to go and document all of them. It took several days, but then it was done.
I don't think it was pleasant by any stretch of the word, but by trying we were able to make it happen.
So, to conclude, the best way I know to reduce the cost of change is to actually accept change. After that, the reduction will happen on its own.
Comments
"So, to conclude, the best way I know to reduce the cost of change is to actually accept change. After that, the reduction will happen on its own."
I think this is a very insightful...well, insight.
In other words, the biggest cost of change is an environment in which change is costly.
This is not being recursive here, this is a prophecy that creates itself.
When you treat change as cheap, you end up with an env. in which change is cheap.
At the least, I think there is enough experience to know that the inverse is true.
When you treat change as costly, you (more or less/usually/often enough) guarantee that it will be.
Which is a hard thing to sell. "We can't make changes like that because it has always broken things in the past, so we have to make it hard to make changes." Uh, yeah, but we can make change at least less costly. "But change has always broken things in the past....".
In some organizations, it is really hard to change this mindset because of the fear factor. And it isn't necessarily an irrational fear. It has cost a lot ot make changes in the past, so why should we trust that things will be different now?
Start small.
Prove that you can do things.
Build trust.
Work hard.
Nothing magical, I am afraid.
I'm guessing you've probably become so facile with the 'practice' you describe above, and can whip out code-on-demand at such a rate, it puts 'frameworks' just close enough within your grasp that you're always tempted to try and whip one out. Seems to work out pretty well for all of us when you do...
I had kind of a lengthy reply, so I posted it in my blog instead(yes, yes a very cheap shot at publicity ;) )
heres the link:
imistaken.blogspot.com/.../...nge-fear-factor.html
Ayende, the key to what you were doing is that you are alone on the project and know perfectly your code, also the project is young and its structure is fresh in your mind.
Patrick,
In this project, you are correct.
But I did the same in projects of > 100K LOC and a team of developers that were able to work while I made this modification.
In another instance on a decade old, > 1 M LOC, with a big team. I was able to spend a week refactoring some of the internals of the application, and just merge it into the trunk without anything either a) noticing very much b) feeling any sort of pain.
The key to reduce the cost of change are:
-A way to check automatically for correctness regression, such as unit test and contract
-A code easy to understand, i.e well structured (high cohesion / low coupling)
On this second point being alone and coding with disposable pieces can help a lot indeed;
"...I am able to roughly sketch a fair amount of the application very rapidly, and then..." and then management declares the project as ready for production and all subsequent changes should be treated as bug-fixes :)
Alex,
I had that happen to me once.
You would be surprised how easily you can get "incomplete" across with very simple UI.
I use things like red border around things, and that gets the point across very nciely.
i think change and the cost of said change is relative
if we are talking about something like an algorithm then sure... i can see change being easy
a component here... a new service there... etc...
if we are talking about a process or a technology then the factors change from my ability (and the code / infrastructure willingness) to the acceptance, understanding, and willingness of the team or stakeholders
if you have a team who is unwilling to change or doesnt have the same drive then you have a very costly change ahead of you
imagine moving from webforms to mvc, datasets to DTO, home grown javascript to jQuery, implementing ajax, wcf, a DSL, etc... (i could go on but... you get the picture)
i can sell a CIO, CTO, or board members that these changes are the way to go and prove ROI, extensibility, and scalability
if my team isn't willing to take on these responsibilities or don't want to change themselves because it is too hard... the cost of these changes become very expensive indeed
just my two cents
(i have been burned by this very topic in the past... does it show?)
I don't believe you. That is, unless by 'roughly' you mean rounded to the nearest week, perhaps? :)
Your point is a good one, though, aside from that one bit of hyperbole. :)
--Stuart
Roughly means a couple of days, maybe half a week.
Still within the same time frame.
@Oren
I might have to start trying that. Crap UI = Not-done-yet so don't deploy this crap to production.
I run into this a lot at my company. Our CTO is our CFO and to him everything should take 2 days to do. Sure, I can have a demo together in 2 days. I wouldn't want that to ever go live though. Tends to stay live once it does :(
Comment preview