8 ms·

In my career I have seen almost identical systems being built by a) 6 developers in a startup in 1 year b) 100+ developers in a big company with a much much lar

by dagss 3y ago

In my career I have seen almost identical systems being built by a) 6 developers in a startup in 1 year b) 100+ developers in a big company with a much much larger budget in 2 years. Almost the same specs, but the one in the startup had better scalability and fewer serious bugs... So, spend 10-50x less and get higher quality? Worst is I now consider case b) quite lean and efficient compared to what I see tech consultancies doing towards public sector, banks, etc... -- My point being: There definitely IS a room for "rockstars" (don't like that term, but interpret this as developers competent enough to carry a lot of weight on their own and work in a smaller company) to deliver a lot of value. The problem with the model is the lack of predictability (what if the few developers you trust don't deliver), the bus factor if one of the few devs quits, etc In a sense inefficiency is a goal, because otherwise you loose redundancy. It costs a lot to hire 100 to produce the output of 10, but much lower risk.

dagss 3y ago
Perhaps some day someone will invent a way to get 20 to produce the output of 10 + redundancy... One theory is: If you have just a little too many developers (redundancy), they become bored and find ways to introduce auxiliary complexities to keep things interesting, thus things explode to 100 developers being needed...
- lanstin 3y ago
  Nothing more dangerous than a bored committer.
- cudgy 3y ago
  Have 2 teams of 10 develop the same thing and pick the best one?
  - nathants 3y ago
    teams of 2 or 1, self selecting. sometimes double up and compete on the same project with multiple implementations.
  - dizhn 3y ago
    The result would still not be guaranteed and one of the teams would have terrible morale at the end. (The other one too probably since there's a 50 percent change they are working for nothing)
com2kid 3y ago
> In my career I have seen almost identical systems being built by a) 6 developers in a startup in 1 year b) 100+ developers in a big company with a much much larger budget in 2 years. The Microsoft Band golfing on device UI was built by 1 developer in 2 or 3 months. The entire notification experience was 2 or 3 developers on and off again for the product's lifecycle. The onscreen keyboard was a couple ML engineers and a software engineer for a few months. The runtime it ran on was ~8 engineers, including all drivers, board bring ups, custom file system, everything. Small teams can do amazing things, but they rely on good leadership and on every member on the team being able to pull their own weight. We had 1 person design+code the entire file system, and as you mention, that put the bus factor at 1.
suzzer99 3y ago
We had a huge project with about 20 devs that went on for a year and a half. We brought in a bunch of consultants. The leads basically spent all day herding cats, and all night coding. We all agreed we probably could have done it in half the time with just the 5 leads.
- intelVISA 3y ago
  The hardest thing, as noted by others, is managing the auxillary complexity -- which is often introduced by excess, sometimes underskilled, developers. The 'good' (whatever that means) devs will waste more of their time hacking around the above... so more devs are added to compensate... repeat a few times: Fred's prophecy becomes manifest.
- rqtwteye 3y ago
  I struggle with that all the time. We have a lot of offshore people and I am pretty sure that 3 experienced people could take on a project that requires 50 offshore people and get it done in less time at higher quality.
  - Clubber 3y ago
    I struggled with this a lot too. I came to the conclusion that an offshore developer who as good as a good onshore developer costs about the same, just due to supply and demand, so it's a wash. If a company can't find or retain talent, hiring a not great developer offshore is cheaper than hiring a not great developer onshore. It's an "I give up" strategy; you can build the same mediocre, buggy crap cheaper offshore. Plus, off shore sales people are very good and promise the world. Many traditional executives are gullible when it comes to technology, but they're pretty good at turd polishing, so that's also part of it too. I also think OpEx vs CapEx accounting has a lot to do with it as well.
  - treeman79 3y ago
    20 years in industry. Typical Offshore people have almost always been a waste of time and just slowed down getting anything useful done. Now, I’ve also hired internationally from all over world and that has usually been fine.
