4 ms·

Generally products built by large teams are large products. There are extra challenges associated with coordinating large groups of people, and there are extra

by mwfunk 10y ago

Generally products built by large teams are large products. There are extra challenges associated with coordinating large groups of people, and there are extra challenges associated with developing big, complicated software products with lots of different subsystems that have to work together. Hopefully no one is using a large team to build a small product. If so, yeah, don't do that. But you're going to get into different problems building large products with small teams. Ultimately there's no silver bullet, the best you can do is maintain awareness of the tradeoffs, identify and deal with problems as they arise, and otherwise do the best you can to maximize the likelihood of success and minimize failure. Sometimes people feel like they've found a silver bullet just by identifying the problems, in which the silver bullet is "well just don't do that then". In contrast, I feel like everything that's nontrivial in life consists of choosing from a set of compromises and tradeoffs. There's a natural tendency to feel the pain of the compromises and assume that if only we weren't making those compromises, everything would be great, without taking into account the tradeoffs and compromises that alternate approaches would create.

edblarney 10y ago
There's no 'silver bullet' - but surely a 'large product' does not need to start off as a 'large product'. A 'small team' making an MVP, and then moving on incrementally from there, adding more people to do peripheral features as the project progress might seem like a good way to overcome some inherent 'monolithic' risks - as well as keep costs down at the start. It takes an open mind from management to grasp that building complex software is not like building a really big building. You just can't predict outcomes, so, you have to build a good team that can forge a path, and have some 'kill-it-don't-kill-it' guidelines, and expect that many will fail.
- cbhl 10y ago
  Then you run into "rewrite risk" -- that the company won't survive long enough for the MVP to meet the needs of the existing customers.
  - webmaven 10y ago
    Or sometimes your prototype or proof-of-concept simply gets deployed to production by executive fiat because they don't understand that it's put together with bubble gum and baling wire, and over the next 3-5 years you are never given the resources to do anything but (a) keep it running somehow, and (b) add more features that got promised to customers in order to land them and that need to be live ASAP. What's that...? No, I've never experienced that situation myself, why do you ask?
    - snerbles 10y ago
      Watching a past employer slowly drown itself in technical debt is simultaneously sad and satisfying.
      - deleted 10y ago
        [deleted]
    - aaronblohowiak 10y ago
      "protoduction"
    - candiodari 10y ago
      > What's that...? No, I've never experienced that situation myself, why do you ask? Another way to look at it is to say this provided you with a job and an entire company with a revenue basis, probably for years. I mean on the other side of the fence there are plenty of stories of software developers being allowed to "properly design", no technical debt, then after 1 year of zero result they come with a product, which doesn't even start (the tests run and succeed, though). Then the third or so feature request that comes in ... needs a rewrite.
Sigerson 10y ago
The key really is making sure a large project is not a monolithic project. Break it down, break it down, break it down. The same logic that works for implementation is also valuable on the product side. Scaling engineering is much easier if the project is designed with that scale in mind.
- mjevans 10y ago
  Also clearly define the scale that things will /run/ at. When possible also have (a snapshot of) real data to run conformance and performance tests against.
  - softawre 10y ago
    Agree 100%. So many people make lip service to SCALE at my company, but out of 20+ teams we are the only team running real scale tests against real defined limits with real (obfuscated) customer data.
woodandsteel 10y ago
I am reminded by something I read by a person who studies complex systems. He said that every complex system that works well started with a simple system that worked well, and then gradually added new features over time.
- sa46 10y ago
  Known as Gall's law. From Wikipedia: Gall's Law is a rule of thumb for systems design from Gall's book Systemantics: How Systems Really Work and How They Fail. It states: A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system. – John Gall https://en.wikipedia.org/wiki/John_Gall_(author)#Gall.27s_law https://en.wikipedia.org/wiki/John_Gall_(author)#Gall.27s_la...

by mwfunk 10y ago

edblarney 10y ago

There's no 'silver bullet' - but surely a 'large product' does not need to start off as a 'large product'. A 'small team' making an MVP, and then moving on incrementally from there, adding more people to do peripheral features as the project progress might seem like a good way to overcome some inherent 'monolithic' risks - as well as keep costs down at the start. It takes an open mind from management to grasp that building complex software is not like building a really big building. You just can't predict outcomes, so, you have to build a good team that can forge a path, and have some 'kill-it-don't-kill-it' guidelines, and expect that many will fail.

cbhl 10y ago
Then you run into "rewrite risk" -- that the company won't survive long enough for the MVP to meet the needs of the existing customers.
- webmaven 10y ago
  Or sometimes your prototype or proof-of-concept simply gets deployed to production by executive fiat because they don't understand that it's put together with bubble gum and baling wire, and over the next 3-5 years you are never given the resources to do anything but (a) keep it running somehow, and (b) add more features that got promised to customers in order to land them and that need to be live ASAP. What's that...? No, I've never experienced that situation myself, why do you ask?
  - snerbles 10y ago
    Watching a past employer slowly drown itself in technical debt is simultaneously sad and satisfying.
    - deleted 10y ago
      [deleted]
  - aaronblohowiak 10y ago
    "protoduction"
  - candiodari 10y ago
    > What's that...? No, I've never experienced that situation myself, why do you ask? Another way to look at it is to say this provided you with a job and an entire company with a revenue basis, probably for years. I mean on the other side of the fence there are plenty of stories of software developers being allowed to "properly design", no technical debt, then after 1 year of zero result they come with a product, which doesn't even start (the tests run and succeed, though). Then the third or so feature request that comes in ... needs a rewrite.

Sigerson 10y ago

The key really is making sure a large project is not a monolithic project. Break it down, break it down, break it down. The same logic that works for implementation is also valuable on the product side. Scaling engineering is much easier if the project is designed with that scale in mind.

mjevans 10y ago
Also clearly define the scale that things will /run/ at. When possible also have (a snapshot of) real data to run conformance and performance tests against.
- softawre 10y ago
  Agree 100%. So many people make lip service to SCALE at my company, but out of 20+ teams we are the only team running real scale tests against real defined limits with real (obfuscated) customer data.

woodandsteel 10y ago

I am reminded by something I read by a person who studies complex systems. He said that every complex system that works well started with a simple system that worked well, and then gradually added new features over time.

sa46 10y ago
Known as Gall's law. From Wikipedia: Gall's Law is a rule of thumb for systems design from Gall's book Systemantics: How Systems Really Work and How They Fail. It states: A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system. – John Gall https://en.wikipedia.org/wiki/John_Gall_(author)#Gall.27s_law https://en.wikipedia.org/wiki/John_Gall_(author)#Gall.27s_la...