The Death Star Design Pattern(kkovacs.eu)
kkovacs.eu
The Death Star Design Pattern
http://kkovacs.eu/the-death-star-design-pattern
5 comments
Love this. I can name a company or two that follows this to the T.
This needs to be formalized and taught in EVERY CS/IS program. It still won't help though ... I've seen it in every large organization I've worked with.
It's not just the software development side that needs this. Project managers, functional managers, product managers, sales people and business analysts also need it. I've worked at more than one company that was doomed by building their products this way as well as on IT projects that experienced the same thing.
Why build something small that works when you can try to build something big that doesn't? This is just a nice packaging of John Gall's wisdom:
1. A complex system cannot be "made" to work. It either works or it doesn't.
2. A simple system, designed from scratch, sometimes works. Some complex systems actually work.
3. A complex system that works is invariably found to have evolved from a simple system that works.
4. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.
- https://en.wikipedia.org/wiki/Systemantics
Why build something small that works when you can try to build something big that doesn't? This is just a nice packaging of John Gall's wisdom:
1. A complex system cannot be "made" to work. It either works or it doesn't.
2. A simple system, designed from scratch, sometimes works. Some complex systems actually work.
3. A complex system that works is invariably found to have evolved from a simple system that works.
4. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.
- https://en.wikipedia.org/wiki/Systemantics
But whats the "cause" of the problem?
I posit that the very root cause, is that a group of stakeholders who don't know any better, fails to trust the person who _do_ know better.
Now, the stakeholder might have good reason to not place their trust in people actually building the system to build it properly (for instance, he/she might be a middle manager and reports to the boss/CEO, but is responsible for the failure of the project, but isn't responsible for its success). The stakeholder might attempt to place complex requirements because they think that they know it is required for the success. In other words, an attempt at somehow guarenteeing that the failure of their subordinates don't lead to their own failure. If everyone up and down the chain uses this method to conduct their business, it would lead to complex systems (and not just software systems, but also business systems - example, all these bureaucracy and paper work to get things to "sign off" and processed, and approval etc).
I propose a radical solution that might perhaps alleviate this problem (at least for software systems). The current structure of organization in companies tend to be heirachical, and this sort of structure will inevitalbly form the problem described above. So, to solve the problem, you could try a non-heirachical organization, or a very, very flat organization, where theres really only 1 level from the "worker" (someone who actually does the output) to the boss (who owns the joint). The worker's vested interest lies in the success of the project, for the payment structure has ties to the success of the project. For example, each worker is given time to "invest" in an array of projects that is needed. If the project succeeds, their contribution counts the same way equity would count for a startup.
There are no "middle managers" whose entire purpose is to summarize the progress and status for upper managers, who do more summarization and report to the boss (who may or may not understand those summaries since they are now far removed from the actual work). Instead, your project is run like a startup - you got a limited budget, you got to ship or die.
I'd like to see something run like this in the real world. Of course, i haven't fleshed out a lot of details...and there lies the devil
I posit that the very root cause, is that a group of stakeholders who don't know any better, fails to trust the person who _do_ know better.
Now, the stakeholder might have good reason to not place their trust in people actually building the system to build it properly (for instance, he/she might be a middle manager and reports to the boss/CEO, but is responsible for the failure of the project, but isn't responsible for its success). The stakeholder might attempt to place complex requirements because they think that they know it is required for the success. In other words, an attempt at somehow guarenteeing that the failure of their subordinates don't lead to their own failure. If everyone up and down the chain uses this method to conduct their business, it would lead to complex systems (and not just software systems, but also business systems - example, all these bureaucracy and paper work to get things to "sign off" and processed, and approval etc).
I propose a radical solution that might perhaps alleviate this problem (at least for software systems). The current structure of organization in companies tend to be heirachical, and this sort of structure will inevitalbly form the problem described above. So, to solve the problem, you could try a non-heirachical organization, or a very, very flat organization, where theres really only 1 level from the "worker" (someone who actually does the output) to the boss (who owns the joint). The worker's vested interest lies in the success of the project, for the payment structure has ties to the success of the project. For example, each worker is given time to "invest" in an array of projects that is needed. If the project succeeds, their contribution counts the same way equity would count for a startup.
There are no "middle managers" whose entire purpose is to summarize the progress and status for upper managers, who do more summarization and report to the boss (who may or may not understand those summaries since they are now far removed from the actual work). Instead, your project is run like a startup - you got a limited budget, you got to ship or die.
I'd like to see something run like this in the real world. Of course, i haven't fleshed out a lot of details...and there lies the devil
My favorite quote from Systemantics is, "When a Fail-Safe system fails, it fails by failing to fail safe." :) So true