Some Trade-offs on Code Design
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.
Tag Archives: design
The Dark Side of Convention over Configuration
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 »
Aphorism Driven Development (ADD)
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 »
BPGB: Single Responsibility Preoccupation
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 »
Secure Development: Threat Models
There are numerous issues that you need to consider when developing almost any software. If you are working on software that connects to a network in any way, security is yet another thing that you need to consider. To introduce this series on Designing Secure software, I’m going to talk about something that normally gets… Read More »
Review of Release It!
Release It! Michael T. Nygard Pragmatic Bookshelf, 2007 I’ve had this book on my shelf for a few years, and finally got some time to start reading it. I should not have waited. Nygard takes the position that the life of a piece of software actually only begins when it is released. He spends a… Read More »
LCDC: Rising Tide
I began this series on Least Common Denominator Code (LCDC) with The Myth of Code Anyone Can Read. In the posts that followed I attempted to show how this kind of code is not actually possible in a real development shop. I’ve shown how different code should be written for different audiences, and how real… Read More »
LCDC: Different Audiences Have Different Needs
In the last few posts, beginning with The Myth of Code Anyone Can Read, I’ve focused on what you can expect from your programmers in general. Of course, generalizing is what got us into this discussion in the first place, so let’s spend a little time not generalizing. When teaching new programmers, I always tell… Read More »
LCDC: Business Logic
In The Myth of Code Anyone Can Read, I introduced the idea that least common denominator code (LCDC) is not a goal anyone should aim for. Despite my assertion, I’ve seen a number of places where this is a requirement. Even if you don’t believe any of the other reasons for code to not cater… Read More »
LCDC: Developer Specialization
In The Myth of Code Anyone Can Read, I introduced the idea that least common denominator code (LCDC) is not a good approach to writing software. Among other things, this approach ignores programmer specialization that happens in any team of more than two developers. Mental Caching As a project becomes larger than one person can… Read More »