Live data from Hacker News

Software disenchantment

tonsky.me

91–98 of 98 posts

Re: Software disenchantment

#91
A wise and cynical manager pointed out to me that software purchases are driven by features, not quality. You don't get to assess the quality of software until after the purchase.

All other (feature) things being equal, the first product to market gets the majority of the purchases. So dev teams are in a race to the bottom regarding quality. As long as software is purchased, as long as rival companies compete to provide software, this is an iron law.

To improve software quality in a race to the bottom, we must improve the quality of (young, inexperienced) software developers. But companies don't want to pay for high quality developers, they are content with barely-qualified devs earning the lowest possible wage. They hire young. They hire offshore. They hire minimally skilled talent.

There are places where quality still lives: operating systems, compilers, databases. Places where the software cannot perform its mission if it fails frequently. You have to find one of these jobs, or suppress your gag reflex.

Re: Software disenchantment

#92

People won't pay for efficiency. People buy solutions to their problems (features), not efficiency. If it needs to be efficient, it will be (the games example). The death of Moore's Law may rejuvenate efficient software. BTW If you use old unix tools on a phone, it's super fast (in a terminal emulator like http://termux.com ). Sadly, the idea of abstractions enabling you to think better (like Alan Kay's point of view…

The only sane reason that AirBnb or Uber are worth as much is that they promise to be more efficient than traditional companies. SO the 'market' pays for efficiently and a lot of digital revolution has been all about making existing processes slightly more efficient (Amazon online shopping experience vs physically going to the different shops etc) So the market definitely value the efficiency where the cost of developing that efficiency does not outweigh the benefits. Typing speed and cursor refresh are not limiting factors for programmers so there's diminishing return in making text editors refresh >120hz. Simple business logic and OP can lament as much as he wants to but we have limited resources, mostly time and that time is usually better spent writing business logic than optimising text editor for the 100th time.

Re: Software disenchantment

#93

One of my friend pretend that we - software engineers - should work as mechanical engineers. They have a documented, standardized, and limited set of screws, nuts, ... and they build anything with it. This allow to develop CAD tool to assemble, verify, simulate, ... On our side, we have thousands of implementations of basic SW blocks (fifo, mutex, ...), or even "bigger" concepts (server, reader/writer, state-machine…

When we try to standardize software development, we usually end up with people mindlessly chaining together GoF patterns into AbstractSingletonProxyFactoryBeans.

I don't know why mechanical engineering is different in this regard from software "engineering". Maybe it's because the domain is more restricted (software concerns basically everything, so it's hard to come up with standardized patterns that are still widely applicable). Maybe it's because mechanical engineering is constrained by the laws of physics, whereas software engineering is mostly constrained by the developer's imagination (and resource constraints, but Moore's Law took care of that one for a long time).

Re: Software disenchantment

#94
post #80

My colleagues (and probably twitter followers) are always sick of me ranting about stuff like this. A few years ago I decided to compile screenshots I'd posted on twitter in the previous single month : https://blog.dantup.com/2016/04/have-software-developers-giv... That it happens is bad enough, but the fact that so few care about it is reslly depressing :(

It's an awesome collection you have there, thank you. (And yeah, also a bit depressing...)

Re: Software disenchantment

#95
post #56
post #25

I agree that something is out of whack. In-house plane-jane CRUD development used to be pretty simple and quick in the 90's. One could focus on the domain analysis side instead of micromanage tech. The IDE products had glitches, but got better every release, including deployment. The Web bleeped it all to heck and back, and nobody seems interested in promoting the standards to fix it. We toss in JavaScript gizmos to…

I think this is what pisses me off the most. The frontend is a complete clusterfuck, but the serverside is almost as bad. Everything is just half-assed and you end up spending most of your time fighting the tech. The worst thing is people who have drunk the Kool-Aid and just stare you, uncomprehending, when you complain that lunatics are running the asylum and the only way to win is to not play. Or at best agree but…

> I think I'm done with the tech industry. 98% of the sort of programming people actually pay you for is about as pleasant as a root canal. I'm currently on a sick leave and seriously entertaining the idea of changing careers to something entirely different. Like gardening.

More than a decade of professional software development later, I'm having very similar thoughts.

I now spend 1/4 of my work week fighting dependency hell (after just about each addition of a new package by any other developer on the project), another 1/4 figuring out how the "latest and greatest" tool of the week is best used to do something that would normally take me 5 minutes to do custom (god forbid, not the C-word!), and the remaining half is spent maybe doing actual work. So incredibly frustrating that I've just about had it.

I've grown to loathe and hate that which I used to adore.

Re: Software disenchantment

#96
Excellent. You could have mentioned the tremendous amount of energy wasted by servers and data centers to drive the mess. Is there such a thing as Code Ecology?

Re: Software disenchantment

#97
It really looks like what you are looking for is Software Craftsmanship. Several books have been written tackling this topic. You can watch Robert C Martin (aka Uncle Bob) and others (Sandro Mancuso) talking about this problem and how to address it.
Post reply on HN