Hacker News Reader

Comment by Ologn | Hacker News Reader

Fred Brooks encountered a similar problem as a project manager at IBM in the early 1960s, working on the software for the System/360. In 1975 he wrote The Mythical Man Month about the experience. He said "adding manpower to a late software project makes it later". The increased communication needed was one reason. About half a century later, most businesses have still not learned these lessons.

View on HN

I once on a company where a CEO did that 3 times in a row to an engineering team, and mentioned wanting that team to be 4x its current size in two years. In an interview, he mentioned The Mythical Man Month as one of his favourite books.

so they just hope company suffer

Everyone perceives things through their perspective. Dopey CEO guy sees himself as the surgeon leading the software “surgical” team described by Brooks.

Just like there's a bunch of politicians complaining about 1984 who clearly have never opened "1984" too.

Those hundreds of millions of VC money have to be put to use. So it either advertising or more head count.

I find myself quoting the mythical man month to various poeple at least 2-3 times a week. Unfortunately no one is familiar with it (obviously) or seems to understand the point.

The other day I had PM complaining how they were going to keep their team (which has somehow grown to 10 devs!) busy after the highly sequential work was blocked by a dependency on another team...

...and who was it that failed at the outset to factor out that dependency into a clean,well-defined interface ?

That would have allowed modules/components to operate independently ,reved on different schedules, and more, but evidently too much thought at the outset ,so they just didn't even bring it up ,or passed on the opportunity if it was brought up.

They think they can't spend the resources to get it right, but they'll magically have more resources to fix the problems.

Now everyone pays.

The micro service hype appeals to managers precisely because it is a technical implementation of an organizatoral solution.

I guess I should have been more clear, as I'm not talking about microservices, but an architecture I implemented before that hype.

It was to partition the app into at least the primary segments that did different functions and had different behaviors, system resource load profiles, etc., and then mandate that those all run on separate machines (this was before everything was cloud-based), and that the relationship to entities was not 1:1. Defined clean interfaces up front. The primary goal was to be able to scale very rapidly for any big customer and/or upon discovering a scalability issue by temporarily throwing hardware at the problem, and secondarily to allow teams to rev different portions of the system on different schedules.

Both worked great, and it wasn't long before we were taking major customers away from competitors because they had scalability issues and we didn't. I'm in R&D and manufacturing now, but see no reason that this approach of fundamental modularity should not be relevant. Heck, I find high modularity to be a good approach relevant to designing industrial processes, or just setting up a shop... just keep everybody's fingers in their own pies, make the organization implement the best architecture, not make your architecture implement your org chart.

I'll be the one who gets blamed for that, but not how to do so without well defined and properly verified requirements.

(see point about about the not understanding what is being built and constantly changing the scope)

but why learn anything when you can hire a kanban/PMP/Kanzai/6 sigma/SaF or whatever is the latest BOTD (not forgetting CMMI and ITIL - the masters of vapid BS that goes nowhere)

I've tried and failed many times to get my boss to understand this.

Reply on news.ycombinator.com