Excessive Branch Use Causes Technical Debt and Increases Risk of Bugs

Agile practitioners already know that technical debt is that accumulation of unfinished work can cause projects to be late late late.  Building up a lot of technical debt is a problem because the debt needs to be payed before you can ship.  One way that debt can be accumulated is by profligate use of branches.  Avoid that at all costs!

Advertisement

The Urge to Merge

Concurrent development of software in a team relies on being able to merge the changes from each person successfully.  Experienced developers will already know this, but there are theoretical limits on how effective merging can be.

When are “best practices” less than best?

A “best practice” is a heuristic which is used to guide early stages of a project, in order to set some patterns.  When should you use them?  More important: when are you justified in ignoring a best practice?

Avoid Unnecessary Conditional Nesting

Simply put: try to make your conditions as flat as possible.  This makes them generally easier for the humans to parse and understand. 

Counting Source Lines

I rarely count the number of lines of source — but here is a quick script to do it.

Never leave ‘commented code’ in the source

Comments in code are good. But not when they consist of old code that has been commented out of the live code. Git rid of that.

Specifying Business Hours

Long ago I worked on a project where we needed to specify the hours that a business was going to be open, and to account for all the various difficulties around holidays and other special days. This is what we came up with and it still stands today.

Estimations – the eternal software problem

This post argues “Why We Should Stop Estimating” completely in software projects. It is very problematic.

Always Test the Software running in the Same Way that Customer will run it

Some programmers have their own favorite ways to run the software they are working on, that is run differently than the way that the customer will run it.  This is evil.  Programmer is not testing what the customer will get, but testing something else.  Is that good enough?

Error Message should be clear, plain, and direct

This post is about a real error message I received and puzzled through.  Luckily, because I was working with open source code, I was able to see a copy of the source, and only then did I understand what the message meant.  An error message should not require you to know and understand the source, in order to understand the message, and I think this is the root of the mistake that many programmers make.