

The Death Star Design Pattern - kkovacs
http://kkovacs.eu/the-death-star-design-pattern

======
davidtyleryork
Love this. I can name a company or two that follows this to the T.

------
smoyer
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.

~~~
SoftwareMaven
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>

~~~
chii
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