intelVISA 3y ago
It's not even a matter of competency: the consultancies are there to oversell - you could have 100 great SWEs on the bank project but it's doomed all the same if the internal only SPA blog has its own nest of microservices.
Clubber 3y ago
>b) 100+ developers in a big company with a much much larger budget in 2 years. Mythical man month in play. In my experience, teams working on a single project peak at around 3-4 people, depending on how well you can silo the responsibilities. You can have 200 developers on a massive project, but the planners need to be able to silo the pieces off properly and define interfaces very well early on, which requires a massive planning phase. That usually doesn't happen the way people want it to either. https://en.wikipedia.org/wiki/The_Mythical_Man-Month https://en.wikipedia.org/wiki/The_Mythical_Man-Month Currently on my team, we have one guy responsible for the schema, back end webapis and automation. Another guy does exclusively UI, those are the two main people. We have another guy responsible for auth and misc stuff and the third guy is a full stack that came in after major development was complete who can add features pretty quickly. We have a completely separate team that handles billing operations/applications of 2 people. Our team members communicate directly with business for requirements and understanding their needs, so nothing gets convoluted passing information down through middle channels. It's not the only way to do it, but it works pretty well for us. We write all the programming required for operations of a pretty complex medical company. This was a complete Greenfield project and we have about 10 major and minor applications so far. We also have to adapt to incoming partner companies who have their own special needs and changing regulations, so the system and team is very flexible. We're about 4 years in and we had a working system up and running from "File -> New" after about 6 months. All this during COVID. Another problem with big companies that I've seen is that everything is done by committee and about 10 people need to sign off on any little thing. It turns into an administrative nightmare.
marcosdumay 3y ago
In my experience you can always count on a team to do in just an year what a single developer takes an entire week to finish. What absolutely does not mean that teams are useless. But that choosing the correct size and composition for them is one of the most important decisions for a project (right there with "are we solving the correct problem?"). And "more is better" is a completely wrong way to decide on it. Also, this doesn't make that one developer a "rockstar" or whatever else you call it.
- smaudet 3y ago
  The best teams do the most because they have the most trust. The worst teams are usually spending time paying down technical debt, or busy generating it to meet a deadline. Same goes for "rockstars", only its easier not to "lose your groove" if there are fewer people pinging you. You still run the real risk of two "rockstars" playing out of sync, and causing a mighty mess down the line.
scruple 3y ago
This sounds like Parkinson's Law applied to software engineering organizations. I also wonder if the larger organizations actual goals have anything at all to do with efficiency in software engineering / practices. I've been inside of some very large teams (400+) and the stated goals are never the real goals, they just happen to be aligned to some degree and so it sort of works.
varjag 3y ago
What happens though that the team of 100 still has the bus factor of 10: those ten people who are doing disproportional amount of work.
varispeed 3y ago
> So, spend 10-50x less and get higher quality? This is why I say "rockstar" is a synonym for mug. Why won't they pay those 6 developer 10-50x more? I've seen it many times. Young developers working their bottoms off, creating a product that makes millions only to earn average developer salary and then being laid off when company gets new investment round. At the same time, through progressive taxation, taxman takes (depending on the country) majority of earnings, so you won't be able to amass capital to start your own business. This is the way how the rich captured the means of production (developers) in wage slavery. You won't make it, unless gatekeepers let you.
- foooobaba 3y ago
  You will make it. Screw the gate keepers and build something for you and your own people. Sounds hard because it is, but that’s life, either way it’s challenging, so keep your head up and move forward.
