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

Incremental Development

I happened across this excellent and perfect depiction of incremental development.  The image addresses on of the key flaws in thinking that lead some agile projects to fail.  So let’s discuss a bit.

Estimations – the eternal software problem

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

26 Hints for Agile Software Development

I collect nuggets of wisdom on various topics. Recently I have been going over the topic of Agile software development; what really matters?  Below is a list of 26 key principles to guide an agile software development team.

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.

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.

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.

Growing Software like a Plant

Maybe it is helpful to view the development of a software in using an Agile approach as being like way that a small tree grows.  In contrast, development of software using waterfall is like that of a factory.  The difference between a tree and a factory tells us a lot about the difference of these two styles of software management.

Don’t Fear Rewriting New Code

The last post #28 Avoid “Test Script” Fever was about simplifying an implementation that was more elaborate than it needed to be.  There was a waterfall-style project in exactly this situation, and leader responded saying “It has already been coded the other way, and if your goal is to save programmer time, rewriting will just waste more time.”   No, it won’t, and this post explains why.