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 »
I have recently being seeing references online to the concept of Technical Debt. The concept is an attempt to explain to business and management types some of the downside of overly complicated designs, lack of testing infrastructure, and quick-and-dirty code written to meet a deadline. In the past, I’ve had trouble explaining the difficulties working… Read More »
Several of the past few essays have focused on the notation aspects of programming languages. The major benefit of a notation is making what you want to say concise without losing it’s power in the process. To use an example from an earlier essay, supporting the use of normal algebraic notation for working with matrices… Read More »
Recently, I’ve been taken with the idea of programming languages as notation. When most people look at a programming language, they see syntax and possibly an underlying paradigm. I see the same, I just find the idea that each language also provides a unique notation for expressing ideas quite appealing. Lately, I’ve been thinking about… Read More »
I recently finished reading Eric Sink on the Business of Software. I had read many of the essays before and, in general, I like what Sink has to say. I’ll freely admit that he knows a lot more about the business of software than I probably ever will, and I’ll normally take his opinion over… Read More »
I probably shouldn’t be, but I’m surprised how often I have heard the statement We can’t do X in our environment… where X is one or more of the following: version control automated testing unit tests design testing object oriented programming bug tracking warning-free compiles In almost every case, the person has claimed to understand… Read More »