3 ms·

Regarding the Empire state building example, most floors are pretty similar (loop); and "deeply experienced builders" of software will try to encapsulate their

Regarding the Empire state building example, most floors are pretty similar (loop); and "deeply experienced builders" of software will try to encapsulate their experience away with code reuse of some kind after a few times (library), rendering their expertise redundant. The nature of software prevents experience.

dhosek 4y ago
> The nature of software prevents experience. This feels like a profound statement about programming work. And at the same time, I find myself pushing back on it in that we end up encountering things that are enough like something else but can’t be encapsulated in a library that experience still counts, whether that surfaces in the form of common practices (algorithms, design patterns, programming idioms, etc.) or just plain experience (I’ve seen this king of bug before).
- hyperthesis 4y ago
  I think it's true in that context, of similar buildings, with similar floors. People are clever, and can optimize repetitive work. Out of context, I intended it to express an ideal, that we should strive to encapsulate our experience, of those similarities. One barrier is insufficient data to formalize just what that similarity is, and how it applies across different scenarios, especially when hidden amongst other factors. Arguably, ChatGPT is a way of capturing such similarities - though not in a library. I agree your suggestion of standard practices is difficult to capture. They are a kind of language for communication with other programmers, so encapsulating them defeats their purpose. Debugging is another good one - if the same type of bug keeps coming up, can we automate it away? If so, is that solution "software". Another task that is difficult to capture is defining the problem, because this involves the world, with all its detail and complexity to cut through - though some would say that "isn't software".
r_hoods_ghost 4y ago
Every time I read something like this I feel like I am living in a parallel world. It really, really doesn't. Now if you were to say "the nature of web development and hn adjacent company hiring practices where people move every 18 months, coupled with ageism and fashion based development that constantly reinvents the wheel prevents experience" then I would agree.
Juliate 4y ago
That’s a pretty limited and limiting statement. That you could also apply to all other kind of craft (music, painting, sculpture, woodworking, building, etc.): you _could_ understand it of having a limited set of tools, techniques and vocabulary, to serve about often the same kind of output. But now, output still vary greatly to the accustomed eye/ear/body, and how you get to that output even more so. Experience (and taste, which refines with it) will always make a difference: how the need is understood, which technique to apply, which hypothesis to form, which to explore or relegate, how to plan/distribute work (on one’s own or on a team), how it will feel working on it, how people will be satisfied, how fast, how well, how costly, etc. all the way to the finished « thing ». Edit: a very specific/limited example: working on the very same project from the different perspectives of a large worldwide consultancy team, a local-based design/tech studio, or a two-people startup team will be a hell of a ride because from project to tech to business to people, expectations, vocabulary, behavior, speed of execution, focus, know-how, freedom to experiment, tools, so many stuff will differ.
- shoo 4y ago
  Sometimes experience can even be harmful. Suppose an individual or a team encountered one situation, and worked very hard to explore, figure out a viable "attack" to solve it, perhaps after a number of failures. Now they have experience. Suppose they're hired to help another project which is in a similar situation -- perhaps instead of repeating what they did the first time, instead of exploring they jump straight to applying the solution that worked before. If the situation is similar but not enough for the same solution to work, then maybe the outcome is going to be worse than if inexperienced folk with reasonable problem solving skills were thrown at it.
  - Juliate 4y ago
    Definitely. But we are all to be « haunted » by our own experience if we are to live, and to have to know how/when not to take it into account (which in itself is some form of experience too).
  - sanitycheck 4y ago
    In the universe I inhabit the opposite happens. For any number of consecutive similar problems teams will pick a different approach/technology each time, because they "already did that" and the needs of the project/business are secondary to their desire for novelty.
shoo 4y ago
When thinking about applying "lean" approaches to delivery of software projects, one easy but flawed analogy is to think of a manufacturing plant churning out some kind of widget. Say, we're manufacturing zippers. In the case of the software project, instead of delivering increments that consist of batches of partly assembled zippers, and handing them off to the next stage for bending or finishing or whatever, we deliver project increments brimming with new features, defect fixes, etc. In the case of the widget factory, you get many attempts at building exactly the same thing. In a typical software project, there's only ever one thing, and with each change in each increment, you're constantly changing the design and construction of that single, increasingly complicated thing. From this perspective, both the case studies of the Empire state building and the Polaris missile system are much better approximations of how incremental design and delivery work in software projects than the mental model of a factory churning out indistinguishable widgets. One can argue most floors in the empire state building are pretty similar, so experience gained while designing and building the 3rd floor can apply to the 53rd, and to some degree that's true. But if we mistake our floor building for zipper manufacturing and conclude this means we will be able to keep adding another 25 floors per quarter and extending the height of the building indefinitely, as we gain more and more experience at building floors, boy are we are in for a big surprise. The floors aren't independent, the project is to design and deliver a single system - the building - each increment during the project modifies that single thing. We'd better have some people involved who are thinking really hard about how the entire system is going to come together, what constraints the whole system is under, and testing our design and build assumptions.

