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 <jeblad(a)gmail.com> wrote:
On Tue, Mar 19, 2019 at 12:53 PM bawolff
<bawolff+wn(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l