Everything in development is a cost-benefit trade off. Despite it's speed limitations, Ruby remains an excellent language for development because of its focus on developer efficiency. You can produce feature complete systems in a short period of time at the expense of slightly higher hosting costs, which is significantly cheaper than labor costs.<p>Monolith development is still much faster than microservice development even though microservice development is the better long term option by far.<p>It's all tradeoffs. I'm an architecture nut and for years I really wanted nothing more than to design the ultimate perfectly scalable and secure system but unless you're at a virtually competition free enterprise, like a telecom or an insurance company the time or budget to do so probably doesn't exist.<p>I've gone from "get it done" to "do it perfect" back to "get it done and avoid obvious problem starters". The reality is just that "get it done" wins the business case almost every single time.
So this is all true, however it is surprising how often in development you find people spending more time and effort getting the 'pragmatic' hack to work acceptably than it would have taken to do it right.<p>People often underestimate the difficulties of getting a hack to work and overestimate how long doing something correctly will take. Even with short time horizons.
"The problem is not that we don’t know how to write correct software. The problem is that correct software is too expensive."<p>That's something I've been saying for a while. It's all about the economics of the situation, rather than the impossibility if it.<p>Naturally, there <i>are</i> also improvements here and there that decrease bugs without increasing efforts, and those are worth looking for.
Joel Spolsky published a blog post in 2000 named "Things You Should Never Do" (<a href="http://www.joelonsoftware.com/articles/fog0000000069.html" rel="nofollow">http://www.joelonsoftware.com/articles/fog0000000069.html</a>)<p>It's about why Microsoft with IE6 won the browser war against Netscape who made the single worst strategic mistake a software company can make by rewriting Netscape 6.0 throwing out all the code from Netscape 4.<p>Netscape was working with extremely buggy and convoluted code in the older version and trying to save the development community from the nightmare that is IE6, ended being late to the market with a superior product. Joel makes a very good observation that often people want to throw out old code because they think it's a mess, but the truth is counter intuitive that the old code contains vast amounts of knowledge.<p>A company can be first, best, or cheat and in this case while Netscape was trying to be best, Microsoft was first.<p>This is the reason iterative code development is best. Speed of iteration beats quality of iteration 9 out of 10 times. Boyd's Law of Iteration (<a href="http://blog.codinghorror.com/boyds-law-of-iteration/" rel="nofollow">http://blog.codinghorror.com/boyds-law-of-iteration/</a>) The best software is software that released most often, not released the most correct.<p>If I was to release a browser in say 2008 to compete with the dominance of IE, what is the single most important feature I could put into that browser? I'd put a feature for forcing iteration, so that the browser can automatically update on the client finishing a development cycle rather than release the update preinstalled unable to remove on newly bought computers.
I think one of the other problems is that people value the economics of software correctness using their gut, rather than empirical analysis.<p><a href="https://en.wikipedia.org/wiki/Hyperbolic_discounting" rel="nofollow">https://en.wikipedia.org/wiki/Hyperbolic_discounting</a><p>Everyone knows that bugs are problematic eventually, it just seems that they can't put that on a level playing field with the up front costs, be they in terms of time, features, or effectiveness.<p>As an example, if you asked Home Depot whether they were saving money with their self checkout machines, I'm sure the answer would be different before their data breach vs after. Even after being warned they simply couldn't properly discount the possibility of massive damage in the future when offered a short term benefit.
> You have probably never written a significant piece of correct software.<p>So true.<p>When we were hiring for a senior engineer position a few months ago, one applicant said he wrote "bug free code."<p>I laughed, sent it around on slack. We all chuckled at it. The applicant did not get a call.
> If you want better software, make or find tools that reduce the effort of finding bugs. ... Better monitoring is another. Code review processes. Static analysis. Improved communication. There are many more.<p>I'm going to come out and suggest that even THESE are more expensive than most businesses need. I believe code review processes are insanely expensive for what they usually return (wrt bug costs).
What about reducing bugs through code reuse, in the form of libraries and frameworks? Because they have more users, more bugs have been found, reported and fixed. e.g. using standard libraries instead of writing your own.
It's possible to write software with very few bugs if you're very experienced in the language/framework and software development in general, writing all the code yourself, and perfectly understand the requirements. Otherwise, good luck.