On 16 Feb, Gabriele Cerami wrote: > Hi, > > I started circling around technical debts a few months ago, and recently > started to propose changes in my team (CI) process on how to manage > them.
> https://review.openstack.org/545392 Hi, I'd like to draw again some attention on this. I'm adding some answers to the common objection that I received after this proposal modification. If someone prefers, we can start the proposal from scratch and build it with the people interested. But I'd like to keep the discussion ongoing, and agree at least on some direction. "Why should I care if a piece of code that works is not optimal and not considering all the cases?" It's all about yours, your team's or another team's future time. "All" is a relative term. "all" the cases someone considered may not be a comprehensive set, and the implementation is really creating unnoticed technical debt if no one else addresses it. The why in general relates closely to Project Management, even if we don't have official PM roles in our projects, there are some tools, techniques, best practices and element that it's best to consider. Technical debts are the developers' contribution to the global risk assessment of a project. Risk management usually deals with "what if"s, calculates the impact of a decision that may make someone lose precious time in the future, and prepares a response in case the "what if" becomes reality. Completely ignoring the TDs may put the project at unassessed risk, and no track will be left of what led to a bad situation. Again, I borrow from project management, or quality management in this case: "Do it right the first time" is a principle that Crosby introduced in 1979. It would be the best approach, and I think we should pursue it. It will not always be possible, but when that happens, at least write it why and what would have been the optimal solution somewhere. "Is it really that big of a problem ? There's still a lot going on without having to take care of this, I don't think TDs impact that much or that often, we don't make so many of them" Since we are not tracking them regularly and with all the informations useful for data collection, we really have no clear data on how much technical debts are making an impact on our capacity. Also, unless a certain technical debt required a rewrite at a later date, representing a serious problem, it's really unlikely that someone remembers it. Hence the need of a policy with a precise workflow and details of what is useful to know at TD creation/detection time. "I agree with the premises, but this is too much work for the contributors" Fixing stuff at a later time may cost a lot more, especially when there is no track of what and why we decided to implement something in a certain way. I reworked the first attempt at the proposal a bit to make it more simple, not sure if less than this will provide enough informations. All the proposal is asking to do more than the exisint is to create a bug with some specific urgency and add two bullet points on it. The original policy was already suggesting to reference the bug in the code, the proposal ask to mark it as TD. Maybe developers can be drawn by more precise indications and workflows, and a detailed motivation. If we start creating TD properly, even if every TD is accepted as it is, with no further processing, we'll have a record of our decisions, and we can start to evaluate better how much really TDs are impacting us. Also these few infos added allow for further handling if need arise. Thanks. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev