4 ms·

There is nothing unique about software - building almost anything has a certain amount of inherent unpredictabilities - would you hire someone to build your hou

by ejb999 4y ago

There is nothing unique about software - building almost anything has a certain amount of inherent unpredictabilities - would you hire someone to build your house with no commitment of when it would be done, what it might cost or what it might look like before it is completed? I doubt it.

sarchertech 4y ago
If you give 2 builders a set of blueprints for a house, they will build essentially the same house. If you give 2 software developers the same software spec they will give you 2 completely different pieces of software. The code is the blueprints. If you’re building a new innovative house that is different than what currently exists, the design phase is very similar to software development, and is likely to take an amount of time that is unknown at the beginning.
- pjmlp 4y ago
  Unless the construction blueprint includes the construction workers skill set, and the bill of materials, I doubt it.
  - thegrimmest 4y ago
    Construction blueprints do indeed include a schedule of materials and finishes.
    - pjmlp 4y ago
      And as we all know they always deliver on time with top quality.
      - sarchertech 4y ago
        I’m not really sure what your point is.
        pjmlp 4y ago
        That construction work is just as bad as software delivery, when the same shortcuts in quality are taken.
        sarchertech 4y ago
        That's fair. A builder could build a terrible house from the same blueprints as another built a great house. However that's not really what I'm talking about. Assuming some minimum level of quality, 2 houses built from the same blueprints with the same materials and finishes, in similar locations, and by similarly skilled craftsman will be pretty much indistinguishable from each other to the end user. That's not the case with software.
