3 ms·

> because their functionally is so small it's always going to be obvious where the flaws That, sadly, won't scale. > we're actually better off doing the wron

> because their functionally is so small it's always going to be obvious where the flaws That, sadly, won't scale. > we're actually better off doing the wrong thing. You aren't actually doing the wrong thing. At 3 employees the maximum complexity your team can handle is pretty low. It's also trivial to pass on institutional knowledge since well... the whole team can share one extra large pizza.

m1sta_ 5y ago
Heavy development processes don't scale when it comes to volume of projects.
moksly 5y ago
> That, sadly, won't scale. We never really need it to. That’s one of the few benefits of writing software in the public sector. We don’t need to expect an explosive growth in users. We’ve seen 10.000 additional citizens move to our area over 5 years, so there is growth, but it’s far from everyone of them who would interact with a single solution that we wouldn’t buy from the private sector through public procurement.
- 908B64B197 5y ago
  I meant feature-wise. My message was unclear. There's a point where a team of three maintaining tribal knowledge is not enough to deliver certain project above a threshold of complexity. But you mention procurement, so I assume your team does a buy vs build pretty much systematically.
dmos62 5y ago
>> because their functionally is so small it's always going to be obvious where the flaws > That, sadly, won't scale. You're contradicting the UNIX philosophy: make programs so small that they're inherently simple (or so simple that they're necesserily small). I think that's what the other commentor meant and that does scale.
- tempodox 5y ago
  It depends. Systems can display so-called emergent properties, i.e. the system's behavior is “more than just the sum of its parts”. Components that are simple in isolation can still form complex interactions. When that happens, you'll need to use the bigger guns.

m1sta_ 5y ago

Heavy development processes don't scale when it comes to volume of projects.

moksly 5y ago

> That, sadly, won't scale. We never really need it to. That’s one of the few benefits of writing software in the public sector. We don’t need to expect an explosive growth in users. We’ve seen 10.000 additional citizens move to our area over 5 years, so there is growth, but it’s far from everyone of them who would interact with a single solution that we wouldn’t buy from the private sector through public procurement.

908B64B197 5y ago
I meant feature-wise. My message was unclear. There's a point where a team of three maintaining tribal knowledge is not enough to deliver certain project above a threshold of complexity. But you mention procurement, so I assume your team does a buy vs build pretty much systematically.

dmos62 5y ago

>> because their functionally is so small it's always going to be obvious where the flaws > That, sadly, won't scale. You're contradicting the UNIX philosophy: make programs so small that they're inherently simple (or so simple that they're necesserily small). I think that's what the other commentor meant and that does scale.

tempodox 5y ago
It depends. Systems can display so-called emergent properties, i.e. the system's behavior is “more than just the sum of its parts”. Components that are simple in isolation can still form complex interactions. When that happens, you'll need to use the bigger guns.