3 ms·

Oh well, all of my 20 years of software engineering are a tale of fighting in the dark before anything works and heavy precaution after, without having any remo

Oh well, all of my 20 years of software engineering are a tale of fighting in the dark before anything works and heavy precaution after, without having any remote evidence of nearly everything readily available.

moksly 5y ago
That’s the most interesting find of the book isn’t it? We’ve taken a sort of controversial approach to software development in the public sector of Denmark because we don’t have enough resources. Small projects are build to run their own little lives with as little post-deployment development as possible. Because of this they aren’t build with best practices, whatever theories are the right way to do things in a current age, none of them are automatically tested because their functionally is so small it’s always going to be obvious where the flaws are and the only way for them to get additional development post deployment is if they turn out to be really good, and even then, we don’t expect them to live after 5-10 years. It’s way of development goes against every theory on software development you’ll find being taught at universities and academies, I know, because I’m an external CS examiner at these places, and we’ve really only chosen to do this because we have 3 developers in an organisation with 10.000 employees. Now the data shows us, that we’re actually better off doing the wrong thing.
- whatshisface 5y ago
  Small programs are by far the best approach. The only time that doesn't work is when the problem itself requires a very large program. That is when you need things like automated tests.
  - InfiniteRand 5y ago
    In theory the obvious solution would be to make everything modular small programs but then you pay the price of coordination (ie, apis between modules, dependency, maintaining uniform practices etc.) so... shrug
- 908B64B197 5y ago
  > 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

moksly 5y ago

That’s the most interesting find of the book isn’t it? We’ve taken a sort of controversial approach to software development in the public sector of Denmark because we don’t have enough resources. Small projects are build to run their own little lives with as little post-deployment development as possible. Because of this they aren’t build with best practices, whatever theories are the right way to do things in a current age, none of them are automatically tested because their functionally is so small it’s always going to be obvious where the flaws are and the only way for them to get additional development post deployment is if they turn out to be really good, and even then, we don’t expect them to live after 5-10 years. It’s way of development goes against every theory on software development you’ll find being taught at universities and academies, I know, because I’m an external CS examiner at these places, and we’ve really only chosen to do this because we have 3 developers in an organisation with 10.000 employees. Now the data shows us, that we’re actually better off doing the wrong thing.

whatshisface 5y ago
Small programs are by far the best approach. The only time that doesn't work is when the problem itself requires a very large program. That is when you need things like automated tests.
- InfiniteRand 5y ago
  In theory the obvious solution would be to make everything modular small programs but then you pay the price of coordination (ie, apis between modules, dependency, maintaining uniform practices etc.) so... shrug
908B64B197 5y ago
> 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