10 ms·
It's the second time I mention Fred Brooks on HN today, but he dedicates a chapter in Mythical Man-Month that agrees with the assertion of the article: > Much
by revvx 7y ago
It's the second time I mention Fred Brooks on HN today, but he dedicates a chapter in Mythical Man-Month that agrees with the assertion of the article:
> Much as a surgical team during surgery is led by one surgeon performing the most critical work, while directing the team to assist with less critical parts, it seems reasonable to have a "good" programmer develop critical system components while the rest of a team provides what is needed at the right time.
Other team members perform other tasks, and some of those even administrative (!), but all of them supporting the "vision" of the surgeon.
IMO this is a healthier way of communicating roles, avoiding fights and training juniors. It's better than the "everyone is replaceable" mindset companies have this day.
- colechristensen 7y agoYou can (should) also give leadership to juniors on appropriately sized projects. That's how you make better programmers.
- theshrike79 7y agoYou should give leadership/ownership/responsibility of smaller components of the larger vision to juniors or people new to the team.
- GrumpyNl 7y agoMost companies want more business value, they dont care for better programmers.
- jdc 7y agoNext time said companies complain about a talent shortage, they would do well to remember TANSTAAFL.
- aerophilic 7y agoBecause I had to look it up: TANSTAAFL = There ain't no such thing as a free lunch
- JustSomeNobody 7y agoTANSTAAFL Have that ingrained in my mind since reading Abrash forever ago.
- phkahler 7y agoYou mean Heinlein?
- JustSomeNobody 7y agoNever read Heinlein.
- Nasrudith 7y agoI know it is reification but most companies end in banrkruptcy. In all seriousness I have noticed that "business value tunnel vision" is one of the surest ways to run a company into the ground in many if not most fields and Wall Street keeps pushing it anyway to nobody's benefit. The fundamentals of the field are what you have to care about or else you will have a really bad time.
- colechristensen 7y agoYes, and investing in employees pays dividends. Many businesses are poorly invested and put themselves at a disadvantage.
- tomnipotent 7y ago> also give leadership to juniors You don't give leadership - you assign ownership, and hope leadership evolves from those responsibilities. Leadership is nurtured by helping the junior navigate issues, holding a vision for them long enough until they can realize it on their own. There's a reason good leadership is so rare and appreciated, and it's not because it grows on trees.
- pmoleri 7y agoExcept that you're usually building knowledge specific to the organization in which you're working. IMO, you should avoid monopolizing vision and knowledge. I see this as different to the surgical team, where each patient is a different "project".
- asimpletune 7y agoCommunication and knowledge should be considered part of the product. You often times still need these kinds of developers to deliver even this aspect. Basically someone who groks the project so thoroughly that they can synthesize disparate pieces of information into something holistic and absorbable.
- revvx 7y agoBuilding good documentation and sharing knowledge is crucial for such teams to work, according to Brooks. Brooks is all about (good) communication. The "Surgical Team" chapter comes right after the "Communication" chapter in MMM. And I don't think that having other members of the team supporting the vision of the leader is monopolizing the vision... it's just being focused on a single goal.
- Nasrudith 7y agoThere are trade offs to everything - generally I haven't seen the best results from attempts to make people inteechangeable to put it mildly.
- Data_Junkie 7y agoYeah, because at a certain level it's not monopolizing knowledge, it's just not letting people without ability act as though their lack of ability is inconsequential and their agendas matter. In surgery they don't have lack of ability or agendas.
- LoSboccacc 7y agothere's one issue that large companies face, after two/three years all the juniors in the "surgery team" model start looking at position of seniority within or outside the company, causing high concentrated turnover in such built teams. the surgical team is great in a crunch but long term you need to stagger your turnover to keep competency on the project high. this isn't as relevant on team that are building projects as they were in the mmm time, today companies tend to build service software that has maybe the same shelf life but gets continuously improved instead of being dropped whole and left into maintenance mode.
- NotAnEconomist 7y ago> after two/three years all the juniors in the "surgery team" model start looking at position of seniority within or outside the company, causing high concentrated turnover in such built teams Is that a problem? I mean, the same thing happens with literal surgeons/doctors and residency, where their early years of career eventually end and they expect a mid-level position in the organization. It sounds like a healthy industry that juniors/apprentices work under journeymen and masters at a large organization early in their career, then move up or branch out after a few years. I'm not sure why companies expect to be able to cost-optimize away a functioning economy, but remain in business.
- LoSboccacc 7y agowhile moving on is natural for the persons to a software company it's a costly proposition and quite different than surgeon teams, because while humans are all more or less similar projects are wildly different so there's less interchangeability. also while surgeon tend to specialize into one in the many fields, programmers that rise in a "surgical team" tend to become of the "full stack" variety > not sure why companies expect to be able to cost-optimize away a functioning economy I'm with you here, I'm not stating this is the optimal way to handle the issue, just reporting the patterns I saw on many workplaces of all kind I've ben into
- Nasrudith 7y agoThat sounds like a secondary management problem to have other projects lined up. Although that isn't new - one or two years is already an effectively encouraged time to look for new jobs because raises don't keep up and changing jobs is the current defacto way to raise salaries. Seems like a needless expense and hassle to all involved and yet it seems strongly preferred oddly.
- bigred100 7y agoThis sounds like a question for management. I suspect the healthy attitude is to not even care what a good managerial approach is—simply show up, do whatever the easiest thing that lines up with management priorities, and leave, managing the rest of your career outside this. Unfortunately I feel like some managers become enraged if you “check out” of doing their managerial duties for them
- taeric 7y agoSurgery is a dangerous comparison to make. Most surgeons get to their seniority by doing a lot of surgery. Most of which are near identical to each other. Programmers? We, for some reason pride ourselves on doing something new every time around, it seems. I've argued before with my leadership that, if we really wanted something done better/faster, we shouldn't be promoting the folks that did it out of the position for the next go around. Rather, we should have them do it again. And then again. And then again. Not only would they be learning from their experiences, but benefiting much more directly.
- revvx 7y ago> I've argued before with my leadership that, if we really wanted something done better/faster, we shouldn't be promoting the folks that did it out of the position for the next go around This is similar to what Fred Brooks suggests in the "Surgical Team" chapter of "Mythical Man Month", although he's a bit harsh, I'll grant that: > if a 200-man project has 25 managers who are the most competent and experienced programmers, fire the 175 troops and put the managers back to programming. EDIT: We were also talking about it yesterday here at HN: https://news.ycombinator.com/item?id=19763562 https://news.ycombinator.com/item?id=19763562
- bartimus 7y agoAnd not forget to fire those other managers who never wrote a single line of code. Or anyone who thinks in terms like 'programmers' and 'resources'.
- lifeisstillgood 7y agoMicrosoft has an idea like this - with the same surgical analogy. Sometime during the MS Word initial development process they tried it out - and the "surgeons" loved the idea, but everyone else hated it - especially as the half fleshed out ideas from the surgeons turned out poor or wrong. I think the skill differences between individual contributors are never as great as you think. cf "Software Heroes" book - has a wireframe cowboy hat in the front cover. v good
- deleted 7y ago[deleted]
- aaronbrethorst 7y agoJoel Spolsky talks a little about this: https://www.joelonsoftware.com/2000/10/04/painless-functional-specifications-part-3-but-how/ https://www.joelonsoftware.com/2000/10/04/painless-functiona...
- revvx 7y agoMicrosoft's idea was very different from what Brooks describes in his book. Microsoft approach was more about having senior programmers telling juniors what and how to do their job, aka micromanagement. Brooks is about having programmers actually coding (and documenting), and have other people handling and other important tasks such as clerical non-programming tasks, developing tools, language research, version management, doing adversarial testing, helping with documentation, etc. Some of the tasks he describe are obsolete these days, but the book is from the early 70s. According to him, doing that "relieves programmers of clerical chores, systematizes and ensures proper performance of those oft neglected chores, and enhances the team's most valuable asset — its work-product".
- baby 7y agoLet me chime in. I've been consulting crypto(graphic) projects for years and systems that are developed by one person are way way clearer and simple than systems developed by nultiple developers. Things like TLS become a mess once multiple developers start collaborating. It's weird. My theory is that one dev working on a project can refactor it many times during development, whereas this would be an insane thing to do when collaborating.
- pvorb 7y agoWhy would major refactoring be insane when collaborating? We do this regularly in my team in early stages of projects and only when really required once projects become stable. But these projects are usually not about crypto, so I might miss the difference here.
- revvx 7y agoYes. After many years I have exactly the same experience that you do. Programming intent and vision is hard to communicate, so sharing code is always a compromise. It's much better to work with smaller units of code that communicate with each other using simple, clear and testable APIs.
- greenyoda 7y ago> systems that are developed by one person are way way clearer and simple than systems developed by multiple developers Brooks called this "conceptual integrity": https://en.wikipedia.org/wiki/The_Mythical_Man-Month#Conceptual_integrity https://en.wikipedia.org/wiki/The_Mythical_Man-Month#Concept...