Technical debt

[denise]

If you aren't familiar with the term technical debt, it basically refers to decisions that organizations and software projects make to get things done now in exchange for having to fix it later -- borrowing time from the future, essentially, in order to get things accomplished now. Repaying your technical debt can involve a whole host of activity from code refactoring to cleanup work to system documentation, yadda.

kareila has been doing yeoman's work in making massive interest payments on the 10 or so years' worth of technical debt that the DW codebase has accrued, and we have a bunch of bugs open (why-cleanup, why-dev, why-optimization, and about 1/3 to 1/2 of why-usability) to repay some more of it. I thought it might be time for a group evaluation of our outstanding technical debt, though, and brainstorm ideas on what we can do to make more payments.

So, what other forms of technical debt do we have "on the balance sheets", so to speak?

Things I can think of off the top of my head:

* finish converting the whole site to TT
* better install docs
* better "so you want to admin a DW clone site" docs
* finish moving cgi-bin/lj*.pl files into proper modules (in cgi-bin/LJ)
* better in-code commenting (ideally each method in User.pm would have a comment explaining what it does and how to call it, for instance)

That's just an example list, though, and I'm sure I'm missing stuff! What bits of 'technical debt' have you noticed?

Comments

[shadowspar]

I don't know specifics, but I've heard it mentioned that much of the code could use more/better unit tests.

[foxfirefey]

We need to standardize all of the app site pages. They need to have standard classes for different elements that behave the same way, so they are easier to style for other people, and so each new page will almost never require any special color styling if it conforms to conventions, only some layout styling. It will greatly reduce the size of our site scheme CSS.

[foxfirefey]

PS: First link to bugzilla broken, think this one works though for cleanup.

Also: we need to move the heck on over to jQuery from all the older JS.

[dreamatdrew]

I have yet to find where there is a list of "This url starts getting generated in this file" directions. I WANT THIS. It's easier to fix things if we know where they are.

[foxfirefey]

I'm not finding the bugs for these yet but I am pretty sure they exist and are important:

* Redoing the support system
* Redoing the translation system

[kareila]

Oh, that's what I've been doing?

I'm sure we need more tests, and a few of the current tests still don't work.

[thorfinn]

Code Style Automation.

I assume DW has a current Perl coding style, but I'm betting that enforcing it costs you a huge amount of review time.

Perl's biggest problem when it comes to maintainability (which is a huge factor in technical debt) is TMTOWTDI. Adopting Damian Conway's Perl Best Practices as The Coding Style pretty much stops that problem, because it gives you One Way To Do It, for pretty much everything you might want to argue about.

Implementing it as an incremental process on an existing codebase is not hard.... Create a script which runs perlcritic and perltidy over a file and reports errors, and make use of that script as the first thing to be done when checking out code and the last thing to be done before checking in code.

I promise you, that one thing alone will save a huge immense amount of time in code review, code style arguments, and massively improve the readability of your codebase alongside that.

[pauamma]

PODified documentation embedded in each module.

[kareila]

There are still some English-stripping bugs open, to get all user-facing text into the translation system.

[azurelunatic]

Does breadcrumbing count?

[kareila]

I just thought of another one: exporting all the changed site strings back into the Mercurial repositories.