Karrot_Kream 3y ago
> In a sense inefficiency is a goal, because otherwise you loose redundancy. It costs a lot to hire 100 to produce the output of 10, but much lower risk. The problem is the velocity hit you take by doing this is its own risk that's not tracked in the same way predictability and bus factor are. I'll bet one of the core reasons OpenAI was able to release a ChatGPT style product so much faster than Google, despite Google coming up with the fundamental Transformer breakthroughs, is this difference in velocity. And when a startup begins to erode a calcified, highly redundant larger company, then the larger company has the risk of becoming irrelevant along with all of its internal redundancy.
- dilyevsky 3y ago
  > The problem is the velocity hit you take by doing this is its own risk that's not tracked in the same way predictability and bus factor are. Yep, this is known as McNamara Fallacy - https://en.m.wikipedia.org/wiki/McNamara_fallacy https://en.m.wikipedia.org/wiki/McNamara_fallacy
  - Karrot_Kream 3y ago
    I think this is more specific than just the McNamara Fallacy (thanks for the link, I knew of the fallacy but didn't know it's name.) Big tech businesses usually optimize for risk reduction in the core business. The specific untracked metric here is that of competition. Big tech seems to go around it by trying to acquire promising competitors, but with a higher anti-trust appetite in the current administration, that's becoming less effective. And even with huge acquisition offers, it just takes one breakthrough competitor to bring a calcified risk-obsessed big tech company to its knees.
- drewcoo 3y ago
  > The problem is the velocity hit you take by doing this is its own risk that's not tracked in the same way predictability and bus factor are. I think there's a better way to think about risk here. There's lower risk with the predictable team. Those are so common, especially in established business, that we can even treat this as the default state. If you so wish, you can take on more risk and seriously slim down and get work done faster. And it will almost certainly be faster on a large enough time scale, but because it's less predictable, you're now playing schedule chicken. The kind of risk that you bring up, risk of being less risky and going slower . . . is really just opportunity cost. And it's ok to take that on as a tradeoff for something else, too, if you do it with eyes wide open. Risk is not a thing to be avoided. It is a thing to harness to gain an edge on competition. After all, without risk there is no profit.
lisasays 3y ago
Or this isn't about "rockstars" at all but a straightforward application of the "too many cooks" principle (and its refinements via The Mythical Man Month et alia). That is, the first project wasn't 15x as productive so much because the developers were so (intrinsically) -- or even when they were objectively all above average. But because beyond a certain optimal team size, per-developer productivity drops substantially -- even plummets precipitously (due to the factors articulated in TMM: communication, politics, etc). Plus there's a huge survivorship / selective bias example involved here (we're not look at pairings of other projects where the smaller team failed, even with better developers, because it was just too small, etc). I also suspect that if one were on the "inside" of both projects (which of course no one was) one would see a host of other factors involved (from knowledge of the requirements to market conditions, etc) not visible to an outsider. We can definitely see how anecdotes like these help promulgate the 10x myth at least. People hear about the fates of the respective teams and think "Of course, it's because those developers were individually that much more productive. I better start making my interview process 10x more difficult now ..." (BTW, no need to drill down on what I just said about the "10x myth", please. It's not that awesome developers don't exist or aren't important. It's just that for a whole lot of reasons, it is both incredibly overhyped, and objectively wrong in its fundamentals -- especially when we look at the original studies whence it supposedly derived).
wek2op3 3y ago
Let me guess... The 100+ team used Kubernetes, right? Because Kubernetes is by far the biggest productivity killer ever.
iancmceachern 3y ago
Me too. I've seen teams of 2 or 3 up to 10 do things in half the time of a team of 100. It's the real power of life startups. If you get the right people with the right experience in the same room and align their motivations you get amazing things like the Apple II. If you put hundreds of not the right people, but close, in the same room you get a job factory.
tr_user 3y ago
Are you measuring only functional requirements? Plenty of people can code it up, but who can maintain it afterwards?
- dagss 3y ago
  Actually for both systems I was among the core maintainers for 3 years after the initial build. System a) was more maintainable.
