Do you like to whinge about CiviCRM code? Have you sat through others doing having a rant? I've certainly done both. Being in the drupal world people often like to compare CiviCRM code with drupal & CiviCRM usually comes up a bit short. I think that's like comparing my kitchen with Bill Gate's kitchen. There are a few good reasons why my kitchen is not as nice as his. However, should I look at his kitchen (in a magazine) then I might glean a few good ideas that I could use in designing my own. (Copying the colour scheme would be in my budget :-))
To continue the metaphor, Bill Gates gets to rip his kitchen out & put a new one in whenever it's getting a bit tatty whereas I have to patch mine up & incrementally improve it. Unfortunately, each time I get a new whiz-bang gadget I find it harder & harder to get the cupboard door to shut. And then I can't find anything or open the door without everything falling out.
This is called kitchen debt. I have a lot of kitchen debt due to my inability to manage the expectations of those for whom I manage the kitchen. Unfortunately they tend towards unrealistic timeframes, constant demands, quick (sticky, unhealthy) fixes over durable ones and fights over whose turn it is to use the batman fork. Every now & then I have to have a massive tidy up, throw some stuff out, consolidate other stuff & rationalise whether I could replace 8 saucepans with one really good one. I also take a wee look at at the kitchens I can't afford to see if I can think of some affordable variations on them.
The technical term when you code looks like my kitchen is Technical Debt. Like kitchen debt, we all have some, but depending on our resources, our clients demands, whether we share the kitchen & our own natural tidiness we have more or less of it. In some areas CiviCRM is doing really well at redressing technical debt. The documentation team have done an amazing job. However on the wikipedia page above this sounds very familiar.
Delayed Refactoring. As the requirements for a project evolve, it may become clear that parts of the code have gotten unwieldy and must be refactored in order to support future requirements. The longer that refactoring is delayed, and the more code is written to use the current form, the more debt that piles up that must be paid at the time the refactoring is finally done.
There are a bunch of complaints I could share about aspects of the CiviCRM code but my goal in writing this is to get you to do that. I want to put technical debt on the agenda, not just in this blog but in EVERY CiviCon & EVERY Code Sprint. These days documentation, tests and the api have become part of our CiviCRM conversation and I would like to see the ongoing management of our technical debt right up there as well. We should dedicate some time at each sprint for refactoring code for the sake of refactoring, not just to fit in another gadget. Talking about what you think the biggest problems are is a really good start.