"Rule Eight: Don’t try to create and analyze at the same time. They are two different processes."
— Today You Need a Rule Book, 1973.
Imaginary problems are the root of bad software
301–310 of 511 posts
Re: Imaginary problems are the root of bad software
#302Earlier quoted context omitted.
> No engineer is paid extra for keeping the codebase without growing too much. I am. I'm paid more than most developers to run a team doing just this. We make minimal change, have an absolutely non-negotiable focus on stability and minimalism and reject any change that isn't absolutely driven by validated majority user need. Even then, the bar is high. I'm not saying this is a common situation, but it certainly isn't…
What kind of software do you work on? At what company? I have seen low level parts that are managed well, because employees have skin in the game But I’ve also seen a lot of what this post is talking about
I work at a consulting firm.
Our salary is loosely linked to what percentage of our work is billable (with leniency for inexperienced staff, who aren't expected to be profitable while they're learning their craft).
If you spend three hours figuring out why things fall apart on the 31st of the month... that generally can't be billed to the client, and therefore it's bad for your salary.
On the other hand, if you spend three hundred hours writing tests and implementing an awesome multi-stage deployment process that avoids one production bug a month? Your manager can totally bill that work (with the right client).
Re: Imaginary problems are the root of bad software
#303If anything it's the incentive system in software industry, which is at fault. 1. No designer is given promotion for sticking to conventional designs. It's their creative & clever designs that get them attention and career incentives. 2. No engineer is paid extra for keeping the codebase without growing too much. It's re-writes and the effort he puts in to churn out more solutions (than there are problems) that offer…
With developers, incentive misalignment is just insane at all levels. - There is bias towards rewarding more lines of code or more code commits (which is often the exact opposite of what characterizes good software design). - There is bias towards rewarding speed of initial implementation (which often goes against medium-term and long term maintainability and ability to handle requirement changes which is usually far…
Mega agree with this. It was really bad for my personal/career growth to get a ton of praise for doing things fast: granted, a lot of people doing the praising had precious little experience in tech themselves. I probably have 2-3 whole dead years where I could have been learning/improving a lot more but got put in “10x developer” expectation projects where I’d churn something out, get a big shiny star sticker for it, and then 2 years later it would be abandoned because there was no incentive for anyone but me to maintain it, and who would want to because it was shitty code with hacks and tech-debt, and anything that isn’t writing a fucking mountain of new garbage code gets in the way of shiny star collection.
Re: Imaginary problems are the root of bad software
#304Earlier quoted context omitted.
Am GP, it is finance based, but not commercial finance. Most of the systems handle complex calculations. The system is a monolith that has been around for 15 years or so. It isn't cool. It isn't pretty. Lots of it would be better for a refactor, but absolute stability is the goal. Refactoring things may result in long-term cost savings, but with risk. The business has no risk appetite, so it doesn't make sense. If it…
Interesting, I believe there is something to finance that allows or forces things this way. There’s much less fidget spinning and much more business in it for some reason.
Regulations (as sibling comment mentioned) is one aspect, but also the cost of screwing up is real-world. A status quo system that isn’t screwing up has a much higher bar to replace where the risk that the replacement system will screw up.
Much of the same reasoning and even more extremely applied, is medtech - hence why you see many medical imaging setups still obviously running a version of Windows XP.
Re: Imaginary problems are the root of bad software
#305Summing it up:
* Communicate effectively - avoid middle layers
* avoid over imagination / premature optimization
* Incentivise for organisational efficiency
Re: Imaginary problems are the root of bad software
#306Earlier quoted context omitted.
> Will the setting icon be three dots? Multiple hamburger menus with a scattering of cryptic icons stuck at arbitrary places on the screen. What does the swirly icon with up arrow do? No text label for you! Oh and let's move the next button to the top left of the screen and not highlight it. Mmmm that's some good UI design.
Might be a coincidence, but that's a weirdly accurate description of MS Teams.
Not mentioning about the wording (at least in spanish) is awful too.
Re: Imaginary problems are the root of bad software
#307Earlier quoted context omitted.
Qt isn't even in the radar of most companies currently building multi-platform applications in HTML. And it won't be soon, for two main reasons: developers able to use it are expensive, and most Qt applications in the wild still have the "uncanny valley" look and feel about them on every OS but Linux. Not to mention that with SaaS being more profitable than selling unlimited-use licenses, a lot of apps also have HTTP…
Qt has uncanney valley... do you think people using HTML care to make things look native then?
No. Why would they? The reason HTML apps don’t suffer from the uncanny valley problem is because they don’t try to look native at all, it's just something totally different.
When they suck it's not because it looks "almost but not quite there".
But there are exceptions: when Cordova/Ionic tries to imitate the look of iOS/Android's native controls. Then we have an uncanny valley problem.
Re: Imaginary problems are the root of bad software
#308Earlier quoted context omitted.
From a person who started using computers from the early 2000s era: THANK YOU! None of the current SaaS apps I use can come close to the experience of using softwares from that era. Take a simple list view of a typical Windows/Mac software? 1. Command clicking selected multiple objects 2. Shift clicking selected a range. 3. Right clicking brought up selection actions. 4. Double clicking opened an object. This pattern…
I can’t help but feel that Agile is at least partly to blame for this. Things like you are describing usually don’t come under the “minimum viable product” purview and thus get pushed out indefinitely until the product is at the “very mature” stage. At that point there’s the risk that the product will be re-written and the cycle reset again.
Nah. If anything a lot of these trends are directly anti-agile, e.g. avoiding labels and using icons so that it's easier to translate your app, even though the icons take longer initially and you're never actually going to translate your app.
Re: Imaginary problems are the root of bad software
#309I don’t know what is going on with this article. The first half is a maybe reasonable description of a common way for certain kinds of contracts to go wrong. But obviously lots of software doesn’t get developed in this sort of arms-length way. I would say that imaginary problems (as the author defines them) cause failed projects by consultants/contractors. I find the rest of the article to be bizarre. The discussion…
The second part of the article makes it clear that the author has never worked in online banking (I have), and possibly any other complex domain.
> Have you ever heard about those three web engineers who figured out that secure online banking is actually quite an easy problem to solve?
> The storage and transfer of numbers is not a particularly hard problem.
These quotes are so incredibly disingenuous that make me question any advice OP has to offer.
First, banking is quite a complex domain, and it's complexity increases exponentially with the kind of services that you offer.
Second, banking is a highly regulated industry, which makes everything why harder than "it should". In fact many "neobanks" have appeared in the last decade, and this is usually their biggest hurdle.
Third, online banking needs to deal with quite a few hard technical challenges. That's why the likes of Monzo, Starling or Revolut often given tech talks.
So no, imaginary requirements weren't the root cause of bad software when I worked in banking. A 20+ years old big ball of mud, inability to pay off any tech debt (unless you wanted to get literally yelled at in front of the entire team), flaky and severely insufficient tests, and a very toxic working environment were all causes of bad software.
Re: Imaginary problems are the root of bad software
#310If anything it's the incentive system in software industry, which is at fault. 1. No designer is given promotion for sticking to conventional designs. It's their creative & clever designs that get them attention and career incentives. 2. No engineer is paid extra for keeping the codebase without growing too much. It's re-writes and the effort he puts in to churn out more solutions (than there are problems) that offer…
> “No designer is given promotion for sticking to conventional designs. It's their creative & clever designs that get them attention and career incentives.” This is a massive change from my first software industry job in 1997. I was essentially a “design intern who knows HTML” on a team that built a shrinkwrap Windows application for enterprises. The core of the design team was a graphic designer, a cognitive scienti…
There is a fundamental difference between working on software products vs bespoke software development:
In the former you make money from selling the result, in the latter you make money from selling the hours spent creating the thing.
If the former is unusable it will lead to bad sales. In the latter it might even lead to additional hours sold in change requests.
The former is bought often after evaluation and comparison by the user of the software. The latter is sold to an executive that will never have to use the software as a project.