deleted 3y ago
[deleted]
danjac 3y ago
Consultancies could hire all the "rockstar" developers they want, but their culture is around generating billable hours, not building great software. A developer on the Scrum/Jira treadmill, working on one ticket at a time, will not have the leeway to step back and look at solutions holistically and come up with a better approach.
devjab 3y ago
> In my career I have seen almost identical systems being built by a) 6 developers in a startup in 1 year b) 100+ developers in a big company with a much much larger budget in 2 years. I spent a decade in the public sector of Denmark and I've since got into helping non-SWE startups transition into enterprise organisations as far as digitalisation goes. So I've seen quite a lot of this. I've also had the pleasure to be on basically every sides of the table, from developer, architect, manager to buyer and consultant. I think it's always down to the business processes and the management. Sure "rockstars" are a thing in SWE, I'm frankly one of them. However I don't think the difference between a 10x and a 1x/rockstar/whatever buzzword developer is necessarily too much about our technical abilities or talent. In my opinion it's often mainly defined by your organisational prowess. If you're the type of developer who can get things done, make an impact and create business value, you're going to be given a lot of freedom and you're eventually going to settle into "rockstar" roles. This is soooo much easier in smaller organisations where the restrictions you face on how you can work are often small-non-existant. Maybe you're even going to build some of the restrictions yourself, by defining how your organisations wants to lint, which techs you want to use and so on. As things grow, more and more people are going to enter the work processes. Some of them are going to be hired to work on the work processes themselves, and eventually you're going to end up with this quagmire of bullshit red-tape. It's there with good intentions, of course it is, nobody goes to work meaning to make the world a worse place, but all the control and the business intelligence is usually an illusion of sorts. At least in my experience. Now, if you have good managers they'll build teams and manage the processes in a way that doesn't get too much in the way, but over the years, you're going to have a lot of bad managers involved in the processes. You're likely also going to work for an organisation where upper management doesn't care about digitalisation, at least not really, despite the fact that 90% of their work force is on a computer 8 hours a day. So eventually you're going to end up with an environment where it's hard to get things done. What is worse, often the best developers. The people who are able to deliver a lot of visible business value, are going to be plucked by management in attempts to try and use them to make other developers produce more value. Meaning that many organisations tie their best development resources up in advisory roles and waste them away in endless meetings. So it's not that those 6 developers are necessarily better than the 100. It's that sometimes, a team of 6 developers get to do more actual work than 100 developers combined do in a year. Obviously that's only part of it. There is a whole range of other things that impact why big organisations suck. Because the quality of the 6 man team isn't necessarily on par with the 100+ developer team if you look at the application at scale over a decade. At least not in my experience. This might not matter when you're small, but it will matter when you're IBM because a few bad years will wreck your reputation for decades. > So, spend 10-50x less and get higher quality? You're never going to convince businesses that it's less risky to buy from a small company. It's not like CEOs are stupid. They might not care about IT too much, and they certainly hate it when IBM fails to deliver on time and that it'll cost extra to get the thing to actually work. But they do know that it will eventually work when they go to the 100+ developer company. They don't necessarily know this when they go to the 6 man team. In fact, one of the primary reasons you hear so much more about the 100+ developer teams is because often the small startup will simply go bankrupt when the contract fails. I'm currently working on fixing one such thing, I can't tell you much more than that, but lets just say, that the 100+ developer company would've been the wiser option. Now, sometimes you do get the better quality, the faster deliverance and the better product form the 6 developer startup, so it's not like you're wrong either. It's just that most decision makers hates risk. ps. Sorry IBM.
regularfry 3y ago
It's never the individuals. It's always the team culture. I've seen 5-person teams of raw bootcamp grads run rings around conventional dev teams with a broader experience base, repeatedly. Part of it is that there are no bullshit status games going on when everyone knows everyone else is just as in the dark as they are, but (in my view) an equally large factor is that the grad teams know they're going to have to learn whatever tools the problem needs. A more tenured team is far more likely to waste time on trying to build java in python, or fighting over not being able to use their favourite libraries. But then there's also the wider situational context: an environment that has 100+ developers in a big company will have governance tarpits and coordination overheads they almost certainly haven't measured the cost of; 10x wouldn't surprise me at all just from those two factors. Grad teams in the same org are more likely to have standalone, lower-risk projects to work on so they're going to be more insulated from those effects.
spacemadness 3y ago
As I’ve moved into bigger companies over my career, I’ve become more held back by the processes in place and I am certainly way less effective than I could be. Code reviews take longer, there are political games to play and far too many meetings, managers want you writing lots of excess documentation for documentations sake instead of coding, spending lots of time on peer review discussions of those useless documents where the reviewers nitpick just to leave comments for their performance reviews, needing to jump through multiple layers of sign-offs from stakeholders for simple changes, etc. I mean, yes, small teams without that cruft will be more effective for the most part. I will probably move back to working for smaller companies soon and it will be a relief.

