5 ms·

At some point, every engineer has heard this same argument but in favor of all kinds of dubious things such as emailing zip files of source code, not having tes

At some point, every engineer has heard this same argument but in favor of all kinds of dubious things such as emailing zip files of source code, not having tests, not having a build system, not doing IaC, not using the type system, etc. I'm sure Rust was the wrong tool for the job in your case but I find this type of get shit done argument unpersuasive in general. It overestimates the value of short-term delivery and underestimates how quickly an investment in doing things "the right way" pays off.

djbusby 4y ago
The business owner (whoever writes the checks) prefers get shit done over "the right way". Time to completion is a key factor of the payoff function of the devs work.
- CipherThrowaway 4y ago
  The entire point of doing things the right way is that you end up delivering more value in the long term, and "long term" can be as soon as weeks or even days in some cases. Business owners definitely prefer less bugs, less customer complaints, less support burden, less outages, less headaches. Corner cutting doesn't make economic sense for most businesses and good engineering leadership doesn't have much trouble communicating this up the chain. The only environment where I've seen corner cutting make business sense is turd polishing agencies whose business model involves dumping their mistakes on their clients and running away so the next guy can take the blame.
  - airtag 4y ago
    Try the travel/event booking business (where I'm in) - and no, people don't dump their mistakes on the next guy here - to the contrary, the "hacky" Python solutions are supported for years and teams stay for decades (allthough a decade ago we had not discovered how great Python was) What business owners actually don't like at all is how long is takes traditional software development to actually solve problems - which then don't really fit the business after wasting a few years of ressources... and the dumping and running away is worse in Java and other compiled software. With Python you can at least read the source in production if the team ran away...
    - ElectricalUnion 4y ago
      > the dumping and running away is worse in Java and other compiled software. With Python you can at least read the source in production if the team ran away... Java (and dotnet, the two big "VM" languages) is somewhat of a strange example for that; JVM bytecode is surprisingly stable and reverse engineering is reasonably easy unless the code was purposely obfuscated - a bad sign on any language anyways.
ubercore 4y ago
Using Python vs Rust is in no way in the same league as not having tests.
- CipherThrowaway 4y ago
  Totally agree. That's why I clarified: > I'm sure Rust was the wrong tool for the job in your case but I find this type of get shit done argument unpersuasive in general. Unless you're working on a fire-and-forget project with a tiny time horizon get shit done arguments are blatantly short-termist.
  - cwyers 4y ago
    The thing is that the short term is much easier to predict what you're going to need and where the value is, and in the long term you might not even work on this codebase anymore. Lot of incentives to get things done in the short term.
airtag 4y ago
Totally depends on the business you're in. If you're dealing in areas with short time limits then Python is great, because you can't sell a ticket for a ship that has sailed. And I've seen "the right way" which, again, depending on the business may result in a well designed product that is not what's actually needed (because people are really bad at defining what they want) What's brilliant with Python compared to other hacky solutions that it does support test, type hints, version control and other things. It just doesn't force you to work that way. But if you want to write stable, maintainable code, you can do it. That means you can write your code without types and add them later. Or add tests later once your prototype was been accepted. Or whenever something goes wrong in production, fix it and then write a test against that. Oh and I totally agree you should certainly try to "do things the right way", if the business allows it.
- osigurdson 4y ago
  It is hard to believe that Python is objectively that much more productive than other languages. I know Python moderately well (with much more real world experience in C#). I like Python very much but I don't think it is significantly more productive than C#.
  - zeku 4y ago
    Python is out of this world more productive in the Science space and Data space. The only thing that can compete with it for productivity in the science space is R.
    - deleted 4y ago
      [deleted]
    - cjalmeida 4y ago
      This. C#, Java or even newcomers such as Kotlin/Go are even in the same ballpark due to the REPL/Jupyter alone. Let alone when you consider the ecosystem
  - kyawzazaw 4y ago
jimbokun 4y ago
> It overestimates the value of short-term delivery For an early stage start up this is almost the only relevant factor for success.
- CipherThrowaway 4y ago
  From the other half of that sentence: > underestimates how quickly an investment in doing things "the right way" pays off. What time horizon should a startup optimize delivery for? Minutes, hours, days, weeks? Say you're a startup dev in a maximalist "get shit done now" mindset so you're skipping types, tests, any forethought or planning so you can get the feature of the week done as fast as possible. This makes you faster for one week but slower the week after, and the week after, and the week after that. Say a seed stage startup aims for 12 months runway to achieve some key outcomes. That's still a marathon. It still doesn't make sense to sprint the first 200 meters.

djbusby 4y ago

The business owner (whoever writes the checks) prefers get shit done over "the right way". Time to completion is a key factor of the payoff function of the devs work.

CipherThrowaway 4y ago
The entire point of doing things the right way is that you end up delivering more value in the long term, and "long term" can be as soon as weeks or even days in some cases. Business owners definitely prefer less bugs, less customer complaints, less support burden, less outages, less headaches. Corner cutting doesn't make economic sense for most businesses and good engineering leadership doesn't have much trouble communicating this up the chain. The only environment where I've seen corner cutting make business sense is turd polishing agencies whose business model involves dumping their mistakes on their clients and running away so the next guy can take the blame.
- airtag 4y ago
  Try the travel/event booking business (where I'm in) - and no, people don't dump their mistakes on the next guy here - to the contrary, the "hacky" Python solutions are supported for years and teams stay for decades (allthough a decade ago we had not discovered how great Python was) What business owners actually don't like at all is how long is takes traditional software development to actually solve problems - which then don't really fit the business after wasting a few years of ressources... and the dumping and running away is worse in Java and other compiled software. With Python you can at least read the source in production if the team ran away...
  - ElectricalUnion 4y ago
    > the dumping and running away is worse in Java and other compiled software. With Python you can at least read the source in production if the team ran away... Java (and dotnet, the two big "VM" languages) is somewhat of a strange example for that; JVM bytecode is surprisingly stable and reverse engineering is reasonably easy unless the code was purposely obfuscated - a bad sign on any language anyways.

ubercore 4y ago

Using Python vs Rust is in no way in the same league as not having tests.

CipherThrowaway 4y ago
Totally agree. That's why I clarified: > I'm sure Rust was the wrong tool for the job in your case but I find this type of get shit done argument unpersuasive in general. Unless you're working on a fire-and-forget project with a tiny time horizon get shit done arguments are blatantly short-termist.
- cwyers 4y ago
  The thing is that the short term is much easier to predict what you're going to need and where the value is, and in the long term you might not even work on this codebase anymore. Lot of incentives to get things done in the short term.

airtag 4y ago

Totally depends on the business you're in. If you're dealing in areas with short time limits then Python is great, because you can't sell a ticket for a ship that has sailed. And I've seen "the right way" which, again, depending on the business may result in a well designed product that is not what's actually needed (because people are really bad at defining what they want) What's brilliant with Python compared to other hacky solutions that it does support test, type hints, version control and other things. It just doesn't force you to work that way. But if you want to write stable, maintainable code, you can do it. That means you can write your code without types and add them later. Or add tests later once your prototype was been accepted. Or whenever something goes wrong in production, fix it and then write a test against that. Oh and I totally agree you should certainly try to "do things the right way", if the business allows it.

osigurdson 4y ago
It is hard to believe that Python is objectively that much more productive than other languages. I know Python moderately well (with much more real world experience in C#). I like Python very much but I don't think it is significantly more productive than C#.
- zeku 4y ago
  Python is out of this world more productive in the Science space and Data space. The only thing that can compete with it for productivity in the science space is R.
  - deleted 4y ago
    [deleted]
  - cjalmeida 4y ago
    This. C#, Java or even newcomers such as Kotlin/Go are even in the same ballpark due to the REPL/Jupyter alone. Let alone when you consider the ecosystem
- kyawzazaw 4y ago

jimbokun 4y ago

> It overestimates the value of short-term delivery For an early stage start up this is almost the only relevant factor for success.

CipherThrowaway 4y ago
From the other half of that sentence: > underestimates how quickly an investment in doing things "the right way" pays off. What time horizon should a startup optimize delivery for? Minutes, hours, days, weeks? Say you're a startup dev in a maximalist "get shit done now" mindset so you're skipping types, tests, any forethought or planning so you can get the feature of the week done as fast as possible. This makes you faster for one week but slower the week after, and the week after, and the week after that. Say a seed stage startup aims for 12 months runway to achieve some key outcomes. That's still a marathon. It still doesn't make sense to sprint the first 200 meters.