I have no beef with process, I just find that the hooting and hollering over software methodology fairly asinine. Worse, the most stupid rules wind up getting embedded into company policy if you're not careful.
So, let's assume that different approaches work for different numbers of people (shocking).
How would you break down work for a > 1 MLoC codebase with lots of people on it? How do you ensure it gets done?
I would do it by having 1 person operate as a system integrator with responsibility for designing interfaces at the top level, then farming out the subcomponents to each subteam, until this reached the point of implementation. Lots of these things can be specified up front (front end! back end! database! integration with other systems! tooling! algorithms! shared utilities!) . As development ensued and new knowledge found, responsibilities would shift and new teams formed/older teams reassigned. Several key thoughts here: 1 person owns the vision of the system (call them the systems engineer), interfaces define interactions with other parts of the system, teams responsible for tightly cohesive components with loose coupling to other teams. Mind you, that's sort of Fred Brooks-ish, but why not? We haven't gotten too far from Psychology of Computer Programming in actual practice.
Its refreshing to see someone suggesting systems engineering as the solution to managing complex software projects. I have felt, and occasionally advocated, this for years. I'm actually surprised how little systems engineering methodology has penetrated the tech industry. Have CMMI and similar initiatives soured commercial enterprise on the idea?
Systems engineering is especially important when software is part of a larger multidiscipline project. All discussions here seem to focus on pure software projects.
> I'm actually surprised how little systems engineering methodology has penetrated the tech industry. Have CMMI and similar initiatives soured commercial enterprise on the idea?
I do not know. IMO, the CMMI-esque approach reeks of paperwork and micromanagement, and Agile approaches reek of lacking of planning. Both seem to be a bit problematic in their own way.
At any rate, would you mind providing some references & resources to read over for what you term systems engineering methodology? I am keen to understand other disciplines' approaches for getting engineering work done.
I'll start by directing you to the website of the membership society for systems engineers: http://www.incose.org Their products and publications section has some publicly-available documents discussing various topics.
The Systems Engineering Body of Knowledge (http://www.sebokwiki.org/) would also be a good place to start. Probably quite a bit of overlap with the INCOSE site, but better organized.
So, let's assume that different approaches work for different numbers of people (shocking).
How would you break down work for a > 1 MLoC codebase with lots of people on it? How do you ensure it gets done?
I would do it by having 1 person operate as a system integrator with responsibility for designing interfaces at the top level, then farming out the subcomponents to each subteam, until this reached the point of implementation. Lots of these things can be specified up front (front end! back end! database! integration with other systems! tooling! algorithms! shared utilities!) . As development ensued and new knowledge found, responsibilities would shift and new teams formed/older teams reassigned. Several key thoughts here: 1 person owns the vision of the system (call them the systems engineer), interfaces define interactions with other parts of the system, teams responsible for tightly cohesive components with loose coupling to other teams. Mind you, that's sort of Fred Brooks-ish, but why not? We haven't gotten too far from Psychology of Computer Programming in actual practice.