3 ms·
> Today, the theme is CI/CD, which translates into "figure out how to keep an overstaffed engineering department occupied long after they delivered the working
by _visgean 3y ago
> Today, the theme is CI/CD, which translates into "figure out how to keep an overstaffed engineering department occupied long after they delivered the working system". This translates into shipping broken, buggy, incomplete, software with the intention to keep the department occupied over the long-term with bug fixes, patches, feature updates and releases, and probably the occasional all-up rewrite
you are looking at it from the wrong end. This model is prefered and delivers better results because nobody was able to say what the "complete" sofware should look like. So better to deliver MVP and ask the users what they want to change rather than develop something for years only to discover that its very bad fit.
- HPsquared 3y ago"then" or "than"? Both sentences plausible depending on perspective.
- _visgean 3y agothan sorry
- bane 3y ago> nobody was able to say what the "complete" sofware should look like We had "complete" software for decades. You can use an iterative development model until all of the major goals are achieved then ship a final product. After that it's just maintenance. Iterative development has consumed the ship and maintenance parts of product delivery to the point that the industry no longer even can recognize or remember that such a thing can exist. Enshittification is the result because if you keep going in and messing with a shipped product, the temptation to try to squeeze it for revenue when its market maxes out becomes irresistible. Modern development practices like CI/CD were invented to enable this behavior and really only build value during the earlier core development stages. After that it becomes an extractive process. It's kind of like how when colonial powers were building railroads in India, or Korea, or wherever. The intention was to use the rail lines to extract resources from the colonized territory, but the side effect is that the local people in the country also suddenly had improved transportation infrastructure and oh yeah, jobs. For a while the people who work on or near the rail line "prosper" but nobody remembers that the goal was to suck all of the lifeblood out of the countryside and move it to the ports. Once the line is complete the model flips to extraction and the development activity ceases, and everybody who had previously prospered because they could use the rail line to get jobs, education and health care wonders why life sucks now.
- deleted 3y ago[deleted]
- _visgean 3y ago> We had "complete" software for decades. You can use an iterative development model until all of the major goals are achieved then ship a final product. After that it's just maintenance. well or its not, depends on the industry but most likely there will be new features etc. You need to be able to ship security features and bug fixes continously - e.g. without manual user action because most users simply don't have mental capacity to upgrade software. Alas continous delivery.
- Ferret7446 3y agoWe had "complete" software in the same sense that we had "complete" technology when we discovered fire and caves. There is always something that can be improved or optimized further, although it may require rethinking the problem.