However, the truth is that in almost all projects, architectural improvements are not captured at all. In other cases, developers are not sure about what to consider as a bug: just errors popping up at customers or also internal problems discovered by themselves or their peers. In some cases, project stakeholders are not even sure which entities in their issue trackers (or project management tools) represent product features. The information is mainly based just on gut feelings and memories of people who happened to be involved in the corresponding activities. When we ask, whether such improvements increased the feature throughput or reduced the number of bugs or any maintenance effort, the answers are often very vague. There is often great uncertainty regarding the sense and benefits of refactorings executed in the past. As a consequence, it becomes almost impossible for them to reliably measure the effects of improvement activities and efficiently handle technical debt. In our consulting projects on software quality we often discover a similar situation: neither developers nor architects or responsible project managers have a clear picture of how much effort is spent on feature implementations, bug-fixing or refactorings in the project. However, for the sake of simplicity, I will use the term “refactoring” as a generic term for both. Remark: I am aware of the difference between “refactoring” and “re-engineering”. However, if you are ready for the whole story, you’re welcome to start the journey right here. If you just believe in summaries or are short of time, but are eager to follow the recommendations here and want to see what happens, just feel free to switch to the section Minimal Set of Needed Issue Types and configure your issue tracker accordingly. In particular, it reasons why a separate issue type is needed to deal with technical debt. It suggests a minimal set of reasonable issue types along with understandable rules for their usage. It shows why a conscious and purposeful application of issue types can lead to better code comprehensibility as well as better quality monitoring and decision making in projects. It reveals the chaos behind the often mindless, uncertain and inconsistent usage of issue types in many software projects. If your answer to one or more of the questions above is “no”, or “don’t know” or “I don’t care”, you are not alone, and this post might be of interest to you. 11 Rules to Survive in the Issue Types Jungleĭo you exactly know which issues types to use for your issue tracker and when to use which? Does everyone in your project know about your approach? Are issue types always used consistently in your project? Should you use Technical User Stories or not? Do you use issue types at all? Do you find it reasonable that different issue trackers have such different default issue types? Have you ever thought about issue types at all?.A Few Words on Technical Debt – Why Refactorings Deserve a Separate Issue Type.Issue Trackers as Basis for Quality Monitoring.Doing it Better – Issue Types That Make Sense.Bad State of the Art – Anarchy of Issues.
0 Comments
Leave a Reply. |