by dagss 3y ago

dagss 3y ago

Perhaps some day someone will invent a way to get 20 to produce the output of 10 + redundancy... One theory is: If you have just a little too many developers (redundancy), they become bored and find ways to introduce auxiliary complexities to keep things interesting, thus things explode to 100 developers being needed...

lanstin 3y ago
Nothing more dangerous than a bored committer.
cudgy 3y ago
Have 2 teams of 10 develop the same thing and pick the best one?
- nathants 3y ago
  teams of 2 or 1, self selecting. sometimes double up and compete on the same project with multiple implementations.
- dizhn 3y ago
  The result would still not be guaranteed and one of the teams would have terrible morale at the end. (The other one too probably since there's a 50 percent change they are working for nothing)

com2kid 3y ago

> In my career I have seen almost identical systems being built by a) 6 developers in a startup in 1 year b) 100+ developers in a big company with a much much larger budget in 2 years. The Microsoft Band golfing on device UI was built by 1 developer in 2 or 3 months. The entire notification experience was 2 or 3 developers on and off again for the product's lifecycle. The onscreen keyboard was a couple ML engineers and a software engineer for a few months. The runtime it ran on was ~8 engineers, including all drivers, board bring ups, custom file system, everything. Small teams can do amazing things, but they rely on good leadership and on every member on the team being able to pull their own weight. We had 1 person design+code the entire file system, and as you mention, that put the bus factor at 1.

suzzer99 3y ago

We had a huge project with about 20 devs that went on for a year and a half. We brought in a bunch of consultants. The leads basically spent all day herding cats, and all night coding. We all agreed we probably could have done it in half the time with just the 5 leads.

intelVISA 3y ago
The hardest thing, as noted by others, is managing the auxillary complexity -- which is often introduced by excess, sometimes underskilled, developers. The 'good' (whatever that means) devs will waste more of their time hacking around the above... so more devs are added to compensate... repeat a few times: Fred's prophecy becomes manifest.
rqtwteye 3y ago
I struggle with that all the time. We have a lot of offshore people and I am pretty sure that 3 experienced people could take on a project that requires 50 offshore people and get it done in less time at higher quality.
- Clubber 3y ago
  I struggled with this a lot too. I came to the conclusion that an offshore developer who as good as a good onshore developer costs about the same, just due to supply and demand, so it's a wash. If a company can't find or retain talent, hiring a not great developer offshore is cheaper than hiring a not great developer onshore. It's an "I give up" strategy; you can build the same mediocre, buggy crap cheaper offshore. Plus, off shore sales people are very good and promise the world. Many traditional executives are gullible when it comes to technology, but they're pretty good at turd polishing, so that's also part of it too. I also think OpEx vs CapEx accounting has a lot to do with it as well.
- treeman79 3y ago
  20 years in industry. Typical Offshore people have almost always been a waste of time and just slowed down getting anything useful done. Now, I’ve also hired internationally from all over world and that has usually been fine.

intelVISA 3y ago

It's not even a matter of competency: the consultancies are there to oversell - you could have 100 great SWEs on the bank project but it's doomed all the same if the internal only SPA blog has its own nest of microservices.

Clubber 3y ago