dhosek 4y ago

> The nature of software prevents experience. This feels like a profound statement about programming work. And at the same time, I find myself pushing back on it in that we end up encountering things that are enough like something else but can’t be encapsulated in a library that experience still counts, whether that surfaces in the form of common practices (algorithms, design patterns, programming idioms, etc.) or just plain experience (I’ve seen this king of bug before).

hyperthesis 4y ago
I think it's true in that context, of similar buildings, with similar floors. People are clever, and can optimize repetitive work. Out of context, I intended it to express an ideal, that we should strive to encapsulate our experience, of those similarities. One barrier is insufficient data to formalize just what that similarity is, and how it applies across different scenarios, especially when hidden amongst other factors. Arguably, ChatGPT is a way of capturing such similarities - though not in a library. I agree your suggestion of standard practices is difficult to capture. They are a kind of language for communication with other programmers, so encapsulating them defeats their purpose. Debugging is another good one - if the same type of bug keeps coming up, can we automate it away? If so, is that solution "software". Another task that is difficult to capture is defining the problem, because this involves the world, with all its detail and complexity to cut through - though some would say that "isn't software".

r_hoods_ghost 4y ago

Every time I read something like this I feel like I am living in a parallel world. It really, really doesn't. Now if you were to say "the nature of web development and hn adjacent company hiring practices where people move every 18 months, coupled with ageism and fashion based development that constantly reinvents the wheel prevents experience" then I would agree.

Juliate 4y ago

That’s a pretty limited and limiting statement. That you could also apply to all other kind of craft (music, painting, sculpture, woodworking, building, etc.): you _could_ understand it of having a limited set of tools, techniques and vocabulary, to serve about often the same kind of output. But now, output still vary greatly to the accustomed eye/ear/body, and how you get to that output even more so. Experience (and taste, which refines with it) will always make a difference: how the need is understood, which technique to apply, which hypothesis to form, which to explore or relegate, how to plan/distribute work (on one’s own or on a team), how it will feel working on it, how people will be satisfied, how fast, how well, how costly, etc. all the way to the finished « thing ». Edit: a very specific/limited example: working on the very same project from the different perspectives of a large worldwide consultancy team, a local-based design/tech studio, or a two-people startup team will be a hell of a ride because from project to tech to business to people, expectations, vocabulary, behavior, speed of execution, focus, know-how, freedom to experiment, tools, so many stuff will differ.

shoo 4y ago
Sometimes experience can even be harmful. Suppose an individual or a team encountered one situation, and worked very hard to explore, figure out a viable "attack" to solve it, perhaps after a number of failures. Now they have experience. Suppose they're hired to help another project which is in a similar situation -- perhaps instead of repeating what they did the first time, instead of exploring they jump straight to applying the solution that worked before. If the situation is similar but not enough for the same solution to work, then maybe the outcome is going to be worse than if inexperienced folk with reasonable problem solving skills were thrown at it.
- Juliate 4y ago
  Definitely. But we are all to be « haunted » by our own experience if we are to live, and to have to know how/when not to take it into account (which in itself is some form of experience too).
- sanitycheck 4y ago
  In the universe I inhabit the opposite happens. For any number of consecutive similar problems teams will pick a different approach/technology each time, because they "already did that" and the needs of the project/business are secondary to their desire for novelty.

shoo 4y ago

When thinking about applying "lean" approaches to delivery of software projects, one easy but flawed analogy is to think of a manufacturing plant churning out some kind of widget. Say, we're manufacturing zippers. In the case of the software project, instead of delivering increments that consist of batches of partly assembled zippers, and handing them off to the next stage for bending or finishing or whatever, we deliver project increments brimming with new features, defect fixes, etc. In the case of the widget factory, you get many attempts at building exactly the same thing. In a typical software project, there's only ever one thing, and with each change in each increment, you're constantly changing the design and construction of that single, increasingly complicated thing. From this perspective, both the case studies of the Empire state building and the Polaris missile system are much better approximations of how incremental design and delivery work in software projects than the mental model of a factory churning out indistinguishable widgets. One can argue most floors in the empire state building are pretty similar, so experience gained while designing and building the 3rd floor can apply to the 53rd, and to some degree that's true. But if we mistake our floor building for zipper manufacturing and conclude this means we will be able to keep adding another 25 floors per quarter and extending the height of the building indefinitely, as we gain more and more experience at building floors, boy are we are in for a big surprise. The floors aren't independent, the project is to design and deliver a single system - the building - each increment during the project modifies that single thing. We'd better have some people involved who are thinking really hard about how the entire system is going to come together, what constraints the whole system is under, and testing our design and build assumptions.