(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)
Wednesday, May 30, 2007
Wil Shipley on writing Not So Big Applications
Actually, he was talking about not making your code more flexible than needed. And he gives a really great argument for writing the briefest possible code and then only making it faster, more robust, more featured, or anything else after you establish a need by testing it.
Here’s his take on writing classes for libraries when you ought to be writing application software:
If you find yourself writing a class for your “library,” then:
Actually, he was talking about not making your code more flexible than needed. And he gives a really great argument for writing the briefest possible code and then only making it faster, more robust, more featured, or anything else after you establish a need by testing it.
Here’s his take on writing classes for libraries when you ought to be writing application software:
If you find yourself writing a class for your “library,” then:
- You’re not writing your application, which is where you make your money,
- You’re writing something that you’re hoping Apple1 will someday replace, which is a sucker’s game,
- You’re writing code you are going to have to test SEPARATELY from your app, because BY DEFINITION you’ve added functionality you didn’t need,
- You’re never going to really know which methods in your library work and which ones don’t (eg, which ones are used in shipping programs) because you don’t have user base that a company like Apple2 does (and witness how buggy even their under-used frameworks are),
- You’re writing code that is going to need documenting (or some other way to comprehend it), so you’re requiring yourself and everyone at your company to understand not JUST all of Apple’s APIs3 (which are, at least, SOMETIMES documented) but also yours, and, possibly worst of all,
- You are attempting to predict how your application’s needs will change in the future, and spending time NOW on your guess, instead of shipping the damn application, getting feedback, and THEN making changes.
- Or Apache. Or Microsoft. Or BEA. Or Linus Torvalds. Or whomever. The point is, if your existing OS or framework or language or tool doesn’t do it, don’t extend it unless you really need it, preferably in two different places.
- Or Apache. Or Microsoft. Or BEA. Or Free Software. or…
- See one and two above.
Comments on “Wil Shipley on writing Not So Big Applications”:
<< Home
Damn skippy, this is how I think of IBM consultancy "One size" fits all framework. They spent all the time developing the "library" that can't be adequately tested and has to be supported now that they are gone. It detracts a great deal from the "Write the application" tasks I could be doing.
<< Home
