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 »
As you probably know, code is read more often than it is written. Anybody who has worked on code written by anyone else has probably wished that the code were more readable at some point. Writing readable code should definitely be considered a best practice. The problem comes when defining what you mean by readable.… Read More »
One of the design ideas that came out of the early days of the agile movement was YAGNI. As I have written before, this idea is push back against the tendency of many programmers to over-engineer or over-complicate our designs. We normally use some variation of the flexibility argument to justify this tendency. In fact,… Read More »
For the next entry in the Best Practices Gone Bad series of posts, I have a topic I wish I had thought of. In issue 125 of Overload magazine (Feb 2015), Sergey Ignatchenko wrote an article entitled Best Practices vs Witch Hunts. Sergey covers a somewhat different approach to how best practices go bad. He… Read More »
The past few generations of version control systems have really good support for branching. This feature allows someone to create a new line of development that is separate from the official main/master/trunk line of development. Changes made on a branch do not affect the main development until they are merged to the main branch. Shortly… Read More »
It is written We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. —Donald Knuth Most people forget the very next thing he said: Yet we should not pass up our opportunities in that critical 3%. Many developers have lost the original meaning of premature… Read More »
In some environments where I’ve worked, new features were being added and bugs were being fixed up until the very moment that the code was released. This obviously leads to problems where one change generates new bugs that we have not yet had time to find, much less fix. Consequently, another buggy release goes out… 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 »
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 »