[flagged]
Imaginary problems are the root of bad software
481–490 of 511 posts
Re: Imaginary problems are the root of bad software
#482[flagged]
Re: Imaginary problems are the root of bad software
#483[flagged]
Re: Imaginary problems are the root of bad software
#484[flagged]
Re: Imaginary problems are the root of bad software
#485Earlier quoted context omitted.
"Show me the incentive, I'll show you the outcome." - Charlie Munger
Isn’t he the guy who tried to get a university to build a giant windowless dormitory cube?
Still don't understand the opposition to that. Students get affordable, safe, private housing on campus, where there's a million places to hang out beyond your windowless bedroom. Libraries, open spaces, study halls, cafes.
The alternative is often paying $1K for some barely maintained triplex basement shared bedroom off of campus, from a negligent landlord.
Re: Imaginary problems are the root of bad software
#486Earlier quoted context omitted.
>I can give you an abundance of examples. We were creating a page that was going to use state in a certain way. I was trying to insist that we address the way state will be handled across pages ahead of time. These concerns were dismissed as premature optimization. A few months later we had 5 pages with the state being handled in 5 different ways. The right time to address this was probably a bit at a time after the…
Rule of 3 is often correct, first time just do it, second consider if it'll very likely happen a third time and when the third time happens it's darn well time to do it! HOWEVER, this only works if you have the agency at an organization to allocate time for doing something. Contrary to this when you are in an organization of management that doesn't understand technical debt (or is fine with it because it just means m…
The good old "We have other priorities right now and lack of resources"
Preventing fires will never be a priority. Not even if you smell smoke.
Re: Imaginary problems are the root of bad software
#487I 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 qu…
Yeah I deliberately didn’t want to write that much about the retail banking stuff because I don’t know why it is the way it is (though there are a few reasons to guess). People would often give regulations/compliance as an excuse for eg not being able to set up an account online, but then the pando happened and somehow this stopped being such a problem. I feel like either those people were just not knowledgeable about the reasons, or they were rationalising business reasons for the bank to not do those things.
Re: Imaginary problems are the root of bad software
#488If 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. I recall the case of a couple of FANGs who on one hand expect their engineers to deliver simple, maintainable and robust systems to minimize operational costs, but on the other hand they demand engineers operate at the next level to be considered for a promotion, which means they are expected to design non-trivial systems which have a certain degree of complexity and require significant amounts of work to pull off. Therefore, as an unintended consequence, the pressure inexperienced engineers to push needlessly complex projects where they are required to design solutions well above their level of expertise, and put them in a position where their career is personally threatened if anything gets between them and their promotion-driven project.
Re: Imaginary problems are the root of bad software
#489Earlier quoted context omitted.
> “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…
Remember times where you could change the theme and all of the apps followed suit ? Even in Linux there were tools to sync gnome with QT look so you could have one theme applied to every app for nice and consistent look, all the way to how the common icons look. Nowadays ? Every fucking app gotta have their own different styling. Will the setting icon be three dots, gear, or honey badger ? WHO FUCKING KNOWS. You'd be…
> Nowadays ? Every fucking app gotta have their own different styling.
This has more to do with the current state of GUI frameworks than with developer mindset. Microsoft is between GUI frameworks and rumoured to have deprecated everything between win32 and WPF, and in the meantime they are pushing React Native. Apple doesn't seem to know what to do with desktop environments and is stuck between their legacy objective C frameworks which they seem to purposely hide any form of documentation and swift-based frameworks which are broken out of the box. Linux has a couple of options which are ugly as sin since ever. There's Qt, but their licensing scares away anyone with two brain cells to rub together.
So where are we left?
Well, with webview-based frameworks, which is the worst of both worlds but at least they don't look half bad.
Except that webview-based frameworks are a far lower-level abstraction than any native widget-based framework. Developers are forced to reinvent the wheel, and this means dropping any standard look-and-feel because that's already ugly to start with but takes even more work to get into a working state.
And all you want to do is to provide a GUI for users to click around.
Re: Imaginary problems are the root of bad software
#490Earlier quoted context omitted.
> “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…
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…
> None of the current SaaS apps I use can come close to the experience of using softwares from that era.
I'm afraid you're looking at the past with rose-tinted glasses. In general software back then sucked hard. User experience did not existed at all. Developers bundled stuff around, and users were expected to learn how to use software. Books were sold to guide desperate users through simple user flows. Forms forms forms forms everywhere, and they all sucked, no exception. Forget about localization or internationalization. Forget about accessibility. Developers tweaked fonts to be smaller to shove more controls into the same screen real estate, and you either picked up a magnifying glass to read what they said or you just risked it and clicked on it anyway.
Software back then sucked, and sucked hard. Atrocities like Gimp were sold as usability champions. That's how bad things were.