A mini review of Hibernating Rhinos - Episode #2

The webcast and code (is there code on this one?  I forget) can be found here.

I'm assuming everyone who reads this knows who Ayende is, what MonoRail is, and all that.

This is a mini-review, both because it is short, and because the main point (assuming there is a point) isn't really about the webcast at all.

Most of my observations are admittedly shallow, but there you go.

Ayende's general point is to attempt to show the difference between programming a simple example using WebForms vs. using MonoRail, and why MonoRail is superior.

There are those points of enjoyment where he says things like (think these are direct quotations, but will use scare quotes in case I get them wrong), "Yada yada yada"..."Run, rinse, repeat"..."What the hell just happened?".  Watching him code is fun and enlightening.  As I've mentioned previously, it's a glimpse at watching a master in action.

The 'funniest' thing about the webcast is that I think he does nothing to prove his main point (that MonoRail is superior) precisely because he goes step by step through the process of showing how to enable essentially identical functionality in both WebForms and MonoRail, and does it quite well. 

What I think he wants to do is to show how you can implement the 'simple' solutions with WebForms, and do it faster than you could with MonoRail, but once you get beyond the simple solutions, WebForms are too fragile and unmanageable, as compared with the extensibility and proper separation of concerns that you get with the latter.  And he makes a comment towards the end about how (paraphrasing) "I hope I've shown you how the Monorail approach is more maintainable," etc. except he hasn't actually done anything of the sort.  Other than a comment about how the WebForms approach implements a business rule in the wrong place (which I think I might disagree with....I think the resulting UI difference should be in the place that it is in the WebForms example, but don't hold me to that, I don't feel that strongly about it), pretty much every example shows how it is quicker to implement functionality in WebForms.  Or at least as quick.

Now, a lot of this depends on how you define 'Maintainability" and I've talked about that concept on this blog in a couple of places (here and here) so I won't rehash all of that now.  I'm currently under NDA on a contract where the idea of maintainability that I think talks about is about as lacking as you can get (paraphrasing a recent conversation: "To fix this bug, the code change would take about 10 minutes"...."Yes, but the QA cycle would take 75 days"), so I *absolutely* get it. 

But the cost of maintainability is dependent on a lot of factors.  My limited sense of understanding suggests to me that the version of maintainability is solely focused on the 'if we had to make change x, how much would it cost" level, but that's only one factor.  If it takes a maintenance developer a week to change something that would otherwise take a day, but the pool of people who could make the quicker change is non-existent, what's the cost of bringing in that person, training them on how the system works, and then make the change, etc.  And there is a *significant* amount of code that is completely maintenance free, in the sense that you write it once, and you never change it.  This is especially true of ETL type code.  You get the vendor file format, you write the code needed to transform the data that comes from that vendor into your internal system, and then you are done.  The only maintenance you have to do is when the vendor decides to change the file format without telling you, which does happen.  But otherwise, you never have to make any serious, substantial changes.

Regardless of all that, I recommend that anyone watch the webcast.

posted on Wednesday, November 28, 2007 8:53 PM Print
# re: A mini review of Hibernating Rhinos - Episode #2
Ayende Rahien
11/29/2007 6:14 AM
Thanks for watching the screen cast.
About maintainability.
I don't think there is a case of who the next developer is going to be affecting the maintainability of the system.
Assuming an understanding of basic CS foundations and at least some experience, a maintainable code base will make it easy to make modifications to it.
No, it will no be easy the first time, but it will be easier the second time, and it will trivial in the tenth time.
# re: A mini review of Hibernating Rhinos - Episode #2
11/29/2007 6:46 PM
What if you have a reasonable expectation that there would be at most a first or a second time?

I know that many people will say "it'll never happen" but I'm quite confident it does.
# re: A mini review of Hibernating Rhinos - Episode #2
7/15/2008 5:50 PM
Half a year late but...

Ah, those who live in ivory towers.

I work on a 300,000 line monster (use to be significantly more, like 1/2M, but we've been beating away at it for 2.5 years) - and 2.5 years later I'm still learning parts of the system because it's so poorly designed, over architected, and undocumented.

I'm at about the 23rd time - it's easier, but definitely far from trivial - another guy who has been there 4 years still doesn't find certain parts easy.

So yeah...never assume just because YOU haven't been on poorly run projects an the the tenth time is trivial, that everyone has it that good.

BTW, to the author of this couldn't hit the nail more on the head if you tried about maintainability.

Post Comment

Title *
Name *
Comment *  
Please add 5 and 7 and type the answer here: