4 ms·

I don't feel its possible for software to be built toward the end of itself. All software has users, even if that user is just yourself (the author of the softw

by 015a 2y ago

I don't feel its possible for software to be built toward the end of itself. All software has users, even if that user is just yourself (the author of the software). There's always a stakeholder who stands as the impetus for Why some feature gets added, or why the code is spring-cleaned, or whatever; the software doesn't demand anything of itself. I only say that to say: I think the actual conclusion I'd draw from the idea this post puts forward is, well, two things: First, that the best software is software built by its biggest and most zealous users; software built for other people exclusively is never, never good. Second, that the best software has features no one is asking for, the "I've got a feeling we'll want to be able to sort on that table" kind of features, some people would call this quality Good Taste. The process which produces most software the world uses seems almost intentionally designed to throw both those conclusions to the curb. That, to me, explains almost all of why software quality has nosde-dived over the past 10 years. Its the old story about how the designers and product managers on the Windows team at Microsoft all use Macs.

rrr_oh_man 2y ago
> The process which produces most software the world uses seems almost intentionally designed to throw both those conclusions to the curb. Scrum?
- robertlagrant 2y ago
  Scrum can deliver any sort of feature for whatever reason. Not because it's amazing; just because it doesn't have an opinion on what features are good. I read this more as purely data-driven product decisions, or three years of UX research before we get building, those sorts of approaches.
- 015a 2y ago
  Eh, not really scrum/agile. These are IMO bad ways to build software, especially when taken to the dictionary-definition extreme of the process, but they're not what I'm talking about. I'm more-so referencing e.g. Amazonian Data-Driven Decision Making. That the nature of this kind of process puts taste behind data, even erroneous interpretations of data or incomplete data, data is data and data is king; organizations quickly lose any sense of taste they may have had as decision making is predominated by data analysis. This process looks down on someone finding data to support a conclusion they want to reach, but in reality this is the only way to build great software: Starting with good taste, and supporting that taste with data, metrics, and experimentation. Cherry-picking is fantastic; instead we larp scientists. To a similar degree, I'm also referencing over-specialization in enterprise companies. The classic Office Space bit: "We don't let the engineers talk to customers". Computers give us an effectively-infinite second-brain and effectively-infinite automation capability, if used correctly. This idea that we need a multi-disciplinary team of a dozen people to build anything, each person holding one small piece of the puzzle like a precious gem, is antiquated; it predictably leads to the vast, vast majority of all billable person-hours being spent on self-inflicted problems and context transfer. At minimum, many extremely successful companies organize themselves around multi-disciplinary individuals & vertical teams, instead of specialized individuals and horizontal teams; this is great. But, as we live through the birth of AI rather quickly gaining many of the capabilities of these specialized individuals, I think we'll inevitably see the most profitable and productive companies and teams get smaller and smaller.
hiAndrewQuinn 2y ago
Yes, I'd agree with this. The phrase is just a little too blunt to be fully accurate, which is why I like it. Many things in life seem to work optimally when we take them with an "ebb-and-flow" style pattern. For example, I'm a fan of seasons of feast and seasons of famine when it comes to trying out new software: In seasons of feast, I throw caution to the wind and try anything new and shiny which looks appealing to me, and then in seasons of famine, I prune, prune, prune away anything which doesn't directly serve my purpose. There's a similar ebb and flow here. The largest community is very "means to an end" oriented. The power users often view the tool as a thing of beauty in itself, at least for a little while. That's the "end in itself" ebb. The hackers transcend this and view the tool as an imperfect, vexing beauty, and wish to create something even more beautiful -- but that's where things wrap back around, because the beauty does ultimately come from how well it is suited as a means to the end!

by 015a 2y ago

rrr_oh_man 2y ago

> The process which produces most software the world uses seems almost intentionally designed to throw both those conclusions to the curb. Scrum?

robertlagrant 2y ago
Scrum can deliver any sort of feature for whatever reason. Not because it's amazing; just because it doesn't have an opinion on what features are good. I read this more as purely data-driven product decisions, or three years of UX research before we get building, those sorts of approaches.
015a 2y ago
Eh, not really scrum/agile. These are IMO bad ways to build software, especially when taken to the dictionary-definition extreme of the process, but they're not what I'm talking about. I'm more-so referencing e.g. Amazonian Data-Driven Decision Making. That the nature of this kind of process puts taste behind data, even erroneous interpretations of data or incomplete data, data is data and data is king; organizations quickly lose any sense of taste they may have had as decision making is predominated by data analysis. This process looks down on someone finding data to support a conclusion they want to reach, but in reality this is the only way to build great software: Starting with good taste, and supporting that taste with data, metrics, and experimentation. Cherry-picking is fantastic; instead we larp scientists. To a similar degree, I'm also referencing over-specialization in enterprise companies. The classic Office Space bit: "We don't let the engineers talk to customers". Computers give us an effectively-infinite second-brain and effectively-infinite automation capability, if used correctly. This idea that we need a multi-disciplinary team of a dozen people to build anything, each person holding one small piece of the puzzle like a precious gem, is antiquated; it predictably leads to the vast, vast majority of all billable person-hours being spent on self-inflicted problems and context transfer. At minimum, many extremely successful companies organize themselves around multi-disciplinary individuals & vertical teams, instead of specialized individuals and horizontal teams; this is great. But, as we live through the birth of AI rather quickly gaining many of the capabilities of these specialized individuals, I think we'll inevitably see the most profitable and productive companies and teams get smaller and smaller.

hiAndrewQuinn 2y ago

Yes, I'd agree with this. The phrase is just a little too blunt to be fully accurate, which is why I like it. Many things in life seem to work optimally when we take them with an "ebb-and-flow" style pattern. For example, I'm a fan of seasons of feast and seasons of famine when it comes to trying out new software: In seasons of feast, I throw caution to the wind and try anything new and shiny which looks appealing to me, and then in seasons of famine, I prune, prune, prune away anything which doesn't directly serve my purpose. There's a similar ebb and flow here. The largest community is very "means to an end" oriented. The power users often view the tool as a thing of beauty in itself, at least for a little while. That's the "end in itself" ebb. The hackers transcend this and view the tool as an imperfect, vexing beauty, and wish to create something even more beautiful -- but that's where things wrap back around, because the beauty does ultimately come from how well it is suited as a means to the end!