We should have a framework for dysfunctional code so we can build those projects faster and ship before the competition.
A software conference that advocates for quality
141–150 of 160 posts
Re: A software conference that advocates for quality
#142Earlier quoted context omitted.
Yes, parent says "people leave" as if it is not a problem in itself; you lose the time it takes to train these people, and they probably take some knowledge about the products with them. Or maybe we are actually talking about commodity developers? But I'm curious about how one prevents this dysfunctional culture.
At my last job the people motivated to fix the clusterfuck were the first to leave. Except me because I’m a masochist apparently.
Yep.. They/we get miffed, and twisted, stalled. Then they get dispassionate, and leave.
Re: A software conference that advocates for quality
#143Earlier quoted context omitted.
This is a bit of a simplification of the ideas of Blow, Muratori et al, a much better source for the ideas can be found in "Preventing the collapse of civilization" [0]. The argument made there is that "software quality" in the uncle bob sense, or in your domain version, is not necessarily wrong but at the very least subjective, and should not be used to guide software development. Instead, we can state that the soft…
> it is about a perceived explosion in complexity both in terms of number of developers & in terms of allocated hardware, without an accompanying explosion in actual end user software complexity. Do we want software to be more complex? Can you explain what you mean here? The explosion from my POV seems to be related to simply more software. > at its core we all understand that nobody needs 600mb of npm packages to bu…
> Do we want software to be more complex?
No but the complexity of software should follow from the complexity of end user features. Essential vs accidental complexity. Some problems are complex, they require complex software. Some problems are simple, so the software should be simple. In an ideal world, at least.
> However, it might make it easier? Isn't easy really important in some domains?
Indeed, this is maybe a better wording of the problem: it is easier but not simpler. Easy is never important in a domain, except perhaps adversarial domains like marketing or sales. Easy is shortsighted. Easy is not economical because easy choices are not the right choice.
> If Word startup speed was important then more engineering resources would be expended to solve that problem
No this is a common misconception about economics: things do not at all behave rationally in supply/demand situations. People want the wrong things all the time, people act irrationally all the time, business don't know what value is all the time, large problems are ignored all the time.
> Unfortunately I think Blow, et. al, only give this question a shallow examination
I am not sure about this, maybe so. Either way, so do you: it is not at all about performance, but performance is the canary in the coalmine: it is a direct translation of the essential vs accidental complexity problem.
If I can serve you a webpage in 10ms, and you serve me that same webpage in 3000ms (excluding network latency), you are obviously solving that problem in a way that is an order of magnitude more complex than what I have proven is necessary to solve the problem. Either by involving more software, more hardware instructions, more infrastructure network hops, etc. In other words: performance is an easy objective metric for the complexity that lies behind (an otherwise opaque) piece of software.
Re: A software conference that advocates for quality
#144Earlier quoted context omitted.
> it is about a perceived explosion in complexity both in terms of number of developers & in terms of allocated hardware, without an accompanying explosion in actual end user software complexity. Do we want software to be more complex? Can you explain what you mean here? The explosion from my POV seems to be related to simply more software. > at its core we all understand that nobody needs 600mb of npm packages to bu…
> Do we want software to be more complex? No but the complexity of software should follow from the complexity of end user features. Essential vs accidental complexity. Some problems are complex, they require complex software. Some problems are simple, so the software should be simple. In an ideal world, at least. > However, it might make it easier? Isn't easy really important in some domains? Indeed, this is maybe a…
> .. [I]t is not at all about performance, but performance is the canary in the coalmine: it is a direct translation of the essential vs accidental complexity problem.
This is all nice color on my commentary, but it fails to address the point of my two parent comments: programming is an economic activity. Sometimes a putatively more complex solution is the "right" solution for someone else, because it is easier to understand and implement, or fits within an existing workflow (it is more coherent and consistent).
Yes, if the performance delta is an order of magnitude, then yes, perhaps that is a problems for such software, but then again, maybe it isn't, because economics matter. Lots of people use 10+x slower languages because for loads of technical reasons, but also economic ones.
> In other words: performance is an easy objective metric for the complexity that lies behind (an otherwise opaque) piece of software.
Then presumably so is performance per dollar? Your argument can make sense, where the cost of a redesign is low (in cost of programmer education and experience and ultimately work), and performance benefits are high (10ms faster nets us 10x more dollars). That is -- Blow, et al/you, need to show us where these, "easy", if you will, 10x gains are.
Again -- I agree performance problems are real problems, and data oriented design is one way to reason about those problems, but Blow's marketing exercise/catastrophizing (see "Preventing the Collapse of Civilization") hasn't solved any problems, and is barely an argument without an analysis of what such incremental improvements cost.
Re: A software conference that advocates for quality
#145Earlier quoted context omitted.
I notice you have not quantified any aspect of your opinion, here. Which is not surprising, since your opinion is unrelated to facts, science, experience, or wisdom. Quality is not a "real, hard number" because such a thing would depend entirely on how you collect the data, what you count as data, and how you interpret the data. All of this is brimming with controversy, as you might know if you had read more than zer…
I’m not sure what conclusion to draw from this comment, apart from the fact that you’ve sure made a lot of assumptions about me and my experience.
For a guy who just made a uniformly damning and unnuanced statement about his peers in the industry, your concerns about "making a lot of assumptions" ring rather hollow. Perhaps you think only other people have to lay out their evidence and argument in a rigorous way, but not you?
Anyway, you could analyze my comment and reply. That's what I did with yours. Perhaps you could call my apparent bluff and challenge what I claim to know about epistemology. Maybe you're having trouble doing that because analysis wasn't how you arrived at your own opinion? You were expressing an ideological position that you inherited from-- I'm just guessing-- one article about Six Sigma or TQM that was 30 years old?
I read Quality Without Tears, by Phil Crosby, in 1987, that expressed much the same attitude as you just did. I've had a lot of time, since then, to become educated and experienced in these things.
Re: A software conference that advocates for quality
#146I'm disillusioned because it never happens, but purveyors of conferences and books are happy to sell the promised land™ of how "it's really going to be different this time." Processes, tools, and diligence vigilantly seem the most apparent path. Perhaps rehash the 50 year old debate of professionalization while AI vibes coding is barking at the door, because what could possibly go wrong with even less experience doin…
It doesn't happen because building the best software is not the goal of a software engineering job. If you want to do that on your own time, that's fine - but the purpose of a job is economic. Of course you should write software of some reasonable quality, but optimizations have diminishing economic returns. Eventually, the returns are lower than the cost (in time, money, etc) of further optimizing, and this break-ev…
Few people who advocate for software quality want better software just because it's more aesthetically pleasing.
Often, we've worked on codebases that were nearly collapsing under their own weight, where adding even small features would take an inordinate amount of time, where most changes would have unintended consequences, where onboarding was incredibly hard, etc. And we've worked on other codebases where changing things was easy, so we know the difference.
Often, the business has no clue how to fix this because a) they're non-technical, b) we unfortunately have no consensus in the industry about what "good code" is, c) humans are much better at short-term than long-term thinking.
Re: A software conference that advocates for quality
#147Earlier quoted context omitted.
Some thoughts regarding this: 1. It is partly because the typical metrics used for software development in big corporations (e.g., test coverage, cyclomatic complexity, etc) are such a snake oil. They are constantly misused and/or misinterpreted by management and because of that cause developers a lot of frustration. 2. Some developers see their craft as a form of art, or at least an activity for "expressing themselv…
1. Totally agree that the field of software metrics is dominated by clueless or outright bad actors. I can say with complete certainty that I do not know the right way to measure software quality. All I know is that quality is handled as a metric in most hardware companies, not an abstract concept. When it’s talked about as such an ephemeral thing by software people, it strikes me as a bit disconnected to reality. (I…
> The point I’m making is that: my boss would laugh me out of the room if I told him “You can’t measure the quality of my electronics designs or my delivery process; it’s art.”
You can find some kind of objective metric, e.g. bug count or time spent developing new features. That alone is super hard to get right, but even if you could, it wouldn't necessarily tell you which techniques lead to a better result. People have tried studying such things (e.g. do static types help) and the studies rarely come up with any effect.
I don't think that's necessarily because these things don't have an individual effect, but because there are humans involved and so, personal ways of thinking probably play an outsized role, so technique X might be a very good fit for person A, but not for person B.
Re: A software conference that advocates for quality
#148I hate talk titles of this form: "Most of your projects are stupid. Please make some actual games.". So annoying. I know it's not personal but I'm sure a better title exists for all talks that choose this form. Why do you have to insult the audience?
For an actual game you need a great story or a great concept, and for that you need to be an artist, it's not just a problem of formalized business logic and correctness. How do I draw sprites? I can draw geometric sprites, but I can't draw artistic sprites. I can make maps, but what should be on those maps? How do I even music?
Re: A software conference that advocates for quality
#149I'm disillusioned because it never happens, but purveyors of conferences and books are happy to sell the promised land™ of how "it's really going to be different this time." Processes, tools, and diligence vigilantly seem the most apparent path. Perhaps rehash the 50 year old debate of professionalization while AI vibes coding is barking at the door, because what could possibly go wrong with even less experience doin…
It doesn't happen because building the best software is not the goal of a software engineering job. If you want to do that on your own time, that's fine - but the purpose of a job is economic. Of course you should write software of some reasonable quality, but optimizations have diminishing economic returns. Eventually, the returns are lower than the cost (in time, money, etc) of further optimizing, and this break-ev…
As LLMs lower the cost of creating software, shouldn’t that change this equation? Perhaps we can be focusing on creating well done optimizations now to give more data to LLMs to have them do future optimizations on other projects. Of course you’d still eventually hit a lower bound on any returns at all, but it will be way lower than the pre-LLM era
Re: A software conference that advocates for quality
#150Earlier quoted context omitted.
It doesn't happen because building the best software is not the goal of a software engineering job. If you want to do that on your own time, that's fine - but the purpose of a job is economic. Of course you should write software of some reasonable quality, but optimizations have diminishing economic returns. Eventually, the returns are lower than the cost (in time, money, etc) of further optimizing, and this break-ev…
This is only true in certain contexts. Most of the time software quality is looked over not because it genuinely isnt important but simply because it's hard to perceive. Ive watched many businesses appreciate the benefits of software quality (happy customers, few incidents, fast feature turnaround) without ascribing it to anything in particular. Then, when it went away, they chalked up the problems to something else,…
I agree, but I think that's a different argument.
The argument here isn't "the goal of a software engineering job isn't economic", it's "sometimes quality is aligned with economic goals" (which is of course true).
If there's a 10-point scale from 0 = the most hacked-together nonsense and 10 = perfect formal proof of correctness, I'm arguing that a lot of engineers should come down from a 9 to a 6, not to a 0 (or at least, that they'd benefit from picking their battles about when to argue for a 9).
In business contexts, I often argue the opposite, trying to move them from a 3 to a 6, because nontechnical people often underestimate the importance of tech debt. That's not a typical problem on HN, though.