Ayende @ Rahien

Lucas Goodwin commented on Reducing the Cost of Change

Sat, 15 Nov 2008 15:20:48 GMT

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

Ayende Rahien commented on Reducing the Cost of Change

Fri, 14 Nov 2008 14:51:28 GMT

Roughly means a couple of days, maybe half a week. Still within the same time frame.

Stuart commented on Reducing the Cost of Change

Fri, 14 Nov 2008 04:37:29 GMT

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

meisinger commented on Reducing the Cost of Change

Thu, 13 Nov 2008 15:23:02 GMT

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

Ayende Rahien commented on Reducing the Cost of Change

Thu, 13 Nov 2008 14:20:19 GMT

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.

Alex Simkin commented on Reducing the Cost of Change

Thu, 13 Nov 2008 14:12:19 GMT

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

Patrick Smacchia commented on Reducing the Cost of Change

Thu, 13 Nov 2008 11:27:44 GMT

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;

Ayende Rahien commented on Reducing the Cost of Change

Thu, 13 Nov 2008 10:47:04 GMT

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 commented on Reducing the Cost of Change

Thu, 13 Nov 2008 08:33:24 GMT

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.

Lior Friedman commented on Reducing the Cost of Change

Thu, 13 Nov 2008 07:03:23 GMT

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](http://imistaken.blogspot.com/2008/11/cost-of-change-fear-factor.html)

J Healy commented on Reducing the Cost of Change

Thu, 13 Nov 2008 06:50:18 GMT

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

Ayende Rahien commented on Reducing the Cost of Change

Thu, 13 Nov 2008 05:28:52 GMT

Start small. Prove that you can do things. Build trust. Work hard. Nothing magical, I am afraid.

jdn commented on Reducing the Cost of Change

Thu, 13 Nov 2008 05:25:53 GMT

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 commented on Reducing the Cost of Change

Thu, 13 Nov 2008 05:19:11 GMT

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 commented on Reducing the Cost of Change

Thu, 13 Nov 2008 05:11:14 GMT

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