So, this sort of devolves to economics, at least where I work. What I mean is, the people that pay for the code don't care and don't care to know. And this is entirely rational from their point of view. If it appears to work, it's good.
To audit the code accurately (as opposed to merely giving out aesthetic advice), in most cases would involve learning the domain, and this is what's expensive.
To the business folks, we're a black box. Stuff goes in, stuff comes out. And it costs. Paying someone else at least as much to prove that we did it according to 'best practice' (I think this is what you're suggesting?) would be anathema.
There might be a business there but it's not mass market.
It's probably also worth noting that all of the above applies to other domains too. Substitute 'code' for 'marketing' quality. In some real senses, die welt ist alles was der fall ist.
> To audit the code accurately (as opposed to merely giving out aesthetic advice), in most cases would involve learning the domain, and this is what's expensive.
There are a lot of things between aesthetics and domain knowledge that are audit-able. A lot of code bases you can walk into and see a million n+1 queries right away and the architectural patterns that lead to them. Another canary is the test complexity that reveals various anti-patterns like active record. Another is correct IOC usage, a lot of code bases will use it for creating POCO objects for example. These are all very common and quickly discoverable.
> So, this sort of devolves to economics, at least where I work. What I mean is, the people that pay for the code don't care and don't care to know. And this is entirely rational from their point of view. If it appears to work, it's good.
I wonder if you could go in and say "this project is costing you $10 million" and we can give you an early indication of whether it's going to be worthwhile or be a turd.
> There are a lot of things between aesthetics and domain
> knowledge that are audit-able.
I don't disagree with you. The pertinent question is 'does anyone care'?
> A lot of code bases you can walk into and see a million
> n+1 queries right away and the architectural patterns
> that lead to them. Another canary is the test
> complexity that reveals various anti-patterns like
> active record. Another is correct IOC usage, a lot of
> code bases will use it for creating POCO objects for
> example. These are all very common and quickly
> discoverable.
Again, I don't disagree. You're right, possibly even corrrect. But we're talking business plans yes? So feel free to buy that expensive suit (or hire a beard) and see if you can explain these issues and why they matter to the people with the money.
"If dogs could talk, perhaps we would find it as hard to get along with them as we do with people."
I get what you mean but I do think the care factor could be broken down a bit better. Some simply don't care, talking to them is a waste of time. Some don't care because the can't, they don't have the visibility into things so they're pointless to worry about.
The final group does care, often because there arse is on the line and are often a CXO. These are the ones that love Agile/scrum because they think it'll identify problems early and/or they don't trust their Devs.
Whether a solid business case could be sold I'm not sure, but I think everyone that ever hired a scrum consultant would be the target market.
To audit the code accurately (as opposed to merely giving out aesthetic advice), in most cases would involve learning the domain, and this is what's expensive.
To the business folks, we're a black box. Stuff goes in, stuff comes out. And it costs. Paying someone else at least as much to prove that we did it according to 'best practice' (I think this is what you're suggesting?) would be anathema.
There might be a business there but it's not mass market.
It's probably also worth noting that all of the above applies to other domains too. Substitute 'code' for 'marketing' quality. In some real senses, die welt ist alles was der fall ist.