Abstractions and Drowning in Them
Written by
on
in
Snaking.
Have been spending a lot of quality time with Dojo this weekend, and it's making me think about abstractions again. The pattern seems to repeat itself again and again; you dive into a deep pool of someone else's abstractions, you spend days working out all the little undocumented assumptions and missing pieces, eventually you get back to the surface and think "hey, not so bad", so you dive back down and try to build something just a little past what's been done before, something trivially different, but which should be an obvious extension of what's there.
It takes a bit longer than you'd thought it would. You keep having to swim just a bit lower in the murky waters. You know it's possible. You can see, loosely, where you have to go... but you really should get back to the surface and get back to work on the problems of today. Deep in the murky depths you begin to realize that the abstractions either just aren't going to let you do this, or that to do it you'd have to spend far more time extending the abstractions than you would re-implementing them.
You've sunk far more time into exploring the waters than you should, and now you have to decide what to do. Do you pull the plug and drain the pool? Do you poke just a bit more to see if maybe there's some hidden corner where the tasks you need to do are waiting with a scuba tank? Or do you just abandon the attempt, hack this little bit and get on to the next task?
Glub.
[Update] In case anyone is interested. Turns out this weird behaviour was a Firefox 3.0.5 bug that other people have run into and Firefox 3.0.6 will fix. If I'd been more confident of my Dojo/Javascript-Fu I likely would have figured that out a lot faster.
Comments
Comments are closed.
Pingbacks
Pingbacks are closed.
Mike C. Fletcher, the VRPlumber, is a philosopher of design turned computer programmer based in Toronto, Canada. He works primarily in the Python programming language, and maintains a large number of Open Source software packages. You can reach him at: mcfletch@vrplumber.com.
Phil Mayes on 12/23/2008 12:11 a.m. #
Oh, I think this is a fascinating and deep area. When I write code, I can write it for the situation at hand, or I can design it to accommodate future extensions - but which extensions? Multiple documents at once? Multiple views onto a single document? Multiple users on the same document? Other document types? Multiple languages? Threads? Porting to other machines? Using a different database? Accessing the data when at a different machine (ie travelling)? Importing other data? Running on small-screen machines like PDAs?
Supporting all of the above would make development very slow; the code harder to read, understand and change; and the program hard to test comprehensively.
I have to make a guess as to what direction the product is likely to go in, and code with that in mind.
Scott Pierce on 12/23/2008 9:48 a.m. #
What you describe above is why I abandoned Dojo for jquery years ago. It is that whole "easy versus simple" thing. I would get two steps forward and three back. I have to assume things have improved a bit however.
Mike Fletcher on 12/23/2008 10:44 a.m. #
YAGNI is rising in my list of "things that could be a mantra". I'm normally coding libraries, where YAGNI is often inappropriate, but when coding applications YAGNI + refactoring seems to be a reasonable approximation to an efficient approach...
Mike Fletcher on 12/23/2008 12:58 p.m. #
So far I haven't found any particular fault with Dojo, a few minor quibbles here and there, but nothing horrible.
The problem is really more one of working with someone else's abstractions. Coding in Mochikit (or JQuery IIRC) you are basically making your own abstractions, so you *know* what you've done (though someone you hire likely will not, and likely will have to work much harder to learn).
Standardization isn't free, but it's useful when you have half a dozen people working on the same code-base. (No conclusions here, just thinking out loud).