Quality can mean a lot of different things. Elegant, simple to understand code. Adherence to current best practices. Modular. And the list goes on...
But the most important part of quality for actual users is that your software is solid -- it isn't going to break and cost them time or money. That kind of quality isn't particularly complicated to obtain -- it takes hard work, discipline, and prioritization, but there's nothing magical about it.
"When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through."
- Steve Jobs
They just want to write a code, skipping writing automation test, and call it "magically done by me, the greatest hacker in this company, for under 1 hour".
Forgive me with the sarcasm but that's apparently quite common.
Of course, there is often no real need to build code to be any more than 'just good enough' in the same way that many people are quite happy to purchase a plywood-backed piece of IKEA furniture instead of a solid mahogany hand-crafted piece. It serves their purposes just fine and saves them a ton of money. A good developer will similarly be able to determine what the precise definition of 'good enough' is for any given project scope/budget/time constraints.
OTOH, if you have OTOOM of $1k or less, and only a few free hours per day or week to put into a project, or a drop-dead-runway of a few months, then tests are your enemy, because there's a lot of additional cost in terms of time and hassle in order to write them and maintain them as you go along. That's not to say that all tests are bad, or that tests never make sense. It's to say that having tests adds a cost, and so sometimes the upside of having them does not justify the downside.
Then, when the urge to rewrite something strikes, you can just rewrite that one component, knowing that everything else should work just fine.
* I haven't actually built anything substantial in a functional language, other than my blog (in Clojure), so I can't back this up with experience. But I think it's true.
I'm pretty sure this was the promise of OOP, too. Or at least the promise of the OOP that was sold to me in (limited) school and on the job.
When you are guaranteed that a subsystem has no side effects, you can gut its internals and as long as the interface behaves the same - your system will behave the same.
edit: a _stateful_ OO system anyway.
This is a key insight, and it usually takes banging your head against architectures you've created yourself a few times in order for it to sink in. Early on, you think that somehow there must be a "perfect" way of coding. So whenever the system gets a lot of cruft, you feel as if you made a mistake somewhere. The much more likely culprit is the impossibility of keeping enough of the thing in your head at any one time in order to keep it consistent.
I think FP helps with this a lot, and I think we're going to start seeing larger and larger systems moving to FP.
FP is going to bring it's own problems, though, which is why I think a hybrid FP/OOP model, with classes "growing" up from REPL constructs to meet contractual obligations is going to be the future. You'll code in FP, then wire in OOP.
