This is an editorial rant thinly disguised as a Pattern... '''Your design looks good, but your running program is sluggish and bloated.''' Programming is hard. You learned that when you got out of school and became a programmer. You toil away and it starts to get easier. You are rewarded and you finally get to do a some ''design'' work. You start designing software and you learn that designing software is very, very hard. Fast forward... So, you finally think you got the hang of designing. Your most recent design is a beautiful pearl: It is simple, elegant and full of insightful patterns. Now, you implement the design, or get others to implement it for you, and you discover the recursive truth: Programming is Hard. Sometimes the best designs are ''abstract''. They avoid the details of the machine. The best DesignPatterns may not go into details like: * How fast is the CPU? * How much memory can you consume? * Is the disk fast enough? * Is the network fast enough? * How well do you take advantage of the OS features? Okay, so now you implement. You take the design and make it come alive in the ''real world''. It runs too slow; eats up too much memory... Of course the design is beautiful and (perhaps) the code is elegant. But, you don't take advantage of your platform's threads, disk caching, parallel processors or maybe you are not up to speed on the latest optimization, search algorithms. Design is a multi-discipline skill, you steal ideas from others disciplines: the architects, civil engineers, hardware designers, cognitive scientists, linguists, visual artists, etc. Coding is also a multi-discipline skill. Some of the skills you need involve computer science disciplines such as: operating system design, language design, networking, disk management systems, databases, assembly language, bug hunting, etc. ''Therefore:'' '''Know your tools.''' Master as many computer skills as possible. You '''will''' need to know how to tune your code to provide the best possible implementation of your elegant design. Tuning requires that you understand the environment in which your program runs in as well as the tools and hardware it interacts with. Don't do a good design and a sloppy implementation. If others do the implementation for you, make sure that they have a wide variety of skills. If they/you don't know the tools, your implementation will suffer. --- ToddCoram ''So, Todd, when you've finished all the Tuning, is your code TuningComplete?'' (I'll duck now) -- GarryHamilton --------------------------- '''Abstractions Are Illusions''' Beautiful, clean, elegant abstractions are still illusions. Don't be afraid to "cheat" ... that is the essence of programming. Each layer's cheating uses another layer's clean abstractions, and so eventually the application is not only fast, clean and reliable, but also *looks* good. For example, window managers for YEARS (I'll resist the temptation to name names) dogmatically painted each window in a stack using the painters algorithm, making the screen go flash flash each time something changed anywhere in the stack. The "stack of windows" is an *illusion* ... one cheat is, for example, to carve each window up into obscured and unobscured regions, then only repaint the unobscured ones (Pike's Algorithm). Another is DeferredUpdate... The point is, don't be afraid to hack, just be elegant and rigorous about how you surface your hacks to your consumers. ---TomStambaugh ---------------- Agreed. Cheating is what it is all about. After all, a good pattern is often a documented cheat that is applicable in a given context - isn't it? ---- Well, no; it's a little more. It is realising that the general problem is easier to solve than the specific one. If you feel the need to cheat, sit back and make an abstraction. Offer your backdoor (or whatever) in a general way. -- DaveHarris : I'm not quite sure. We're already talking about having an abstraction. The cheating is doing things 'incorrectly' as far as the abstraction is concerned, but that anyone on the other side of it can't tell you're doing it. For example, this is the main idea behind ReferentialIntegrity: it's not that you can't destructively modify something, it's that you can't break the abstraction when you do. --WilliamUnderwood