Working at the right level of abstraction

Eric Sink writes about the .NET Abstraction Pile in SourceGear’s Vault product. This is a nicely written article that highlights some of the issues that programmers face every day. The issue of complexity that comes with abstraction is a large motivator for the XP rule of “Do the simplest thing that can possibly work”. Don’t add that complexity on before you actually need it. Eric’s experince with their SOS Collab product sounds exactly like the kind of problem that comes up when you try to overengineer and get the most perfect and flexible solution.

I’ve been reading about O-R mapping tools recently, and have read a lot of positive comments about Hibernate. A major competitor to Hibernate is Jakarta OJB, which adds layers of abstraction in order to support ODMG and JDO interfaces. Many of the positive comments about Hibernate have praised it for being simple and fast, which is exactly the effect one would expect you would get by stripping away a couple of layers.

I find it interesting that he has moved from Java to .NET and found that .NET is “Java done right”. I’m definitely keeping my eyes on .NET, particularly as Mono gets up to speed. I’m not certain which layers of abstraction were contributing to their bug list, though. Java itself does not imply much of anything in terms of layers of abstraction. If he’s talking about Swing, certainly Swing has many layers. For doing web apps in Java, you can choose to go with few layers (HttpServletRequest, anyone) or many.