Ayende @ Rahien

It's a girl

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

jdn
11/13/2008 05:11 AM by
jdn

"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.

Ayende Rahien
11/13/2008 05:19 AM by
Ayende Rahien

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.

jdn
11/13/2008 05:25 AM by
jdn

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?

Ayende Rahien
11/13/2008 05:28 AM by
Ayende Rahien

Start small.

Prove that you can do things.

Build trust.

Work hard.

Nothing magical, I am afraid.

J Healy
11/13/2008 06:50 AM by
J Healy

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...

Patrick Smacchia
11/13/2008 08:33 AM by
Patrick Smacchia

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.

Ayende Rahien
11/13/2008 10:47 AM by
Ayende Rahien

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.

Patrick Smacchia
11/13/2008 11:27 AM by
Patrick Smacchia

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;

Alex Simkin
11/13/2008 02:12 PM by
Alex Simkin

"...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 :)

Ayende Rahien
11/13/2008 02:20 PM by
Ayende Rahien

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.

meisinger
11/13/2008 03:23 PM by
meisinger

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?)

Stuart
11/14/2008 04:37 AM by
Stuart

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. <<

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

Ayende Rahien
11/14/2008 02:51 PM by
Ayende Rahien

Roughly means a couple of days, maybe half a week.

Still within the same time frame.

Lucas Goodwin
11/15/2008 03:20 PM by
Lucas Goodwin

@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 :(

Comments have been closed on this topic.