TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

High-Quality Software Engineering (2007)

86 pointsby rhimabout 1 year ago

6 comments

ChrisMarshallNY12 months ago
I was explaining this to a friend who&#x27;s a top-shelf cabinetmaker.<p>He was telling me how he would sell high-quality cabinets to homeowners, basically by building a &quot;dream kitchen,&quot; that far exceeds their budget, then backing down, by removing features, until they have something that exceeds their original budget, but would still be quite good, and that they want.<p>He was saying that I should use his methodology.<p>I explained that his sales are to the people that would actually use the cabinets, so they have a vested interest in high quality.<p>In my case, I would be working for a business that absolutely doesn&#x27;t care about quality. They want the cheapest, shittiest garbage they can possibly get away with pushing. They don&#x27;t use it, and many of them won&#x27;t even be responsible for supporting it, afterwards, so there&#x27;s no incentive for quality.<p>The same goes for corporations that don&#x27;t try to retain talent. If someone is only going to be around for eighteen months, they are paid well, and they are pressured to produce a lot of &quot;stuff,&quot; then you can expect them to produce a lot of ... <i>stuff</i>. They don&#x27;t give a damn about supporting it, because they are already practicing LeetCode for their next gig.<p>I have found that giving people a vested interest in Quality is essential. That often comes from being responsible for taking care of it, after it is released, using it themselves, or having their reputation staked on it.<p>I don&#x27;t feel the current tech industry meets any of these bars.<p>Most of the software I write, is stuff that I use, and I am intimately involved with the users of my work. I want it to be good, because I see them, several times a week. Also, I have a fairly high personal bar, that I won&#x27;t compromise. I have to feel good about my work, and that doesn&#x27;t seem to sell.
评论 #40382965 未加载
评论 #40384612 未加载
评论 #40385737 未加载
评论 #40388100 未加载
tkiolp412 months ago
I don’t know. If I have learned something in the last decade about software engineering and quality is: business only care about revenue and speed, while engineers don’t have an objective way to define quality (10 engineers would give you 10 different opinions about the same piece of code).<p>The only moment I consider quality as the top priority is when I work on side projects (because there’s only one opinion about what quality means, because there’s no time pressure and because no one is asking me “are we profitable now?”)
评论 #40384902 未加载
评论 #40386350 未加载
评论 #40382390 未加载
评论 #40382480 未加载
评论 #40382781 未加载
评论 #40382613 未加载
didgetmaster12 months ago
&#x27;Eating your own dog food&#x27; is the best path to quality software in my opinion. Too many people working for a software company (developers, salespeople, product managers, etc.) never bother to use the software to do the kinds of things they expect their customers to use it for on a regular basis. Write the code. Make sure it passes some tests. Move on to the next project. This is common.<p>No wonder so many bugs never get reported unless many customers run into it much later. I have a project I work on regularly. I use it regularly to do productive things and I find most of the bugs just doing that. I had a couple different &#x27;business partners&#x27; who talked a good game, but I could not get them to actually use the software and give me feedback on how to improve it. Neither one added much value to it and quickly moved on to other things.
评论 #40385412 未加载
评论 #40384259 未加载
评论 #40385111 未加载
评论 #40385374 未加载
评论 #40383984 未加载
评论 #40385141 未加载
w10-112 months ago
This is really baseline software development.<p>What&#x27;s missing are the fault models with the solutions from 15 years ago:<p>- how to keep code review from becoming a politicized bottleneck<p>- deploying continuously to avoid train schedules<p>- comprehensive security, for both code and process<p>- ...
评论 #40385127 未加载
评论 #40384645 未加载
doctor_eval12 months ago
&gt; For example the telephone system and the Internet are both fundamentally grounded on software developed using a waterfall methodology<p>Is this true? I can’t speak for telco, but I thought the internet in particular was developed incrementally with a lot of experimentation. I mean, yes, the experimentation resulted in RFPs and STDs. But I thought these generally came after the software was working. And as someone who has implemented a few RFPs, I would not say my approach was remotely waterfall.<p>Indeed my perhaps incorrect version of events is that the waterfall approach is represented by the big loser in telco, the ISO OSI.
angarg1212 months ago
&gt; Here’s a little-known secret: most six-nines reliability software projects are developed using a waterfall methodology.<p>I&#x27;ve designed and deployed Tier 1 services for a Big Tech company, and here&#x27;s is a little-known secret: when nothing changes, our reliability is higher than six-nines.<p>Last year I measured our uptime during Black Friday for fun. Our error rate was measured in scientific notation because the number was so small. We didn&#x27;t do any deployments or changes during that period.<p>When you operate in a steady state it&#x27;s easy to achieve zero errors, and most downtime comes from random failures in hardware, i.e. servers crashing or network blips (which, operating at scale, are relatively common).<p>So my and other&#x27;s personal experience is that most outages are due to changes in the software, dependency outages, or the rare large scale event that completely kills your SLA (e.g. a whole AWS region is down). Taming these is at the essence of reliable software.<p>Whoever tells you that the best software is made using waterwall methodologies from a fixed and never changing set of specifications, lives in a fantasyland alien to the vast majority of developers.