>b) 100+ developers in a big company with a much much larger budget in 2 years. Mythical man month in play. In my experience, teams working on a single project peak at around 3-4 people, depending on how well you can silo the responsibilities. You can have 200 developers on a massive project, but the planners need to be able to silo the pieces off properly and define interfaces very well early on, which requires a massive planning phase. That usually doesn't happen the way people want it to either. https://en.wikipedia.org/wiki/The_Mythical_Man-Month https://en.wikipedia.org/wiki/The_Mythical_Man-Month Currently on my team, we have one guy responsible for the schema, back end webapis and automation. Another guy does exclusively UI, those are the two main people. We have another guy responsible for auth and misc stuff and the third guy is a full stack that came in after major development was complete who can add features pretty quickly. We have a completely separate team that handles billing operations/applications of 2 people. Our team members communicate directly with business for requirements and understanding their needs, so nothing gets convoluted passing information down through middle channels. It's not the only way to do it, but it works pretty well for us. We write all the programming required for operations of a pretty complex medical company. This was a complete Greenfield project and we have about 10 major and minor applications so far. We also have to adapt to incoming partner companies who have their own special needs and changing regulations, so the system and team is very flexible. We're about 4 years in and we had a working system up and running from "File -> New" after about 6 months. All this during COVID. Another problem with big companies that I've seen is that everything is done by committee and about 10 people need to sign off on any little thing. It turns into an administrative nightmare.

marcosdumay 3y ago

In my experience you can always count on a team to do in just an year what a single developer takes an entire week to finish. What absolutely does not mean that teams are useless. But that choosing the correct size and composition for them is one of the most important decisions for a project (right there with "are we solving the correct problem?"). And "more is better" is a completely wrong way to decide on it. Also, this doesn't make that one developer a "rockstar" or whatever else you call it.

smaudet 3y ago
The best teams do the most because they have the most trust. The worst teams are usually spending time paying down technical debt, or busy generating it to meet a deadline. Same goes for "rockstars", only its easier not to "lose your groove" if there are fewer people pinging you. You still run the real risk of two "rockstars" playing out of sync, and causing a mighty mess down the line.

scruple 3y ago

This sounds like Parkinson's Law applied to software engineering organizations. I also wonder if the larger organizations actual goals have anything at all to do with efficiency in software engineering / practices. I've been inside of some very large teams (400+) and the stated goals are never the real goals, they just happen to be aligned to some degree and so it sort of works.

varjag 3y ago

What happens though that the team of 100 still has the bus factor of 10: those ten people who are doing disproportional amount of work.

varispeed 3y ago

> So, spend 10-50x less and get higher quality? This is why I say "rockstar" is a synonym for mug. Why won't they pay those 6 developer 10-50x more? I've seen it many times. Young developers working their bottoms off, creating a product that makes millions only to earn average developer salary and then being laid off when company gets new investment round. At the same time, through progressive taxation, taxman takes (depending on the country) majority of earnings, so you won't be able to amass capital to start your own business. This is the way how the rich captured the means of production (developers) in wage slavery. You won't make it, unless gatekeepers let you.

foooobaba 3y ago
You will make it. Screw the gate keepers and build something for you and your own people. Sounds hard because it is, but that’s life, either way it’s challenging, so keep your head up and move forward.

Karrot_Kream 3y ago

> In a sense inefficiency is a goal, because otherwise you loose redundancy. It costs a lot to hire 100 to produce the output of 10, but much lower risk. The problem is the velocity hit you take by doing this is its own risk that's not tracked in the same way predictability and bus factor are. I'll bet one of the core reasons OpenAI was able to release a ChatGPT style product so much faster than Google, despite Google coming up with the fundamental Transformer breakthroughs, is this difference in velocity. And when a startup begins to erode a calcified, highly redundant larger company, then the larger company has the risk of becoming irrelevant along with all of its internal redundancy.

dilyevsky 3y ago
> The problem is the velocity hit you take by doing this is its own risk that's not tracked in the same way predictability and bus factor are. Yep, this is known as McNamara Fallacy - https://en.m.wikipedia.org/wiki/McNamara_fallacy https://en.m.wikipedia.org/wiki/McNamara_fallacy
- Karrot_Kream 3y ago
  I think this is more specific than just the McNamara Fallacy (thanks for the link, I knew of the fallacy but didn't know it's name.) Big tech businesses usually optimize for risk reduction in the core business. The specific untracked metric here is that of competition. Big tech seems to go around it by trying to acquire promising competitors, but with a higher anti-trust appetite in the current administration, that's becoming less effective. And even with huge acquisition offers, it just takes one breakthrough competitor to bring a calcified risk-obsessed big tech company to its knees.
