Any project or software includes potential risks. Will it do the job or fail? Will it leak user information? Will it serve as a springboard for attacking other systems? When you realize the need to learn how risky your software is, there are a number of approaches to assessing that risk. If a piece of… Read More »
You might wonder if code review is necessary if your team practices pair programming. (Assuming that your team does either code review or pairing.) Pair programming was originally one of the practices pushed by Extreme Programming (XP). The reasoning was pretty straight-forward, if we assume code review produces better outcomes, more frequent code review should… 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 Art of Readable Code Dustin Boswell and Trevor Foucher O’Reilly Media, Inc., 2012 When I saw this book, it seemed like a great idea. I’ve spent my entire career with legacy codebases, trying to make them better. A book that covers ways to make code more readable, and therefore, more maintainable is a wonderful… Read More »
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 »
This is another post in my intermittent series of Best Practices Gone Bad (BPGB) Today, we are going to take another side-step into version control. Most development groups use version control of some form. Whether you prefer Subversion, Git, Mercurial, Bazaar, Clear Case, or any of the many others, version control is an important technique… Read More »
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 »
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 »
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 »
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 »