I don’t like developers getting blamed for what is often due to being rushed to arbitrary deadlines from management. But, I will say I agree with the article in that a large portion of the development toolbox is completely fucked. The last 15 years of most business development has basically been this:
- Let’s implement cool JS frameworks that don’t really work with the browser natively!
- Let’s execute browser code on the server and server code on the browser!
- Let’s transpile code to artificially improve upon native languages and make our JS frameworks easier to code. We need a transpilation tool!
- Let’s take “DRY” way too far! Everything we need should already be in existing code packages we can combine together. We need a package manager tool!
- Uh oh, it’s too hard to start projects. We need a scaffolding tool!
- Uh oh, we now have too many packages. We need a bundling tool!
- Uh oh, our development environments are now too complicated to setup. We need a virtualization container tool!
- Uh oh, we have too many virtual machines. We need a container management tool!
- Uh oh, deployments are super complicated now. We need deployment automation tools!
- Ok, NOW we’re setup to code 20% faster, but we need 3 new DevOps employees to support all this.
- Oh yea, we’re “agile” now too. I think that means we fire our QA testers. I’m not sure. We can’t agree on what being “agile” even means.
Not saying it’s all bad. Mostly good ideas that have gone off the rails.
Let’s also not forget “half of what we’re using frameworks for has been directly supported by every browser since 2011 but we still have a dependency on a framework that extends another framework that hard-requires jQuery as a selector engine so we’re not going to remove any of them”.
It’s kind of depressing to ship two megabytes of dependencies for something a hundred lines of vanilla JS would do just fine these days. But of course it’s far easier to maintain external code than int– oh wait, one of our dependencies switched a dependency and now security needs to re-evaluate the stack before we can install the latest security-relevant update.
reminds me of this:
simple and genius
I’m in this thread, and I don’t like it.
I’ve always thought that the recent surge in popularity of containerization was not the solution to a problem but the symptom of a bigger issue.
Would you be surprised to hear software developers do test their software? It might not feel like it with all the outages this year, but the average developer spends 42% of their work week on maintenance.
Uuuhm… Those are not the same thing lol
Maintenance is much more than “testing the software”.
The internet made code brittle because updates could happen anytime. Pre-internet, your software came in a box and that was it for this version. Companies had to test the hell out of it. Even after we got internet updates, but before broadband, people had to deliberately seek out updates, download them at painfully slow speeds, and maybe even write them to a disk to install them. I remember a MacOS update that spanned fourteen floppies.
But that simplifies things too much. Our software is also infinitely more complex. Getting into the business of trying to ship new and exciting features over maintaining a solid foundation also eats the industry.
I think it’s a bit different. The updates are a problem, yes, but only because people accept the promise of
goodworking software as if it weregoodworking software. “The next update will fix everything”, while the next update only places another block on top of the Jenga tower. If the next update isn’t just another introduction to an additional enshittification step that we accept because we also already accepted the idea of unsupervised updates.
Too few people know their architecture inside out. With a little discipline, that can change.
Yeah, no. It’s certainly nothing little to have a noticeable impact.
It needs continued investment, and the right people with expertise, and boldness to do what is necessary.
As a software tester, this is too real
If over 40% of development time is just keeping code alive, that’s not adding value to the product.
I assume the 60% “new” development includes 80% technical debt cost. If that doesn’t count towards “maintenance”, and that’s where the distinction is being made, I don’t think it’s a good distinction to make that point.
