My colleague told me today that companies with shit code quality, complete chaos, no tests of QA of any kind, and poor security practices still make loads of money and are extremely successful so it's all a waste of time.

I detest this idea and I refuse to work like that anymore. But I also think he's right :(

Makes me really question the point of studying all the time and trying to do a better job when I think about this.

There was a good article out there of a founder who was working on a startup. They had a big focus on code quality, good dev tools, and releasing super stable and good products.

They had some good customers that they were working with and had a nice roadmap and looking like they had a good future.

Then over the course of months all his customers left him for some new thing that he had seen but he knew was ass as far as all the things he valued (code quality, chaotic development, etc).

He talked to his former customers and they all just talked about features that were on his roadmap, but new thing had them already (or at least they said they did).

The new thing was Salesforce...

There's very much a yin and yang as far as actually making a thing that people can use at a reasonable speed and ... doing it right.

@N00bPancakes if you company aligns with their roadmap, and your company has the $$$ to throw at it, it's not as bad...... 👀 did I just say that!

Salesforce is a restrictive, chaotic and ever changing platform, for better or worse, it really depends on the feature and the year.
But if you can wield its mighty sword and not kill yourself in the process, fuck, the things you can do are impressive.

Customer does not pay for highly maintainable, uncle bob approved code. They pay for working product.

Neglecting tests and code quality will likely be benefitial in the short term as you can churn out more features per month for a while. But a year later development will be slower cause the code is too difficult to modify.

...Buuut at the same: your friend does have a point.
The goal of a developer is not to write nice code. It's to produce features that make money.

And if you spend 60% of your time on tests, maybe that's too much.

In some cases maybe we should even ask ourselves: how bad is it really if the site crashes once in a while - if we can roll back the release instantly and no one even cares - was it really worth 50% of time to build 20.000 unit tests to prevent one crash?

Maybe we could limit our time to only 20% on tests and just test the essentials and not every unit.

In terms of code quality I do think many of us over-estimate how long our codebase will live and spend way too much time on making it "easily modifiable".

My latest story:
My pal wrote a new version of a site. They spent 1 year on writing the new codebase. They spent tons of times writing the code to make it super easy to change the color scheme and API in case that would change.
The launch was delayed. Company lost money.

The site was replaced 3 years later by a fresh codebase.
Not because the old code was bad but because they wanted more personalization so made sense to rewrite it in a frontend FW.

They didn't take into consideration that the color theme and the API had been the same for 12 years, but the company had a tradition of rewriting the entire frontend codebase every 3-4 years.

@jiraTicket

I agree on the 'easily modifiable' part.

I can count plenty of times I made something easy to modify / modular and ... ended up rewriting it after it turned out it needed to be differently modular....

Not that the first effort was wasted time, it wasn't but it is REALLY hard to predict what is efficient in the future.

@N00bPancakes That's a lesson many of us could learn from.

"It needed to be modular - but in a different way"

I feel like most devs know the famous quote "premature optimization is the root of all evil" - but there should be one about premature modularization too.