“What gets measured, gets done”. We all know this. By the way, did you notice that it says: “done”, not “done well”? We like metrics, because we base decisions on them. If we didn’t have them, then we would just be guessing.
For project managers things are decidedly more complex. Much of their traditional work around “when” is redundant, since we are aiming for stable teams and sizing work to the time work around “who” is also gone.
About half way into the interview Dr. Dan starts talking about Cosmic Function Points. I almost sounds like a new age approach to Agile software development but he’s really talking about the complexity of the data flow between components in a system. It’s an interesting concept!
What is a design pattern? Sometimes it's an evanescent concept to explain, so I put together this list of roles a pattern fulfills in software development to get a concrete feel about why we are codifying solutions as Composite or Data Mappers.
In many ways, estimating project budgets or dates for agile projects turns out to be irrelevant. If you have a ranked backlog, and you finish features, you can always stop the project if you hit a particular date or cost.
There are so many reasons why continuously refactoring code is a good idea – in fact, it is a sound investment for the overall health of your codebase. So, what could be some reasons why we fear doing refactorings?
Working with legacy assets can be difficult. You will start out with fear, uncertainty, and doubt (aka the FUD factor) and you will probably question if it is worth going through the trouble of touching old code.
In Part 3, you had some knowledge of the team’s velocity. This is the option of when you do not have knowledge of the team’s velocity, because this team has not worked together before, or has not worked on a project like this before. You are all coming in blind.
An agile enthusiast who seeks excellence in software engineering. This is how Patroklos Papapetrou defines himself. Let's have a techdebt talk with this greek "software gardener" who recently published a very interesting approach on how to identify & remediate resign patterns with code metrics and agile practices, based on the original article written by Michael Duell.