The Duct Tape Programmer Posts (Joel and Bob)

What is the Duct Tape Programmer? He is the smart, pragmatic Keep It Simple Stupid (KISS) software developer, whose top priority is to ship as soon as possible a "good enough" product (but not garbage) that satisfies the users needs. At least that's my summary from the original "The Duct Tape Programmer" blog post, by Joel Spolsky and Uncle Bob's comments on that post.

Some main points from both of these posts:

• Keep it simple. Using advanced, usually more complicated, tools and designs (e.g. COM, multithreading, C++, templates) only when absolutely necessary. Be careful of over using a tool and of over engineering the solution.
• Good (smart) software developers know when the aforementioned tools are needed and when to avoid them, and are not afraid to make the decision to use or not use them, or assert there views on the matter.
• Be pragmatic: "A 50%-good solution that people actually have solves more problems and survives longer than a 99% solution that nobody has" [Joel].
• One of the most important, perhaps the most important, feature of a (software) product is to ship the product as soon as possible. "It's great to rewrite your code and make it cleaner and by the third time it'll actually be pretty. But that's not the point --- you're not here to write code; you're here to ship products" [Jamie Zawinski, from Joel]. Nevertheless, don't ship garbage: "The programmer who spends weeks building the perfect structure does just as much harm to the project as the programmer who hacks a bunch of crap together. Neither have struck the balance that's required" [Bob]

Here are some follow-ups by Bob:
Echoes from the Stone Age
TDD Derangement Syndrome

Steve Yegge's Property List Pattern Summary

Steve Yegge has written an article entitled The Universal Design Pattern in which he describes in detail the Property List Pattern [1]. The key design elements of this pattern (as he describes them) are:

• It has the basic methods of a Map (using Java's terminology): get, put, has, and remove.
• Keys are generally strings.
• It has a pointer to a parent property list so properties can be inherited and overridden. In particular, certain operations, such as get, are applied on a child, but if the property is not found there, it is applied to the parent.
• Reading a property returns the first value encountered for that property, from the child if it exists, otherwise from its ancestor.
• Writing (and deleting) a property on the child only changes the property list for that child. When deleting a property that is inherited, it must be flagged in the child as deleted, not actually deleted. Otherwise, all siblings and the parent will have the property deleted.
• Properties can have meta-properties. Common ones include information governing types and access control (such as "read-only").

Why would you want to use this pattern? Yegge mentions several reasons, including (1) it is very scalable, so it can be applied to single classes or used as part of a larger framework, and (2) it enables extensible systems. Yegge also describes several issues with this pattern, two of which struck home with me. The first is its performance may be unacceptable for some applications, although Yegge describes many optimizations that can be made. The second is that it is subject to data corruption. For example, incorrectly spelling a key and then adding data. References [1] Steve Yegge, The Universal Design Pattern, 2008