Hacker News new | past | comments | ask | show | jobs | submit login
Is High Quality Software Worth the Cost? (martinfowler.com)
24 points by sathishmanohar on July 29, 2022 | hide | past | favorite | 9 comments



None of this means anything until "the market" determines how to effectively filter/punish low-quality software, which mostly hasn't happened yet?


According to the article, poor internal quality means your software just can't keep up with competitors. So you don't get punished for releasing buggy software, you get punished for not releasing software at all.


I try to do the best I possibly can and write clean, elegant code that I'm proud to look at afterwards, but for small teams 1-4 people, sometimes it's just required to do the 95% implementation that ships today. The 'it will cost me more later' is absolutely true, but often there is a business case to get moving on the next feature to stay ahead of the competition.

There's definitely an optimum point between quality & shipping. You need to know when to stop spending exponential effort on the last 5%, and move onto the next low hanging fruit.


Most businesses couldn’t produce high quality software regardless of the cost. Money won’t always get you there


Without reading the article, likely not as software engineering is business activity and most software isn't high quality.


After reading the article: spot on, until certain point.

High quality is more expensive upfront but goes relatively cheaper as maintenance and modifications is progressing. The opposite applies to low quality software.

Similar with real world situation, some things are more expensive upfront while cheaper in the long run.


> High quality is more expensive upfront but goes relatively cheaper as maintenance and modifications is progressing.

What about the fact that many pieces of software are needed for a particular purpose and will eventually be retired or replaced by a rewrite in whatever tech seems modern at that time?

Or the fact that project based thinking is still pretty popular in certain parts of the world - once you finish writing the piece of software for your clients and they receive the codebase, it's no longer your problem anymore.

The opposite also exists, of course, codebases that have been around for a decade in COBOL or something, are still mission critical, but nobody really knows how they work.

And second system effect is also very much a thing to keep in mind, when thinking about rewrites. Though I also agree with a statement that I once heard: "Don't just write code to be easy to read and change, but also easy to delete and throw away."


Something not mentioned is the huge sums of VC money spent on marketing in an attempt to blitzkrieg a vertical, even if the underlying code is crap, it will be hard to overtake a company if they own 80% of the market.


it is not for the client. it is for me.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: