3 ms·

> I think of enshitification primarily as an organisational/business phenomenon rather than a technical one. I will second this. I can't count how many project

by dig1 3y ago

> I think of enshitification primarily as an organisational/business phenomenon rather than a technical one. I will second this. I can't count how many projects were started with a clean design and clean early releases (what worked well), to be later messed up with business changes because the original (business) idea didn't work. And those sudden changes are expected to be implemented usually "yesterday", which adds additional momentum to the project's downward spiral.

matwood 3y ago
> to be later messed up with business changes because the original (business) idea didn't work If the point of a project was to run a business, I would argue the project was messed up from the start if it could not adapt to the changes. Very little software survives contact with the real world.
- josephg 3y ago
  I think software should always be written with a known half-life. Code I write for some one-off script is incredibly different than code I write when I expect the code to outlive me (eg in an opensource library that people depend on). Scrappy prototype code is written with developer velocity as the most important property. I’ll throw everything in one file. Stick to tools I know well. Copy from other projects. Use crap variable names and generally make a bit of a mess. Something made fast can be remade fast if it’s wrong. Code you expect to last a long time should have tests, CI and documentation. If I’m serious, I’ll often rewrite the code several times before deciding on a final design. A good engineer should be able to switch between styles based on the needs of the project. And a good company will make those needs explicit to the engineering team and they’ll be transparent and trustworthy when expectations change. (Eg if a prototype is going to stay in production long term, they need to tell the engineering team). It’s fine for businesses to pivot. And it’s fine for engineers to make quick prototypes to test a business idea. But everyone needs to be on the same page the whole way along.
- ipaddr 3y ago
  If you buy apples only later to realize you need oranges the apple project wasn't a failure. Part of running a business is trying what works. Now if you were unsuccessful finding apples than the apple project failed. The overall business might fail but the apple project went off smoothly

by dig1 3y ago

matwood 3y ago

> to be later messed up with business changes because the original (business) idea didn't work If the point of a project was to run a business, I would argue the project was messed up from the start if it could not adapt to the changes. Very little software survives contact with the real world.

josephg 3y ago
I think software should always be written with a known half-life. Code I write for some one-off script is incredibly different than code I write when I expect the code to outlive me (eg in an opensource library that people depend on). Scrappy prototype code is written with developer velocity as the most important property. I’ll throw everything in one file. Stick to tools I know well. Copy from other projects. Use crap variable names and generally make a bit of a mess. Something made fast can be remade fast if it’s wrong. Code you expect to last a long time should have tests, CI and documentation. If I’m serious, I’ll often rewrite the code several times before deciding on a final design. A good engineer should be able to switch between styles based on the needs of the project. And a good company will make those needs explicit to the engineering team and they’ll be transparent and trustworthy when expectations change. (Eg if a prototype is going to stay in production long term, they need to tell the engineering team). It’s fine for businesses to pivot. And it’s fine for engineers to make quick prototypes to test a business idea. But everyone needs to be on the same page the whole way along.
ipaddr 3y ago
If you buy apples only later to realize you need oranges the apple project wasn't a failure. Part of running a business is trying what works. Now if you were unsuccessful finding apples than the apple project failed. The overall business might fail but the apple project went off smoothly