All software development costs someone something. Software does not change without someone paying something for it (even if that is just their own time, time has value).
To that end, technical debt, is like any other software change. There is no difference between solving technical debt, fixing bugs, or creating new features. All of these changes must have a "business value" associated with them. If you cannot justify the value of the change, why are you doing it? If you can, then you know what it is worth. A lot of technical debt has a business case that it makes future software development slower. Or to borrow some of the examples from this thread, it takes longer to find something in your home, if your home is not organized. Likewise, it takes longer to fix bugs and develop new features if the code is not organized and provides a pleasant developer experience. It is up to individual developers to surface the issues that have the most value to the business (from a technical or user perspective) and it is up to the product owners to make a determination of what truly has the most value to the business. In other words, what gets Wikimedia the greatest bang for the buck? I am thankful that it is not up to me to answer that question. :) On Tue, Mar 19, 2019 at 11:49 AM John Erling Blad <jeb...@gmail.com> wrote: > On Tue, Mar 19, 2019 at 12:53 PM bawolff <bawolff...@gmail.com> wrote: > > > > Technical debt is by definition "ickyness felt by devs". It is a thing > that > > can be worked on. It is not the only thing to be worked on, nor should it > > be, but it is one aspect of the system to be worked on. If its ignored it > > makes it really hard to fix bugs because then devs wont understand how > the > > software works. If tech debt is worked on at the expense of everything > > else, that is bad too (like cleaning your house for a week straight > without > > stopping to eat-bad outcomes) By definition it is not new features nor is > > it ickyness felt by users. It might help with bugs felt by users as often > > they are the result of devs misunderstanding what is going on, but that > is > > a consequence not the thing itself. > > The devs is not the primary user group, and they never will be. An > editor is a primary user, and (s)he has no idea where the letters > travels or how they are stored. A reader is a primary user, and > likewise (s)he has no idea how the letters emerge on the screen. > > The devs are just one of several in a stakeholder group, and focusing > solely on whatever ickyness they feel is like building a house by > starting calling the plumber. > > > Sales dept usually dont advocate for bug fixing as that doesnt sell > > products, new features do, so i dont know why you are bringing them up. > > They also dont usually deal with technical debt in the same way somebody > > who has never been to your house cant give you effective advice on how to > > clean it. > > A sales dep is in contact with the customer, which is a primary user > of the product. If you don't like using the sales department, then say > you have a support desk that don't report bugs. Without anyone > reporting the bugs the product is dead. > > Actually this is the decade old fight over "who owns the product". The > only solution is to create a real stakeholder group. > > > That said, fundamentally you want user priorities (or at least *your* > > priorities. Its unclear if your priorities reflect the user base at > large) > > to be taken into consideration when deciding developer priorities? Well > > step 1 is to define what you want. The wmf obviously tries to figure out > > what is important to users, and its pretty obvious in your view they are > > failing. Saying people are working on the wrong thing without saying what > > they should work on instead is a self-fulfiling prophecy. > > Not going to answer this, it is an implicit blame game > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
