Wed 7 Jan 2004
Check your framework at the door
Posted by dkaz under C#, Programming
Bill Venners’ outstanding interview with Anders Hejlsberg (lead C# architect)
brings back ghosts of many “framework” horror stories I’ve been exposed to in
my professional career.
It’s amazing how many ugly-ass behemoth frameworks are thrown out (or are
ripped to shreds at lunch time) as soon as the original developer moves on.
Build to your specs, people!!!
<Anders on C# and checked exceptions>
C# is basically silent on the checked exceptions issue. Once a better solution is
known, and trust me we continue to think about it, we can go back and actually
put something in place. I’m a strong believer that if you don’t have anything
right to say, or anything that moves the art forward, then you’d better just be
completely silent and neutral, as opposed to trying to lay out a framework.If you ask beginning programmers to write a calendar control, they often think
to themselves, “Oh, I’m going to write the world’s best calendar control! It’s
going to be polymorphic with respect to the kind of calendar. It will have
displayers, and mungers, and this, that, and the other.” They need to ship a
calendar application in two months. They put all this infrastructure into place in
the control, and then spend two days writing a crappy calendar application on
top of it. They’ll think, “In the next version of the application, I’m going to do so
much more.”Once they start thinking about how they’re actually going to implement all of
these other concretizations of their abstract design, however, it turns out that
their design is completely wrong. And now they’ve painted themself into a
corner, and they have to throw the whole thing out. I have seen that over and
over. I’m a strong believer in being minimalistic. Unless you actually are going
to solve the general problem, don’t try and put in place a framework for solving
a specific one, because you don’t know what that framework should look like.
UPDATE: At the time I was writing this entry, the C2 Wiki was down, but I had
a real urge to link my post to the PrematureGeneralization and
YouArentGonnaNeedIt pages.
January 8th, 2004 at 2:21 am
Sometimes I wonder if bash frameworks is just the current “cynics fashion.” Mind you, I’m not doubting your experience or the statements of Mr. Hejlsberg. I think you both make good points. I just find it odd that with the number of frameworks being written and *used*, I don’t see them getting more positive press.
How many frameworks have you used?
January 8th, 2004 at 6:10 am
Well, I’ve used EJB’s (certainly a framework in their own right) and Struts quite a bit. More recently I’ve been looking at much more lightweight frameworks - PicoContainer and Spring. The problem with frameworks is that by their very nature they need to be generic enough to be useable in a wide number of circumstances, but invariably get developed with a single use in mind. Those frameworks I mentioned have been developed, used and maintained by a large number of people, and so they work (to varying degrees) in a large number of circumstances.
Much of the home-grown framework development that goes is often a symptom of a wider developmental issue, that is code being written for future use rather than for right now. I’m a big fan of writing simple code - it makes it more maintainable so if you have to rework at a later date you can (this is one of the central tenants of eXtreme Programming). Gazing into a crystal ball to determine what someone will be doing with the code base later on can leave your API littered with unused, bloated code.
January 18th, 2004 at 10:00 am
I think that is more what I’d call “central strawman” of XP - this fear of unused code. I hear so much in the Agile community about all this work being done that isn’t used, but I see little to none of that in my career. I have seen much more damage and inefficiency caused by doing just what XP proposes - hack out the minimal piece and address it later. I’ve seen code written in very specific ways, then rewritten to generalize down the road over and over when a little thought and generality up front would have made all the rewrites unnecessary.
What gets ignored in XP world is that there are times when writing code gets an “economy of scale.” By doing all of a certain kind of code while you are in that zone, you get it done and out of the way which obviates a need for context switching. If you write it, test it and can take it as a given, that’s a closed issue and you don’t have to fool with it again. I find that leaving my high-level presentation code to go down into debugging or writing low-level code is highly inefficient, and I lose a lot of time reorienting myself into the issues of that chunk of the product. I’d rather do it all at once while I’m working there. I might write code this isn’t used at the moment or ever, but that takes less time than context switches later on.
The big problem here is with any sort of “you must do it this way” advocacy. I’ve worked with dozens of programmers, and all of them had different ways of thinking and working. Anyone who says there is one true way to do it and failing to do that makes you a lesser being is just being a prick.