That's a great solution when you understand the problem. Process is great when nobody can understand the problem. Windows is a great example of this, nobody at Microsoft really understands even 1/2 of what Windows does internally down at the code level. Now, how do you ensure a useful update comes out the door in 2015?

PS: Granted if you deal with less than 30 people process tends to be overrated.

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.

OCW has a systems engineering course posted: http://ocw.mit.edu/courses/engineering-systems-division/esd-.... There are some lecture notes available, but unfortunately the materials are a little thin.

Too pragmatic. Where are the meetings?!

Snarky, but frankly, there will be meetings very regularly with people who care & fund the project, as well as meetings within the engineering team to keep everyone abreast of what's going on.

The trick is not to have pointless meetings. Someone should get something out of the meeting besides warm fuzzies and new doodles.

> The trick is not to have pointless meetings. Someone should get something out of the meeting besides warm fuzzies and new doodles.

Agreed. I should have been more specifically snarky.

Where's the fooseball and beer?

In the 'figure out X' parts.

If web based project: Involve your operations team as early as possible.

Carry on.

Deployment plans & team should be part of initial technical planning. They are the linchpin to ensuring happy customers. No?

The move from labor-intensive, big-bang, monolithic deployments to fully automated, tested, non-event deployments has been a bigger positive change for me than any defined methodology or specific technology.

Continuous testing/building is a major component to a good project. I know it'd been done for years by some groups Agile became a Thing.

I tried to track the history of CI once[1] -- a similar practice may date back as far as the 60s at IBM. There are multiple sources indicating daily builds with tests at Microsoft from at least the early 90s (not quite CI but at the scale of the projects probably as close as practical at the time). Long before Agile became trendy in the 00's.

[1]: http://www.alittlemadness.com/2009/01/09/continuous-integrat...

Pardon me prying, but what exactly is your experience?

I'm only asking because I've seen "in my experience" sermons delivered by fresh-out-of-college kids one too many times, and have become wary of the phrase.