Speed vs Code Quality

when managers pressure the developer to ship fast and move to the next thing

"It's not being more productive, it just seems that you're getting things done faster because you're taking out a loan on the quality of your software (i.e. technical debt) with every line you write." This. When someone does this in a hurry or because they didn't know better, it's understandable. But when someone thinks that this style of working is superior, that's a huge problem.

As an end user, I care more about code quality and stability than I do speed of shipping code. I don't want to use some buggy code that was pushed through production too quickly just because the devs are lazy!

I'm not totally convinced that allowing developers to build faster is really all that great of an idea. At least not the sacred ideal that seems to be accepted without any question.Most of what I see when people are moving fast is building things as fast as they can think of them based on the first idea that comes to mind that sounds like it might get things done.But the reality is that the first way that you think of implementing something isn't always the best. It's often

The adage for software is “fast, cheap, good - pick two”, but it has devolved further into “fast, cheap, good - pick fast”. This is obviously a generalisation, but the reality for most software development is that speed to market, pivot and patch trumps everything else. I expect it will get worse before it gets better.

If "faster" equates to lower quality, bugs, more post-release thrash - simply to meet a contrived / marketing deadline - then none ;)

I believe it's largely down to short term goals versus long term goals.From the business perspective, the company should do things quickly because that means the jobs are more profitable, cashflow is stable, and the business team believe that they can always find more clients even if the product is horrible. This is the short term outlook.From the programmers perspective the company should do things slowly because that leads to more maintainable software, less technical debt, and high

The topic of your rant is something that it took me forever to accept as a software engineer. Nobody cares about quality.Your method is refactored to be super-fast and have no branches? Nobody cares.Elegant, re-usable architecture? Nobody cares.You've optimized an inner loop in assembly and increased speed by 30%? Nobody cares.Made it to zero compiler warnings? Nobody cares.No known crashers left in the bug tracker? Nobody cares.Fixed that bug that's been in the code

Do. It. It's embarrassing when the industry sacrifices speed and quality for the sake of dev convenience.

Unfortunately most of the business people are in a hurry to release a new feature or version.There is a misconception that code quality comes in a price of developing time but in my experience I have released much faster the final product when I use unit testing, incremental releases, use code reviews and other techniques that help maintain the code quality high.By not using these techniques you get faster initial release but a much slower final, bug free, release.