drewcoo 3y ago
> The problem is the velocity hit you take by doing this is its own risk that's not tracked in the same way predictability and bus factor are. I think there's a better way to think about risk here. There's lower risk with the predictable team. Those are so common, especially in established business, that we can even treat this as the default state. If you so wish, you can take on more risk and seriously slim down and get work done faster. And it will almost certainly be faster on a large enough time scale, but because it's less predictable, you're now playing schedule chicken. The kind of risk that you bring up, risk of being less risky and going slower . . . is really just opportunity cost. And it's ok to take that on as a tradeoff for something else, too, if you do it with eyes wide open. Risk is not a thing to be avoided. It is a thing to harness to gain an edge on competition. After all, without risk there is no profit.

lisasays 3y ago

Or this isn't about "rockstars" at all but a straightforward application of the "too many cooks" principle (and its refinements via The Mythical Man Month et alia). That is, the first project wasn't 15x as productive so much because the developers were so (intrinsically) -- or even when they were objectively all above average. But because beyond a certain optimal team size, per-developer productivity drops substantially -- even plummets precipitously (due to the factors articulated in TMM: communication, politics, etc). Plus there's a huge survivorship / selective bias example involved here (we're not look at pairings of other projects where the smaller team failed, even with better developers, because it was just too small, etc). I also suspect that if one were on the "inside" of both projects (which of course no one was) one would see a host of other factors involved (from knowledge of the requirements to market conditions, etc) not visible to an outsider. We can definitely see how anecdotes like these help promulgate the 10x myth at least. People hear about the fates of the respective teams and think "Of course, it's because those developers were individually that much more productive. I better start making my interview process 10x more difficult now ..." (BTW, no need to drill down on what I just said about the "10x myth", please. It's not that awesome developers don't exist or aren't important. It's just that for a whole lot of reasons, it is both incredibly overhyped, and objectively wrong in its fundamentals -- especially when we look at the original studies whence it supposedly derived).

wek2op3 3y ago

Let me guess... The 100+ team used Kubernetes, right? Because Kubernetes is by far the biggest productivity killer ever.

iancmceachern 3y ago

Me too. I've seen teams of 2 or 3 up to 10 do things in half the time of a team of 100. It's the real power of life startups. If you get the right people with the right experience in the same room and align their motivations you get amazing things like the Apple II. If you put hundreds of not the right people, but close, in the same room you get a job factory.

tr_user 3y ago

Are you measuring only functional requirements? Plenty of people can code it up, but who can maintain it afterwards?

dagss 3y ago
Actually for both systems I was among the core maintainers for 3 years after the initial build. System a) was more maintainable.

deleted 3y ago

[deleted]

danjac 3y ago

Consultancies could hire all the "rockstar" developers they want, but their culture is around generating billable hours, not building great software. A developer on the Scrum/Jira treadmill, working on one ticket at a time, will not have the leeway to step back and look at solutions holistically and come up with a better approach.

devjab 3y ago

