With this and your other post on sovereign methods I think you are getting to a more general point that may be helpful to you. Conway's Law (not game of life Conway) states that the design of a system recapitulates the communication structure of the organization that produces that design. Or to put it in the most polemical terms possible all software not produced by an organization designed by software engineers is going to be badly designed. Because the needs of human workers and the needs of well designed algorithms have no known relationship and you have to solve both problems simultaneously to get greatness lots of stuff that attacks the problem from one side only fails.
What I'm pointing out it that since Conway's law says they are always the same you can't just change the code you have to change the organization too or it will pull the code back to itself. Pointing out the need for a methodology that is in line with your software design tools of choice is perfectly aligned with Conway.
Your article does a good job in explaining some issues with agile.I think the strength of agile is to quickly produce some application level software that works OK-ish with a mixed bunch of developers. Some online shop software written in J2EE would be a good example for this. IMO if you are an extraordinary developer producing cleaner and more efficient code than the people around you, working in a religiously agile project will kill your passion before the first seven Scrum sprints have finished because you're confrontend with shitty code and short sighted architecture all the time.
A good example of how a non-agile project succeeds is the Linux kernel. Linus Torvalds and his mates do a fantastic job driving this software.
8 comments
1 u/nicky_haflinger 06 Dec 2015 05:47
With this and your other post on sovereign methods I think you are getting to a more general point that may be helpful to you. Conway's Law (not game of life Conway) states that the design of a system recapitulates the communication structure of the organization that produces that design. Or to put it in the most polemical terms possible all software not produced by an organization designed by software engineers is going to be badly designed. Because the needs of human workers and the needs of well designed algorithms have no known relationship and you have to solve both problems simultaneously to get greatness lots of stuff that attacks the problem from one side only fails.
1 u/bryanedds [OP] 06 Dec 2015 17:55
Conway's law is the opposite of what I'm suggesting.
In this case, it is the organizational structure that should follow the software structure, not the other way around.
So yes, literally the opposite.
0 u/nicky_haflinger 06 Dec 2015 18:16
What I'm pointing out it that since Conway's law says they are always the same you can't just change the code you have to change the organization too or it will pull the code back to itself. Pointing out the need for a methodology that is in line with your software design tools of choice is perfectly aligned with Conway.
0 u/bryanedds [OP] 06 Dec 2015 18:20
I see.
So yes, it introduces a form of organizational coupling.
I'm not sure if that's a good, bad, or even unavoidable thing.
The implications of this coupling will be something to keep a very close eye on!
1 u/atat 06 Dec 2015 07:08
Thanks for sharing. These articles are great, and kind of really touching some ideas that corporate agile overlords would find disturbing.
0 u/Komsomol 06 Dec 2015 03:13
Could you quickly explain what agile is and the TL;DR of this article?
0 u/gringo 08 Dec 2015 17:33
Your article does a good job in explaining some issues with agile.I think the strength of agile is to quickly produce some application level software that works OK-ish with a mixed bunch of developers. Some online shop software written in J2EE would be a good example for this. IMO if you are an extraordinary developer producing cleaner and more efficient code than the people around you, working in a religiously agile project will kill your passion before the first seven Scrum sprints have finished because you're confrontend with shitty code and short sighted architecture all the time.
A good example of how a non-agile project succeeds is the Linux kernel. Linus Torvalds and his mates do a fantastic job driving this software.