Big tech internal incentives really exacerbates this. The entire performance system incentivizes engineers to create imaginary problems and solve them. Honestly, I think a good chunk of engineering activity are along these lines. Literally just imaginary problems being created which compound into more imaginary problems, all which are used by engineers to justify their existence.
Imaginary problems are the root of bad software
491–500 of 511 posts
Re: Imaginary problems are the root of bad software
#492A drop of anecdata: Once had a several-days argument about deploying a fix involving an SQL query analysing information from our deployed devices because the other developers were convinced it wouldn't work efficiently for 1000+ devices. Client was threatening to withdraw their money and support -- which would have killed the company I was working for -- if we didn't make things work RIGHT DAMN NOW. Reader, we had 25…
L'Enfer c'est les autres programmeurs.
Hell is other programmers: Existential programming and the perpetual ontological struggle of solving imaginary problems together.
Re: Imaginary problems are the root of bad software
#493Earlier quoted context omitted.
All this sounds great from the perspective of retail shrink wrap software. Today, the major use cases for Qt on the desktop are in-house corporate software. And, no one cares about "uncanny valley". Only HN and online nerds care about that stuff. Average, non-technical, corporate users care about functions, not form. Hell, they are happy with a VBA app! Also, lots of in-car and in-seat (aeroplane) entertainment syste…
There's a reason in-house corporate software started becoming web based 15-or-so years ago: web is cheaper, easier to hire for, faster to develop and deploy, doesn't require installation or updates, easier to troubleshoot, doesn't need special pipes for communicating with the server (yeah I remember the days of DCOM, CORBA, WCF and other weird protocols instead of HTTP). It is things like Qt that only HN and online n…
No, long term, web apps are more expensive because the front end needs to be completely re-written ever few years. A desktop app written in Qt can be kept running for a decade with very little work. (This assumes no Qt library upgrades, which for in-house apps, are most unnecessary.)
The primary advantage of web apps is "zero install", which is a major point of friction at large corps.
Re: Imaginary problems are the root of bad software
#494Earlier quoted context omitted.
Learn what? That you should use the language that you’re more comfortable with and then scale? Or that languages have become more efficient? Php 8, for example, is many times faster than the php 4 and 5 that Facebook was using.
In part the reason that PHP8 (and it was 7 that had the quantum leap in perf) are now so fast is precisely because of Hack - it was easy to accept the status quo on performance until Hack showed there really was a lot of performance left on the table. For me the biggest win was the changes they made to how arrays are stored in memory, I saw some systems drop by half in memory usage and had to change basically nothing…
Yeah, I know the performance optimization were in part because of hhvm.
Re: Imaginary problems are the root of bad software
#495Earlier quoted context omitted.
No, it’s bad business because it doesn’t scale. Software is lucrative because you make it once and sell it to thousands of customers. If you’re making every customer their own bespoke thing, you’ll spend all your time for little return.
“Billed to the customer” means you’re charging the customer by the hour / project. You can get plenty of return selling bespoke things this way. Accenture is a $200 billion company.
That’s called Professional Services. Professional Services assemble a solution for a customer from a variety of components and maybe build some glue or the equivalent of a dashboard. This is not the same as having a ton of “if” statements in code to handle customer X vs customer Y.
The secret, as a software vendor, is to generalise these bespoke customer requests so you can sell the solution to all your customers (and get more customers!). If you are really cheeky, you can even get that customer to help fund the development that will make your business more money (hey, it’s win-win). You need to ruthlessly follow this approach though, as the rot of bespoke code will quickly become an insurmountable quality nightmare that can sink your business.
Re: Imaginary problems are the root of bad software
#496Earlier quoted context omitted.
That's been a thing for 30 years. Entrepreneurship is HARD, and tech salaries are fat right now. I think we'll see a lot more software entrepreneurship when there's another recession.
Makes you wonder what the actual state of the industry is right now with thousands of layoffs, but then comments like this one. Probably it's a bifurcation and an uneven distribution of reality.
There were layoffs in the big tech companies, but the sector itself is strong. Still very low unemployment. They over-hired. It happens. It's been a relative minor correction.
Re: Imaginary problems are the root of bad software
#497Earlier quoted context omitted.
New is not always better, but many times it is. We see this for example in programming languages, where newer ones incorporate the best features of their predecessors. I think there are two things to be wary of: 1) Selecting a new technology just because it's hot, and 2) Refusing to consider new technology because the old stuff "just works." A good engineer looks at the requirements and selects the best tool to solve…
If new is not always better, then you’re stuck with the really hard job of knowing when it’s worth moving to the new thing. Worse, you’ll be blinded by survivability bias. One easily notices the good rewrites and can easily ignore the bad ones. Even worse, bad rewrites may be noticed in a place that a year or two ago was deemed a success story. I’ve seen many such cases due to misunderstandings or just political dyna…
Yeah, good point--when I said new wasn't always better, I was just talking about the case where the new tech solves a problem, but it's not the one you have.
Like choosing GraphQL just because it's new, even if your data doesn't have the structure for it.
Will have to disagree with you on Scala for several reasons I won't go into here--but the point was just that, in order to make these arguments in the first place, you need to do your research. Seems commonsense, but surprisingly many people don't do it (including younger me).
Re: Imaginary problems are the root of bad software
#498If you only paid $15,000 for all of that technology after only two months and you're salty about not having automatons carrying out your commands, you probably should just stick to your podcast show and thank everyone for delivering something, even if it's a few shades different than what you asked for.
These aren't imaginary problems but interesting solutions. I'd bet that card punching programmers working on the first computers were the first to build interesting solutions along with addressing requirements. Look at how far managers have evolved since then.
Re: Imaginary problems are the root of bad software
#499How do you manage boring part though? Going mad because of boredom is a real thing. I definitely agree that some of my job is caused exclusively by my need to keep myself entertained. But what's the solution? Another factor is resume driven development. Yes, you can frown upon it all the day, but in the end I'll switch company and I'll need to find a new job. And, like it or not, but everyone these days wants a lot o…
Try to make it not about the job itself. Reward yourself with other things that are non-code related.
"If I get 5-10 of these done today, I'll reward myself with..."
Or use your imagination in someway like kids do with action figures. It can seem strange but there's ways it less mundane indirectly.
Re: Imaginary problems are the root of bad software
#500Earlier quoted context omitted.
Confirming a hypothesis I put forth in a different comment: Would you say you and your team have ownership of the product? That is to say, there isn't one team doing what you're doing and then another separate team trying to graft new features on all the time, is there? Maybe there is, and maybe that causes issues down the line.
We do have ownership, and I try and structure the development such that every engineer has ownership, decision making power and accountability. I aim for a flat responsibility structure as much as possible. We have lots of work to do, lots of changes in process and despite the constraints we have a steady stream of features we do add. The trick is to ensure the culture of solid engineering goes right through the orga…
Are you guys hiring. I pride myself on writing short, simple and readable code.