6 ms·

The problem with software development methodologies is they are sold as a solution for problems that arise from organizational/cultural dysfunctions. Up front a

The problem with software development methodologies is they are sold as a solution for problems that arise from organizational/cultural dysfunctions. Up front analysis is not the problem, the problem is that the people charged with implantation are not given the big picture view and the flexibility to adapt the solution. Instead of using the term waterfall as the counterpoint of agile I prefer to call it the human centipede model. In this model all of the vision, creativity, and flexibility stays with the head and the rest of the centipede just eats their shit. Developers can't see further than the next person's ass and have no idea why they are actually building the functional specifications that are fed to them. Implementation becomes completely disconnected from design which leads to compromised quality, missed deadlines, and products that miss the mark. No task management framework is going to solve these problems.

bhawks 5y ago
The sad fact is just how many organizations are so utterly dysfunctional and how many people follow the centipede model without even realizing it.
throwawayboise 5y ago
Is it just a problem of inadequate specification? Because the methodology seems to work with physical systems. If I design a machine, and I need a gear or a cam or even a more complex component, I can send the specifications for that part to a machinist who knows nothing about the "big picture" of what I am building. Yet he can make that part of it to perfection. Does this lead to the same sort of problems with the development of physical systems?
- stevegalla 5y ago
  > Does this lead to the same sort of problems with the development of physical systems? I would argue that physical systems aren’t developed in a “waterfall” method. In mechanical design classes in engineering school, we learned to start with low fidelity sketches to capture customer intent. We come up with several options, build those into increasingly higher fidelity 3D models, use simulation to refine, take a few candidates and get physical prototypes, do physical testing (strength, endurance, integration, etc.), determine the best one, then go into limited production to prove out and establish the production process, then go into full production. We are taught (and in the automotive industry it’s a requirement) to have cross functional teams involved in the design stages of both the item and the manufacturing process. To your point about inadequate spec: My opinion is there are so many different backgrounds coming into software that there is no common language or background. I think everyone thinks their way is better and it’s hard to communicate technical ideas when you need to constantly recreate and translate between terminology and documentation methods. This lack of convergence and common knowledge is what I think results in poor specs.
- Ma8ee 5y ago
  The problem with comparing software development with manufacturing physical artifacts is that the phases are mixed up. The manufacturing, creating the artifact, in the case of software, is a wholly automated process usually done by a compiler (or similar). The compiler doesn’t need to know shit about the big picture and usually produces the artifact exactly as specified, as your machinist. So software development are all about writing down the specifications precisely enough for the compiler to create the artifact. Mixing up this process with manufacturing is a source of many of the problems in software development.
legulere 5y ago
> Up front analysis is not the problem It depends, the idea of working in short sprints with deliverables at the end of it is that often you do not know what you need and the best way of finding out is by trying out and talking to the customer. The place I'm currently working at is agile on paper but 90% of the work is just implementing external requirements we have no say in. Needless to say, not analysing the problem up front and not designing the general architecture up front leads to building roadblocks later on that prevent getting work done. To stay with your metaphor: Sometimes you have to eat shit (because of legal requirements, etc.). Planning ahead is very useful in those situations for not choking on the shit.
anodari 5y ago
I call this the problem of noise and loss of information. If someone has to write a specification and move on to another one, there will be a noise. Imagine customer -> product -> analyst / ux -> dev. etc. At each level, a little bit of information is lost. One possible solution is that the devs. are partly involved in all phases of the specification and design. This could reduce the problem of noise and loss.
- Tagbert 5y ago
  One way to fight information loss is through error correction. That means a feedback loop between the stages in this process where downstream results are reviewed by upstream actors to evaluate their suitability. Agile tries to build that in by iterative work, demos, and retrospectives.
deleted 5y ago
[deleted]

bhawks 5y ago

The sad fact is just how many organizations are so utterly dysfunctional and how many people follow the centipede model without even realizing it.

throwawayboise 5y ago

Is it just a problem of inadequate specification? Because the methodology seems to work with physical systems. If I design a machine, and I need a gear or a cam or even a more complex component, I can send the specifications for that part to a machinist who knows nothing about the "big picture" of what I am building. Yet he can make that part of it to perfection. Does this lead to the same sort of problems with the development of physical systems?

stevegalla 5y ago
> Does this lead to the same sort of problems with the development of physical systems? I would argue that physical systems aren’t developed in a “waterfall” method. In mechanical design classes in engineering school, we learned to start with low fidelity sketches to capture customer intent. We come up with several options, build those into increasingly higher fidelity 3D models, use simulation to refine, take a few candidates and get physical prototypes, do physical testing (strength, endurance, integration, etc.), determine the best one, then go into limited production to prove out and establish the production process, then go into full production. We are taught (and in the automotive industry it’s a requirement) to have cross functional teams involved in the design stages of both the item and the manufacturing process. To your point about inadequate spec: My opinion is there are so many different backgrounds coming into software that there is no common language or background. I think everyone thinks their way is better and it’s hard to communicate technical ideas when you need to constantly recreate and translate between terminology and documentation methods. This lack of convergence and common knowledge is what I think results in poor specs.
Ma8ee 5y ago
The problem with comparing software development with manufacturing physical artifacts is that the phases are mixed up. The manufacturing, creating the artifact, in the case of software, is a wholly automated process usually done by a compiler (or similar). The compiler doesn’t need to know shit about the big picture and usually produces the artifact exactly as specified, as your machinist. So software development are all about writing down the specifications precisely enough for the compiler to create the artifact. Mixing up this process with manufacturing is a source of many of the problems in software development.

legulere 5y ago

> Up front analysis is not the problem It depends, the idea of working in short sprints with deliverables at the end of it is that often you do not know what you need and the best way of finding out is by trying out and talking to the customer. The place I'm currently working at is agile on paper but 90% of the work is just implementing external requirements we have no say in. Needless to say, not analysing the problem up front and not designing the general architecture up front leads to building roadblocks later on that prevent getting work done. To stay with your metaphor: Sometimes you have to eat shit (because of legal requirements, etc.). Planning ahead is very useful in those situations for not choking on the shit.

anodari 5y ago

I call this the problem of noise and loss of information. If someone has to write a specification and move on to another one, there will be a noise. Imagine customer -> product -> analyst / ux -> dev. etc. At each level, a little bit of information is lost. One possible solution is that the devs. are partly involved in all phases of the specification and design. This could reduce the problem of noise and loss.

Tagbert 5y ago
One way to fight information loss is through error correction. That means a feedback loop between the stages in this process where downstream results are reviewed by upstream actors to evaluate their suitability. Agile tries to build that in by iterative work, demos, and retrospectives.

deleted 5y ago

[deleted]