Any time you have a long-term data structure, it’s important to have some form of unique identifier used to look up or recognize the structure. It doesn’t matter if the long-term data is a database record, a document in some form of storage, an object, or whatever. If the data lives for a while, you’ll… Read More »
One approach for design trade-off is between Until recently, I tended to treat the second and third as the same. With some more thought, I’ve convinced myself they are not.
I see a lot of development advice that assumes the developer is working on a green field application. Many of the tools that “make a developer’s life easier” are also designed mostly for use in creating new applications. Most of my experience as a professional developer (or whichever title you prefer) has been improving and… Read More »
Over the years I have noticed a habit among some developers that I’ve come to call Aphorism Driven Development. Many best practices are taught and remembered through the use pithy statements. Although these statements are easy to remember, they can’t capture the full context and connotations of the practice in question. If someone never learns… Read More »
Any solution to a problem involves trade-offs. One of my managers a long time ago used to be fond of saying some variation of There are an infinite number of solutions to a problem. A subset of those will work. A subset of those will work well. A subset of those are actually worth doing.… Read More »
It’s time for another post in my intermittent series of Best Practices Gone Bad (BPGB). This time we’ll cover the dark side of the Single Responsibility Principle (SRP). According to Robert Martin: A class should have one, and only one, reason to change. The basic concept is easy. Every object or method should be responsible… Read More »
The comments from Ian and rlb3 have made me think a bit more on what I said last time about Chronistic Coupling. One thing I didn’t make perfectly clear is that I’m not advocating avoiding Chronistic Coupling at all costs. Any real system will require some amount of Chronistic coupling. The key design point is… Read More »
I recently been studying software architecture and have had a minor epiphany. My assumptions about code complexity may have been unnecessarily pessimistic. From my experiences in software development, I have observed that more powerful or more robust systems are naturally more complex. A side effect of this observation is that beginning to do development on… Read More »
I was reading The JavaScript Phrasebook on Safari and ran across one of my favorite pet peeves when people write about Web technologies. Cookies are not a specific browser technology, but a mechanism in the client/server model to overcome one major shortcoming in the HTTP protocol. HTTP is stateless, which means that the protocol does… Read More »
Recently, Joel Spolsky wrote about Don Norman’s article Simplicity Is Highly Overrated. Joel used this as a springboard to another talk of how simplicity doesn’t matter in Joel on Software: Simplicity. He referenced and expanded on his views from Strategy Letter IV: Bloatware and the 80/20 Myth. As I’ve said before, I often find Joel’s… Read More »