- jackcviers3 4y ago
  More analogous to software development is the design of the house with the blueprints as output, and regulations, client review, and architect creative inspiration as the software specs. Nobody complains about blueprints being delivered too slowly. They just happen on a competitive landscape where two people are racing to deliver to the client so the slowest person loses. I like kanban, a stack of tasks with predefined dependencies determining if a card can be picked up, and sorted in priority order once they can be picked up. When something critical goes wrong, the entire team stops and works the problem individually, competitively , until the problem is solved, and the team then resumes their prior work. CI/CD delivers to production, features are enabled when they are ready and the customer is ready. Feedback goes immediately back into the stack and delivery leads constantly manage the feature flags, the stack priority, and inter team communication. The devs just dev and stop the line. The team tech lead, product lead, delivery lead, architect, and program/product lead do all the negotiations and priority setting. There are no estimates. You deliver constantly. You need strong leads and architects to run this way, and you should probably coach your client to expect slow change at first, and rapid change after the first release. Done this at several clients, for several different domains, with lots of interdependent teams as a consultant, and it is highly productive. The one time it failed, we didn't get buy-in on feature flags in production and the client insisted on batched release branches and long-term maintenance branches for those cut releases. The other, minor failure, is that it is very prone to momentum. That's when teams get overconfident that they can fix problems in-band with tasks (because they've been successful for so long), and are resistant to stopping the line. This can be spotted by a person not delivering a pr for more than two weeks, or not transitioning a card to done for more than two weeks. Tech lead calls a meeting, determines the issue, decides on stop the line or not. It works. It's iterative. It keeps the number of communications channels and decision stakeholders low. It cross-polinates through linked dependencies. It ensures product cohesion thru feature flags. It evades critical missteps and bugs via stop the line. And it works well with our modern SSO dev/platform ops and integrated toolsets (Atlassian/clickup + ci pipeline of choice where docs, features, delivery can all talk to each other and reports can be generated for leads that pull from the integrated tools). It doesn't fix Conway's law, but I am not sure that actually needs fixing in truly large development houses.
dasil003 4y ago
Yes all large projects have risks, however it's ridiculous to say there's nothing unique about software. How often does a nail in one corner of a building become a dependency for a bunch of elements clear on the other side? How often does a dog house have to scale to a skyscraper because more people suddenly want to use it? How often do materials and laws of physics change in the real world? How often can you not get a clear answer on whether a specific requirement is necessary? Software is arbitrary logic which many stakeholders expect to be magic. It's not the same as any kind of construction project.
- ejb999 4y ago
  >>How often does a nail in one corner of a building become a dependency for a bunch of elements clear on the other side? Thats like asking 'how does naming my local variable X instead of Y have any dependency on code in other functions? and assuming that summarizes the complexity of writing code. I take it you have never built a large custom house from scratch.
  - dasil003 4y ago
    Seriously? Is this the nit you're going to pick on to argue my thesis? Yes, I have been privy to the pain of custom home builds and remodels. The difference is, when someone says "oh damn the plumbing isn't working as well as we would like", when the contractor says that's not feasible to fix without gutting the house back to studs at the cost of hundreds of thousands, people understand that intuitively. They don't say "can't you just drill some holes and run some new pipes diagonally through the living space". Software is malleable, opaque, and ever-changing. Construction and maintenance costs of physical infrastructure can be explained in a way that a reasonable lay person can understand. That is not true of software at scale.
etblg 4y ago
And with the same result, you can't expect someone building your house to finish it on time, on budget, the same way you expected it to be built going in to it. Construction projects in the real world end up the same way software projects end up -- with ~ ~ unforeseen ~ ~ delays and complications.

by ejb999 4y ago

sarchertech 4y ago

If you give 2 builders a set of blueprints for a house, they will build essentially the same house. If you give 2 software developers the same software spec they will give you 2 completely different pieces of software. The code is the blueprints. If you’re building a new innovative house that is different than what currently exists, the design phase is very similar to software development, and is likely to take an amount of time that is unknown at the beginning.

pjmlp 4y ago
Unless the construction blueprint includes the construction workers skill set, and the bill of materials, I doubt it.
- thegrimmest 4y ago
  Construction blueprints do indeed include a schedule of materials and finishes.
  - pjmlp 4y ago
    And as we all know they always deliver on time with top quality.
    - sarchertech 4y ago
      I’m not really sure what your point is.
      - pjmlp 4y ago
        That construction work is just as bad as software delivery, when the same shortcuts in quality are taken.
        sarchertech 4y ago
        That's fair. A builder could build a terrible house from the same blueprints as another built a great house. However that's not really what I'm talking about. Assuming some minimum level of quality, 2 houses built from the same blueprints with the same materials and finishes, in similar locations, and by similarly skilled craftsman will be pretty much indistinguishable from each other to the end user. That's not the case with software.
jackcviers3 4y ago
More analogous to software development is the design of the house with the blueprints as output, and regulations, client review, and architect creative inspiration as the software specs. Nobody complains about blueprints being delivered too slowly. They just happen on a competitive landscape where two people are racing to deliver to the client so the slowest person loses. I like kanban, a stack of tasks with predefined dependencies determining if a card can be picked up, and sorted in priority order once they can be picked up. When something critical goes wrong, the entire team stops and works the problem individually, competitively , until the problem is solved, and the team then resumes their prior work. CI/CD delivers to production, features are enabled when they are ready and the customer is ready. Feedback goes immediately back into the stack and delivery leads constantly manage the feature flags, the stack priority, and inter team communication. The devs just dev and stop the line. The team tech lead, product lead, delivery lead, architect, and program/product lead do all the negotiations and priority setting. There are no estimates. You deliver constantly. You need strong leads and architects to run this way, and you should probably coach your client to expect slow change at first, and rapid change after the first release. Done this at several clients, for several different domains, with lots of interdependent teams as a consultant, and it is highly productive. The one time it failed, we didn't get buy-in on feature flags in production and the client insisted on batched release branches and long-term maintenance branches for those cut releases. The other, minor failure, is that it is very prone to momentum. That's when teams get overconfident that they can fix problems in-band with tasks (because they've been successful for so long), and are resistant to stopping the line. This can be spotted by a person not delivering a pr for more than two weeks, or not transitioning a card to done for more than two weeks. Tech lead calls a meeting, determines the issue, decides on stop the line or not. It works. It's iterative. It keeps the number of communications channels and decision stakeholders low. It cross-polinates through linked dependencies. It ensures product cohesion thru feature flags. It evades critical missteps and bugs via stop the line. And it works well with our modern SSO dev/platform ops and integrated toolsets (Atlassian/clickup + ci pipeline of choice where docs, features, delivery can all talk to each other and reports can be generated for leads that pull from the integrated tools). It doesn't fix Conway's law, but I am not sure that actually needs fixing in truly large development houses.

dasil003 4y ago

Yes all large projects have risks, however it's ridiculous to say there's nothing unique about software. How often does a nail in one corner of a building become a dependency for a bunch of elements clear on the other side? How often does a dog house have to scale to a skyscraper because more people suddenly want to use it? How often do materials and laws of physics change in the real world? How often can you not get a clear answer on whether a specific requirement is necessary? Software is arbitrary logic which many stakeholders expect to be magic. It's not the same as any kind of construction project.

ejb999 4y ago
>>How often does a nail in one corner of a building become a dependency for a bunch of elements clear on the other side? Thats like asking 'how does naming my local variable X instead of Y have any dependency on code in other functions? and assuming that summarizes the complexity of writing code. I take it you have never built a large custom house from scratch.
- dasil003 4y ago
  Seriously? Is this the nit you're going to pick on to argue my thesis? Yes, I have been privy to the pain of custom home builds and remodels. The difference is, when someone says "oh damn the plumbing isn't working as well as we would like", when the contractor says that's not feasible to fix without gutting the house back to studs at the cost of hundreds of thousands, people understand that intuitively. They don't say "can't you just drill some holes and run some new pipes diagonally through the living space". Software is malleable, opaque, and ever-changing. Construction and maintenance costs of physical infrastructure can be explained in a way that a reasonable lay person can understand. That is not true of software at scale.

etblg 4y ago

And with the same result, you can't expect someone building your house to finish it on time, on budget, the same way you expected it to be built going in to it. Construction projects in the real world end up the same way software projects end up -- with ~ ~ unforeseen ~ ~ delays and complications.