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! Continue reading

Don’t Suffer Poor Names

You know the problem: you write a method for one purpose and give it a name.  Later, it become useful for something else, or maybe you change it slightly to accommodate another use, or maybe some names change elsewhere making the current name obsolete.  You have all seen code where someone says that the name “is historical” or traditional.  This post is to say with conviction that that history is NOT interesting, and get rid of it.  Get a good IDE and change those names to be correct. Continue reading

We don’t need Programmers … we only need Designers

Today’s post is a reflection on a classic misunderstanding often made by people who don’t understand how software is produced.  This misunderstanding can be particularly harmful when held by management making decisions on team structure.  The full quote is: “We don’t need any programmers here.  There are plenty of programmers in India.  Here, we just need people who can tell programmers what to do.”  Let me explain why this is a classic management mistake. Continue reading

Partial Agile: No Such Thing

On several occasions in the past, I have heard software engineering management suggest that they would like to “try” an Agile approach by implementing it in part of a project.  For example one feature, a couple of team members, would work in an Agile approach, while the rest of the team works with a waterfall model.  Another manager told me they were using Agile, but instead of time-based Agile, they were doing feature-by-feature Agile which involved the normal 3 to 6 month time cycle. Continue reading