10 ms·
On the other hand, in software-related matters, I have the increasing feeling that kludges and temporary decisions made in the "First do it" stage, tend to get
by j1elo 3y ago
On the other hand, in software-related matters, I have the increasing feeling that kludges and temporary decisions made in the "First do it" stage, tend to get carried on to infinity through the other phases.
Thus, lots of stuff that falls in the "Important, but Not Urgent" category of the Eisenhower Matrix end up never getting its proper development time. One could argue "well, then maybe they weren't actually that important, were they?" but I'd reply that usually the criteria to define something as important is measured with growth potential, and that's the wrong bar to use.
That's how we end up with "we'll build it in Electron for the time being and later will rebuild in proper native apps if the idea works" ends up being still Electron 10 years later. Or how "we'll make our own controls and later worry about accessibility" turns out never worrying about it.
- cryptonector 3y agoIt's not just software. It's everything. It's even things like parenting -- per TFA you'd have to have three children to maybe get it right, but things are not that easy.
- sockgrant 3y agoYeah but if something stays in Electron 10 years later then either it’s not successful enough to warrant the cost of a rewrite or the payoff of the rewrite isn’t a good trade off. In both cases if originally building in Electron was a substantial productivity boost then it sounds like it was the right choice.
- jamiek88 3y agoI don’t think that’s specific to software. After all the phrase ‘there’s nothing so permanent as a temporary repair’ comes from construction. I think the difference is rules and licensing were created around physical repairs and construction because of the human tendency to ‘good enough’ it. And to be fair software that has the same safety importance as bridge sturcutural calculations does have a level of scrutiny around it commensurate with its importance, see NASA and their caution and flight / avionics software for aircraft etc.
- yokoprime 3y agoI think the "good enough" mindset should always be challenged by a voice pushing for perfection, and solutions should try to land somewhere in between the two extremes.
- mjr00 3y agoBut outside of the small percentage of technical people who know how inefficient e.g. Discord and Slack are, and how you could replace these applications that take 800MB of RAM each with something that took less than 50MB if they weren't using Electron... nobody cares. If people did care, you'd have someone writing a highly optimized chat/voip app from the ground up in Rust and native code for the mobile versions and people switching en masse. But it just hasn't happened, because for 99.999% of the world, they're good enough.
- JohnFen 3y agoI care a lot, but I'm not going to write a good version. Instead, I just don't use those apps (except at work where they force us to use Teams) -- that's a whole lot easier.
- mcronce 3y agoI care enough to violate TOS by bridging (some of) them to my Matrix server and chatting through a Matrix client instead. But absolutely not enough to (A) write one, and (B) attempt to acquire market share.
- dylan604 3y agoI don't know that this is accurate either though. Sure, there's as you say a small number of technical people that understand why an app taking 800MB+ of RAM is causing the sluggishness felt by 100% of users. There are other savvy enough people that know that having Slack and/or Discord open causes things to be less snappy. So even if they don't know why, they would also appreciate the rewritten app as much as the rest of us.
- jimmaswell 3y agoDiscord's never had major performance problems for me, at least compared to anything else like Skype.
- mjr00 3y agoOf course if a snappier UI came "for free" nobody would be mad about it. But how many people would actually switch chat apps because of it? Discord and Slack are valued at $15b and $27b respectively; if you could get people to switch to a more efficient program written in native code, you'd become extremely wealthy.
- marcosdumay 3y agoIf you don't have the time and agency to do-it-right, you won't. It's tempting to believe that just by dropping the "discover what you need to do step" and you'll get enough time for it and make the thing a single change you can plug on your Jira. It's also delusional. A blatant lie people have been repeating to themselves for half a century, while fully knowing it's wrong for the entire time.
- deleted 3y ago[deleted]
- stouset 3y ago100%. “Do it right” should always be the first goal. Then you make concessions to make sure it works in the flawed reality it needs to operate in. A classic example from back in the day (maybe it’s still this way): don’t just design your webpages for IE. Write the markup and stylesheets as they ought to be, then amend as necessary to make it look correct for each browser’s quirks.
- mattchamb 3y agoTo interpret your example in another way, a page working in IE is doing it right. So first you do it, and structure it the way you think it should be done with "correct" markup. Once you have that, you can then do it right and get it working properly in IE. After that, doing it better would be restructuring things so maybe you dont need as many hacks.
- pixl97 3y agoReality: Your employer doesn't pay you to write 'right' software, they want a deliverable that works in IE by end of day tomorrow and for the life of you, you can't figure out where half the elements are actually displaying.
- stouset 3y agoReality: it is far easier to iterate on software that’s clean and mostly correct than it is to do on software that is riddled with hacks, gotchas, footguns, and long-distance side effects. It’s extremely depressing working with “senior” engineers who’ve spent an entire career with the above mentality, who have missed out on any chance at ever learning how to actually engineer software for reliability and maintainability. Their inability to do so reflects on a lack of practice rather than some sort of fundamental impossibility. Which sadly seems to be a widespread misconception these days.
- uuddlrlrbaba 3y agoBecause more often than not good enough is good enough. Electron is a great example. Look at the market share of slack, discord, spotify, etc. Optimizing as step one is a very good way to not ship on time and miss opportunities to competition.
- chrisdbanks 3y ago+1
- yashap 3y agoAgreed, and as much as ppl hate it, this applies to a11y too. Ultimately all work that businesses do is only done if it’s a high enough priority for the business. If you have a massive customer base, and/or specific important customers who require strong a11y, then you prioritize it. But if you have a smaller customer base, with no important customers pushing for a11y, it’ll probably never get prioritized. That obviously sucks for your users who really need it, but if there aren’t many of them, the site/app/whatever will just be hard to use for them, probably forever.
- dbg31415 3y agohttps://www.rhysmills.com/post/2023/02/10/a11y-isnt-accessible.html https://www.rhysmills.com/post/2023/02/10/a11y-isnt-accessib...
- NooneAtAll3 3y agofinally I can express my opinion by linking to someone else's thank you I hate "ally" thing so much >_<
- justinclift 3y agoFor an article that seems overly long and wordy that includes things like: On the initial use of an unfamiliar acronym within a document or a section, spell out the full term, and then put the acronym in parentheses. ... then goes on to lecture people about making things understandable... not even mentioning wtf "a11y" is supposed to mean is kind of taking the piss. :/
- roenxi 3y ago"we'll build it in Electron" isn't a kludge or temporary decision though. It is an acknowledgement that there aren't enough devs on payroll to support a true-native app. The tradeoff is RAM for developer time and hiring efficiency. That is a pretty good trade; RAM is there to be used. The technical issue here is that the protocol is closed, not that the client is fat. So someone in a RAM-constrained environment can't choose to make different trade offs. But the protocol being closed, while annoying as a user, is definitely a strategic choice.
- Analemma_ 3y agoPeople who constantly bellyache about Electron need to compare the all-up cost of one web developer-- of which there is a massive supply in the labor market-- versus one experienced native dev per OS, who are rare and expensive and getting more so all the time as the desktop withers as a development platform. That cost difference absolutely can be the difference between economic viability and unviability, but HN constantly seems to think companies only pick Electron because they're cackling with glee at the thought of wasting their customer's CPU cycles or whatever.
- progmetaldev 3y agoOn top of having different teams supporting each OS, because a company developing a project this large isn't going to have a small team where the developers know each OS (not quite full-stack in the web development stack, but just comparable to developers that know every OS they need to build for). There then needs to be communication between different development teams, as well as offering feature-parity across OS's, because your clients need to be able to communicate with each other across OS's since your product is a chat application for business. It's not normally acceptable to have features that are different between OS's when your product is meant for team chat.
- rubyfan 3y agoI hate to break it to you, some things are good enough.
- hoten 3y agoBezos talks about this a lot. Decisions can either be significantly important to get right and worth spending the time to explore fully all the options --- or not so much, but only if the cost of getting it wrong is cheap. The key is realizing this dichotomy exists, and then figuring out how to identify the problem in front of you as one or the other.
- coldtea 3y ago>Bezos talks about this a lot. Decisions can either be significantly important to get right and worth spending the time to explore fully all the options --- or not so much, but only if the cost of getting it wrong is cheap. reply So he basically says "It will either rain, or it will not rain".
- hoten 3y agoNo, I said different words than that. Maybe my edit clarified.
- coldtea 3y agoI know, I was mostly interested in capturing the "amounts to" of what he said, as opposed to the precise words. That some decisions are more important to get right than others (that "the dichotomy exists"), is just a trivial observation, the kind that people like Bezos make to appear insightful "technical leaders", but which are ultimately empty, amounting to "some decisions are important, others are not". Gee, thanks, Jeff! The interesting part is knowing which case is which, or advice for that - which the above leaves out.
- DANmode 3y agoI read it as "some decisions end up being more important than others, with no way to know beforehand, keep trying things to increase your luck surface".
- ctvo 3y ago1-way and 2-way doors in the Amazon lexicon is useful. Worth noting: Most decisions are 2-way doors. Very few decisions are 1-way doors. It takes experienced folks to identify true 1-way doors and apply the brakes. Having a culture of thoughtful document reviews, for example, gives space for people to identify 1-way / 2-way doors and push back. Having institutionalized knowledge gained from 20 years of running the largest public cloud provider helps in identifying 1-way doors in software development too. All of that is to caution... yes, Bezos says useful things, can you take it and apply it to your company? Maybe. Do you implement / have the rest of what made it work well for Amazon too?
- treprinum 3y agoNothing is more permanent than a temporary solution.
- JohnFen 3y ago> On the other hand, in software-related matters, I have the increasing feeling that kludges and temporary decisions made in the "First do it" stage, tend to get carried on to infinity through the other phases This is true, unless you also follow the "throw away your first draft" process. If you do that, then you also throw away all of the duct tape and bubble gum you put in while figuring out what you're actually doing.
- Cannabat 3y agoAlways throwing away the first draft is such a useful strategy. Besides almost always resulting in a better finished product, it keeps you humble and light - life is an experiment!
- sanderjd 3y agoAll three legs of the "first do it, then do it right, then do it better" stool are necessary parts of this philosophy / methodology. It's indeed a difficult and rarely-achieved practice. But personally, I think it's the better aspiration, even recognizing that it often gets stuck at the first step. I think the alternative of trying to start with "build it right" also usually falls into its own failure modes - analysis paralysis, crumbling under the weight of adding all the complexity all at once rather than iteratively, etc. - which in my view are even worse.
- satvikpendem 3y agoIn companies, software exists to serve business and customer needs, not the other way around. SWEs are typically shielded from the business side so many don't understand this and treat it like an art form, which it can be, but that is not its primary purpose. If Electron didn't work, people wouldn't use it. If it takes 2x as long to make native apps while your competitors use Electron, they will supplant you.
- hinkley 3y agoMy read is that most people try to skip step 2. So we either stay with the kludge, or we double down on it, making it even more expensive to remove than if we had just left it. The real revelation for me though is the reversible decision, to the point that for really reversible decisions, I can be very averse to us spending any significant meeting time on it at all. There are 6 of us here, let's not waste man-hours on something we could as easily decide with a random number generator. Move on to something more delicate.
- myaccountonhn 3y agoAnother approach is to “do it right but small”, ie do an analysis of what is the smallest needed piece for it to work, the mvp, and then build it properly with good foundations and measurements in place. I worked this way with a super strong business PM. Each iteration was small but we measured everything and made sure it had impact. Every feature was built properly, IE tested, refactored, typed etc. It made our pace more steady. If something didn’t have an impact we tried to understand why, incidents were reported and properly remedied. Still the most solid way I’ve worked.