Peter Lund (peterfirefly.delete@this.gmail.com) on November 27, 2014 1:10 pm wrote:
> rwessel (robertwessel.delete@this.yahoo.com) on November 24, 2014 11:48 pm wrote:
> > OTOH, it's hard to credit those decisions to any brilliant insights (or lack thereof),
> > the pipelining and decode issues just weren't relevant at the time.
>
> Thank god for *short* design phases where people just have to come up with a non-sucky
> upgrade to existing architectures. It limits the damage/cleverness :)

This is actually one of my key guiding principles as a system architect: First you figure out how many people you'll have available to take the system to production, and then you limit the initial design team to a very small fraction of that and hold them to a very tight schedule.

I deeply believe that engineering is an entropy-driven process: The complexity always expands to fill the available staffing, typically for seemingly "good" and difficult-to-argue reasons. One way to control complexity in large groups is therefore to impose draconian staffing constraints so that people are forced to make uncomfortable tradeoffs (you can also can have a single "benign dictator" at the top a la Linus, but that's difficult to sustain in larger companies).