It’s not a big surprise that most programmers feel that the most important result of writing code is the code itself. Other people might argue that while the code is important, other things are more important: Results of the execution of the code Money made by selling the program Business value realized by running the… Read More »
Every bit of code we write is the result of trade-offs. Some seem like no-brainers: what language to use, which paradigm to use. Others are more subtle: how important is speed/maintainability/memory, fail fast or never fail, fix a bug quickly or rewrite to prevent that class of bugs. One of the big trade-offs is between… Read More »
There are a few reasons that Best Practices get specified in a profession. Provide standards for judging proposed solutions. Provide cover for unforeseen circumstances. Provide a starting point for discussions to improve the state of the art even more. Help more junior people make better decisions before they fully understand the field. Applied to software,… Read More »
A few years ago, I first became aware of the concept of Value Objects. Unlike most objects you might use in a design, the identity of a value object is completely unimportant. Instead, the value of the object is all that is important. This leads to a couple of interesting design decisions: Value objects tend… Read More »
This is yet another in the Best Practices Gone Bad series of posts. Around two decades ago, the book Design Patterns (often called the Gang of Four, or GoF, book) was published. This book introduced a large number of programmers to a new approach to thinking about solutions. For those who are not familiar with… Read More »
This is the second entry in the Best Practices Gone Bad series of posts. One principle that a lot of developers have been holding to lately is DRY. In The Pragmatic Programmer, Hunt and Thomas state the DRY principle as: Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. This… Read More »
As a first post in the Best Practices Gone Bad series, I figured I would take an simple example from a previous job. An Example In that position, there were two best practices that intersected to generate unreadable code. The first practice was expressive names. All names of variables, classes, and methods were required to… Read More »
Most professional fields develop a set of best practices that help people in the field produce consistent solutions to similar problems. Any given problem has an infinite number of potential solutions, some of those will actually work. Fewer still will work well. Best practices tend to prune some of the bad solutions by pointing out… Read More »
In the last post, we had begun streamlining novice Ned’s problem. Our current solution has some problems. The most annoying is the need to type a password for each server that we are going to write to. High-level Description We are using scp to do the copy, so the login is controlled by the SSH… Read More »
In the last post, we spent a small amount of time understanding a problem faced by our hypothetical novice programmer, Ned. As a reminder, let’s revisit Novice Ned’s breakdown of the problem. Launch FTP Connect to the host Log in with the foobar user and password Change to the appropriate remote directory Put each of… Read More »