> In my career I have seen almost identical systems being built by a) 6 developers in a startup in 1 year b) 100+ developers in a big company with a much much larger budget in 2 years. I spent a decade in the public sector of Denmark and I've since got into helping non-SWE startups transition into enterprise organisations as far as digitalisation goes. So I've seen quite a lot of this. I've also had the pleasure to be on basically every sides of the table, from developer, architect, manager to buyer and consultant. I think it's always down to the business processes and the management. Sure "rockstars" are a thing in SWE, I'm frankly one of them. However I don't think the difference between a 10x and a 1x/rockstar/whatever buzzword developer is necessarily too much about our technical abilities or talent. In my opinion it's often mainly defined by your organisational prowess. If you're the type of developer who can get things done, make an impact and create business value, you're going to be given a lot of freedom and you're eventually going to settle into "rockstar" roles. This is soooo much easier in smaller organisations where the restrictions you face on how you can work are often small-non-existant. Maybe you're even going to build some of the restrictions yourself, by defining how your organisations wants to lint, which techs you want to use and so on. As things grow, more and more people are going to enter the work processes. Some of them are going to be hired to work on the work processes themselves, and eventually you're going to end up with this quagmire of bullshit red-tape. It's there with good intentions, of course it is, nobody goes to work meaning to make the world a worse place, but all the control and the business intelligence is usually an illusion of sorts. At least in my experience. Now, if you have good managers they'll build teams and manage the processes in a way that doesn't get too much in the way, but over the years, you're going to have a lot of bad managers involved in the processes. You're likely also going to work for an organisation where upper management doesn't care about digitalisation, at least not really, despite the fact that 90% of their work force is on a computer 8 hours a day. So eventually you're going to end up with an environment where it's hard to get things done. What is worse, often the best developers. The people who are able to deliver a lot of visible business value, are going to be plucked by management in attempts to try and use them to make other developers produce more value. Meaning that many organisations tie their best development resources up in advisory roles and waste them away in endless meetings. So it's not that those 6 developers are necessarily better than the 100. It's that sometimes, a team of 6 developers get to do more actual work than 100 developers combined do in a year. Obviously that's only part of it. There is a whole range of other things that impact why big organisations suck. Because the quality of the 6 man team isn't necessarily on par with the 100+ developer team if you look at the application at scale over a decade. At least not in my experience. This might not matter when you're small, but it will matter when you're IBM because a few bad years will wreck your reputation for decades. > So, spend 10-50x less and get higher quality? You're never going to convince businesses that it's less risky to buy from a small company. It's not like CEOs are stupid. They might not care about IT too much, and they certainly hate it when IBM fails to deliver on time and that it'll cost extra to get the thing to actually work. But they do know that it will eventually work when they go to the 100+ developer company. They don't necessarily know this when they go to the 6 man team. In fact, one of the primary reasons you hear so much more about the 100+ developer teams is because often the small startup will simply go bankrupt when the contract fails. I'm currently working on fixing one such thing, I can't tell you much more than that, but lets just say, that the 100+ developer company would've been the wiser option. Now, sometimes you do get the better quality, the faster deliverance and the better product form the 6 developer startup, so it's not like you're wrong either. It's just that most decision makers hates risk. ps. Sorry IBM.

regularfry 3y ago

It's never the individuals. It's always the team culture. I've seen 5-person teams of raw bootcamp grads run rings around conventional dev teams with a broader experience base, repeatedly. Part of it is that there are no bullshit status games going on when everyone knows everyone else is just as in the dark as they are, but (in my view) an equally large factor is that the grad teams know they're going to have to learn whatever tools the problem needs. A more tenured team is far more likely to waste time on trying to build java in python, or fighting over not being able to use their favourite libraries. But then there's also the wider situational context: an environment that has 100+ developers in a big company will have governance tarpits and coordination overheads they almost certainly haven't measured the cost of; 10x wouldn't surprise me at all just from those two factors. Grad teams in the same org are more likely to have standalone, lower-risk projects to work on so they're going to be more insulated from those effects.

spacemadness 3y ago

As I’ve moved into bigger companies over my career, I’ve become more held back by the processes in place and I am certainly way less effective than I could be. Code reviews take longer, there are political games to play and far too many meetings, managers want you writing lots of excess documentation for documentations sake instead of coding, spending lots of time on peer review discussions of those useless documents where the reviewers nitpick just to leave comments for their performance reviews, needing to jump through multiple layers of sign-offs from stakeholders for simple changes, etc. I mean, yes, small teams without that cruft will be more effective for the most part. I will probably move back to working for smaller companies soon and it will be a relief.