Last week I wrote a blog about technical debt (comparing it to keeping a kitchen in order). I got a lot of feedback - most of it constructive. I'm going to resist belabouring the whole metaphor & limit this blog to a quick summary of some of the discussion that came out of it.
It's about making it better
There is such a thing as code without technical debt. It is found in textbooks & outputs the words 'hello world'. Code that is actually used has technical debt. Technical debt is a natural by-product of writing code without unlimited resources & time. So, while addressing technical debt is a good thing - saying that CiviCRM has technical debt is like saying CiviCRM is software.
On the flipside, it's important to note that CiviCRM is a remarkable piece of software & it represents a remarkable commitment by the core team and others. Most of us take this for granted but when you start talking about what we can improve sometimes this needs to be re-iterated.
It's also worth noting that the core team and others do improve the code on an ongoing basis - this was obvious when noting that a number of things brought up in response to my post had already been addressed or were in the process of being addressed. Just this week a change was made to autoload CRM files & remove the need for many require_once statements.
It's about repayment-welcoming
We have many ongoing -mostly bad - jokes in the CiviCRM community & many of you will be familiar with our new verb 'to patch-welcome' someone. Patch-welcoming is pointing out to people that if they would like something improved they are welcome to submit a patch. But when it's done well patch-welcoming also includes giving people enough information that they know how to go about it. We need to encourage people to submit code improvements - but we need to help them with it too.
It's about standards
One of the big blockers to people contributing debt-free code, or reducing debt is having clear standards as to what the code conform to - it's like doing the dishes in someone else's house - do you leave them on the benchtop or put them away the wrong house. Often we are scared to tidy up code because we aren't sure whether the Core team will agree we are tidying it in the right direction. Discussion from my blog continued onto the forum and then after we were officially 'standards-welcomed' onto a wiki page. At this stage we are working on deciding what standards we should work towards. It also triggered me to write an API standard - the api standard is more mature than the others as it is pretty much documents what has previously been agreed in various discussions and we have already been actively working towards it.
I wasn't surprised to see how much coders care about a standard for spacing as the strict standard of drupal seems to gladden many coders hearts. However, I was surprised Lobo suggested we move to the drupal standard - mostly because I had thought we'd need to define a standard that was similar to what was in place. However, I can see many good reasons for that approach.
It's about funding
One of the difficulties with paying of technical debt is that we are often funded to write new features or patch bugs. However, many of the bugs arise in code that has become complex and difficult to understand. A key challenge is getting those people who use CiviCRM to direct some of their funds into preventative maintenance.
It's about doing it
What part can you help with?