– Low Code Quality. It is never enough that something works (which it often doesn’t). It needs to be maintainable and extensible, especially for software on this scale. Just looking at some of the source code, it’s obvious that developers have worked in isolation. Interfaces that don’t speak to each other properly, if at all! And I don’t mean working remotely, that has been done hugely successfully in many places e.g. 37signals. It’s almost as if there’s a culture of ‘this part of the system is not my problem’ syndrome. It’s contemptible. If you are on the project, it sure as hell is your problem, no matter which part of the system you work on.
– Lack of quality processes. I say this because I think low code quality is partly a function of this. You can’t just try the first thing that “works” and stick to it. There’s a saying “if it ain’t broke, don’t fix it”. But are you just convincing yourself it isn’t broken? A process can’t just work for you. It has to work for everybody on board the project or else it’s going to cause friction, low morales and poor performance. This is where empathy comes in and is as important as technical skills.
– Lack of quality logging & debugging capabilities. If you can’t replicate and then diagnose issues, then you damn well can’t fix it.
– Lack of quality bug tracking and reporting capabilities.
– Poor quality documentation (in and out of code). IMHO, the saying “good code is self documenting” is ego driven dribble.
– Very high noise to signal ratio in the community
– Lack of community engagement
– Closed sourced, difficult to use platforms for community engagement
– Slow and unintuitive interfaces.
– Very difficult to deploy and manage by DevOps or IT (e.g. schism between database and file based data is a mess). Sure, when you understand how everything works, you can say it’s no big deal. But you are assuming that everyone on the team always has the same level of knowledge and the same educational background as you do.
– Partial UI tooling is often worse than none at all. E.g. UI based tools can screw up the codebase. Again, no problems if you are an expert on the CRM system, but you can’t assume everyone else on the team is, right?
– Lack of transparency in the development process of CRM systems.
– There should be more focus and direct interaction with developers embedded in organisations, as opposed to CRM partners, who often have very different goals.
– The customer is not always right. Don’t keep adding more and more features just because they are requested. As an outsider, CRM development seem to suffer from this. It takes some courage to say no to your customers, but sometimes that’s the right answer.
– All of this would even expected were it not that these products have been around for over a decade, have had healthy funding and a lot of time to mature.
I doubt this is a reflection on CRM developers at all. It just seems like the impulsive need to just add more and more features is overriding the needs of the community and an overarching vision of what CRM could be.
Remember the Denver Airport software nightmare? It’s heard to find a graduate of software development who hasn’t heard of it. Was it run by very smart people? Almost certainly. Was that enough? No. Perhaps because of the talent in the project, not despite it, egos won and the project didn’t. Sometimes it feels like we haven’t learned from it.