3 ms·
I think this touches on an interesting problem. I don't see a reason to praise security experts though. Here's a theory on why (some form of) Agile is problem
by smokel 2y ago
I think this touches on an interesting problem. I don't see a reason to praise security experts though.
Here's a theory on why (some form of) Agile is problematic: Subdividing work into smaller parts is typically beneficial. However, in computer programming, this approach often fails because even the smaller tasks require some creativity, and unexpected challenges are likely to arise.
The person who did the subdividing gains a lot of insight while breaking down the larger problem. However, when transferring a portion of the work to a developer, much of this knowledge is inherently lost. The developer must then devise a creative solution, and lacking the necessary information, may either come up with a suboptimal solution or need further communication with the original architect.
There is no clear-cut solution. Some might argue for more experienced developers who have all the necessary knowledge readily available in their heads. Others might advocate for better design diagrams and documentation to capture all the relevant information. Ultimately, it requires careful consideration, or luck, to strike the right balance. But the dogmas of Agile certainly aren't helping much.
- skydhash 2y agoThere are always interdependent units and I think the main issue is when we broke down those units into smaller tasks and then transfer the individual task to be implemented in isolation. There should always be someone that own that unit as a whole even if his job is only to answer architectural questions. A unit is assigned to one team (ad hoc or fixed) and a person (if the members count is greater than 3) is directing the implementation. I still think that the team layout in The Mythical Man month is one of the best for software projects.
- ryandv 2y agoRight; "the surgeon" in Brooks' proposed team structure has the responsibility of maintaining the "theory" of the program as described by Peter Naur in 1985.
- ryandv 2y ago> lacking the necessary information, may either come up with a suboptimal solution or need further communication with the original architect. > Others might advocate for better design diagrams and documentation to capture all the relevant information. During the design phase group B made suggestions for the manner in which the extensions should be accommodated and submitted them to group A for review. In several major cases it turned out that the solutions suggested by group B were found by group A to make no use of the facilities that were not only inherent in the structure of the existing compiler but were discussed at length in its documentation, and to be based instead on additions to that structure in the form of patches that effectively destroyed its power and simplicity. [...] This is an example of how the full program text and additional documentation is insufficient in conveying to even the highly motivated group B the deeper insight into the design, that theory which is immediately present to the members of group A. [...] A very important consequence of the Theory Building View is that program revival, that is reestablishing the theory of a program merely from the documentation, is strictly impossible. [0] [0] https://pages.cs.wisc.edu/~remzi/Naur.pdf https://pages.cs.wisc.edu/~remzi/Naur.pdf
- smokel 2y agoVery interesting, thanks for sharing. There have been multiple discussions on this text here before, but I seem to have missed them all :)