3 ms·

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 th

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.

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.