7 ms·

This has always felt like the catch 22/anthropic principal of software development to me: 1. Early on you favor decisions that enable rapid iteration and growt

This has always felt like the catch 22/anthropic principal of software development to me: 1. Early on you favor decisions that enable rapid iteration and growth without being able to put in much deep thought around long term productivity. Most of these tend to be fine in the long run but there's probably at least 1 or 2 that will haunt the company for the rest of its days. Companies that don't take these "short cuts" will probably kill the business. 2. Companies that survive largely have their architecture dictated by #1 and are fairly constrained in how radically they can change the decisions in #1. So most of us end up working on a product which has some pretty critical architectural flaws that are very hard to repair. The only companies I've seen that do work their way out of it are the printing presses (google, linkedin, yahoo, amazon, etc) that are able to invest in very strong platforms and move their applications onto them, and even then it's a long drawn out process.

HeyLaughingBoy 4y ago
There's a way out of this, but it requires discipline and besides, most companies don't want to do it. Prototype. Deliberately build "one to throw away." Iterate fast and figure out what you need. When you've learned the important lessons about architecture, structure and collaborations, make a note of those lessons in a design document and then build the "real" product with proper engineering, but with a lot less risk. I worked for an organization that did this and it results in good quality software, but you need buy-in at all levels of management or you run into "why did your team just waste 6 months on throw-away work?" questions.
- anthonypasq 4y ago
  arent you just describing the business from #1 that does this method and fails because they have no money and no customers?
  - n42 4y ago
    It’s important to time this well and start doing it as soon as you have your feet on the ground, and the hard part is to hit the ground running. Too early and you crash, too late and you grind to a halt edit: missed “6 months”, I live in another world — a week to prototype and throw it out. spending 6 months to prototype anything and you’re biting too big
    - HeyLaughingBoy 4y ago
      > spending 6 months to prototype anything I come from the world of medical devices. Nothing happens in a week ;-)
      - deleted 4y ago
        [deleted]
      - ska 4y ago
        Most of the medical device industry could move a lot faster than they do. There are an interesting collection of reasons why they don't, but it's not inherent.
  - ska 4y ago
    It really doesn't have to be. If you come from a hardware background, you get used to the idea of quickly prototyping with techniques (e.g. breadboard electronics) and materials (e.g. 3D prints in plastic instead of CNC milled parts) because it is vastly faster and cheaper. See also scale models etc. The problem with software is it nearly infinitely malleable, so the tempation is always there to think that you will be faster if you ship-of-Theseus your current prototype into production code. It works sometimes, but often it's faster to actually prototype, then do it "right" from what you've learned. It's a skill though, to know what to concentrate on and what to skip/fake/ignore.
deleted 4y ago
[deleted]
dilyevsky 4y ago
Disagree. Everyone will make at least one major blunder in 1. and probably more. I don't care how much thought you think you put into it, you will make mistakes if you move proactively and not just sit there and wait until you are forced to act or the problem goes away. Companies live or die by how nimble and effective they are at fixing the messes made in 1. while moving forward.
lmm 4y ago
Why should it be otherwise? Any software development interesting enough to be worth working on will be at least partly a research project, and research always involves wrong directions and dead ends. If you didn't learn something that would radically change your understanding of how you should architecture your system, you launched too late.
8n4vidtmkvmk 4y ago
yep. and then they put tight timelines (meaning like 1.5 years) to finish those massive migrations and so we take more shortcuts to finish them and i guess technically we end up on the new platform but the implementation is about as bad as the original
bl4ckm0r3 4y ago
the problem is that most people/orgs don't think this way, they still think their solution is scalable and easy to start (like RoR) and no one optimizes for deletion so eventually you are stuck with all those initial choices until you spend a lot of money to overcome them (literally in every company i have worked at, authentication, MVC - with more than 3k loc controllers - and monoliths were "impossible" - as in not economically sustainable - to refactor. I think there's a misunderstanding of the word "easy", django, springboot, laravel, RoR etc are easy to start with, as most architectural choices come out of the box, but then you can never leave that box.

HeyLaughingBoy 4y ago

There's a way out of this, but it requires discipline and besides, most companies don't want to do it. Prototype. Deliberately build "one to throw away." Iterate fast and figure out what you need. When you've learned the important lessons about architecture, structure and collaborations, make a note of those lessons in a design document and then build the "real" product with proper engineering, but with a lot less risk. I worked for an organization that did this and it results in good quality software, but you need buy-in at all levels of management or you run into "why did your team just waste 6 months on throw-away work?" questions.

anthonypasq 4y ago
arent you just describing the business from #1 that does this method and fails because they have no money and no customers?
- n42 4y ago
  It’s important to time this well and start doing it as soon as you have your feet on the ground, and the hard part is to hit the ground running. Too early and you crash, too late and you grind to a halt edit: missed “6 months”, I live in another world — a week to prototype and throw it out. spending 6 months to prototype anything and you’re biting too big
  - HeyLaughingBoy 4y ago
    > spending 6 months to prototype anything I come from the world of medical devices. Nothing happens in a week ;-)
    - deleted 4y ago
      [deleted]
    - ska 4y ago
      Most of the medical device industry could move a lot faster than they do. There are an interesting collection of reasons why they don't, but it's not inherent.
- ska 4y ago
  It really doesn't have to be. If you come from a hardware background, you get used to the idea of quickly prototyping with techniques (e.g. breadboard electronics) and materials (e.g. 3D prints in plastic instead of CNC milled parts) because it is vastly faster and cheaper. See also scale models etc. The problem with software is it nearly infinitely malleable, so the tempation is always there to think that you will be faster if you ship-of-Theseus your current prototype into production code. It works sometimes, but often it's faster to actually prototype, then do it "right" from what you've learned. It's a skill though, to know what to concentrate on and what to skip/fake/ignore.

deleted 4y ago

[deleted]

dilyevsky 4y ago

Disagree. Everyone will make at least one major blunder in 1. and probably more. I don't care how much thought you think you put into it, you will make mistakes if you move proactively and not just sit there and wait until you are forced to act or the problem goes away. Companies live or die by how nimble and effective they are at fixing the messes made in 1. while moving forward.

lmm 4y ago

Why should it be otherwise? Any software development interesting enough to be worth working on will be at least partly a research project, and research always involves wrong directions and dead ends. If you didn't learn something that would radically change your understanding of how you should architecture your system, you launched too late.

8n4vidtmkvmk 4y ago

yep. and then they put tight timelines (meaning like 1.5 years) to finish those massive migrations and so we take more shortcuts to finish them and i guess technically we end up on the new platform but the implementation is about as bad as the original

bl4ckm0r3 4y ago

the problem is that most people/orgs don't think this way, they still think their solution is scalable and easy to start (like RoR) and no one optimizes for deletion so eventually you are stuck with all those initial choices until you spend a lot of money to overcome them (literally in every company i have worked at, authentication, MVC - with more than 3k loc controllers - and monoliths were "impossible" - as in not economically sustainable - to refactor. I think there's a misunderstanding of the word "easy", django, springboot, laravel, RoR etc are easy to start with, as most architectural choices come out of the box, but then you can never leave that box.