[HN Gopher] First do it, then do it right, then do it better
___________________________________________________________________
First do it, then do it right, then do it better
Author : erfanebrahimnia
Score : 131 points
Date : 2024-01-02 18:57 UTC (4 hours ago)
(HTM) web link (twitter.com)
(TXT) w3m dump (twitter.com)
| JadoJodo wrote:
| I love this saying, though I always heard it as a more SE-
| specific addage: Make it work, make it right, make it fast.
| nwienert wrote:
| IMO Make it work, make it right, make it fast is a bit off.
|
| Often the "fast" part is very intertwined with the "right/work"
| part. You can make it work/right and then realize you designed
| the core data structures completely wrong for performance. I
| know, I've made that mistake terribly before where I avoided
| performance until a year after a project was in flight, only to
| realize the fundamental API design actually made it impossible
| to fix. Had to basically start from scratch.
|
| Of course it depends on if performance matters much, but it
| often does.
| Tallain wrote:
| I see Make It Fast as a discrete step after Make It Right,
| because if it's made Right, then you can swap out the parts
| where optimizations need to be made. While you can't always
| know where slowness will occur, you do know that it will
| happen one day, and design the system so that swapping the
| "slow part" for a "fast part" is relatively trivial. That's
| the Make It Right part.
|
| An well-designed API should behave so that you can fudge up
| whatever is happening behind the scenes, so long as the
| outputs remain the same based on the inputs. Design for
| consistency and idempotency. Implementation (read: behind the
| scenes) details are just that, details, and subject to
| change. If your implementation is tied to your interface,
| there are bigger problems and you skipped the Make It Right
| part.
| nwienert wrote:
| My exact case was something like this: I've made a bunch of
| style libraries for web (my latest is Tamagui). The one
| before Tamagui was similar, it had variants and a `styled`
| helper, but it didn't output to "atomic CSS". A full year
| plus into the development of it it was working alright but
| was quite slow due to all the crazy CSS is was generating
| and inserting all the time. Atomic CSS really helps this in
| many ways.
|
| So I dove in, technically I felt I could keep the API
| surface the same. But after about a full month of
| refactoring it to work with atomic CSS I found many
| problems. There are just some fundamental limitations to
| the API design you must enforce to make it work, and
| without such you really can't merge things properly. It's
| hard to explain without writing a mini-book, but needless
| to say the API surface very much can dictate the
| performance, and if you stuff your API with a bunch of
| features before making things fast, you may end up like me
| having to basically start from scratch.
|
| My take: work/right/fast is a loop you must run many times.
| They also bleed into each other. Sometimes you do
| work/right and it feels fast, but you haven't deployed it
| at scale, so you never realize it's not fast. Keep your API
| as simple as you can, try and hit the fast part somewhat
| early before you add many features, and don't be afraid to
| take all your lessons and restart things. If fast is
| important to your lib, making it right must also be done in
| tandem with make it fast.
| Jtsummers wrote:
| > I know, I've made that mistake terribly before where I
| _avoided_ performance until a year after a project was in
| flight [emphasis added]
|
| It's not about avoiding making it fast, it's about
| prioritizing. There's a probably apocryphal story from, I
| believe, _The Psychology of Computer Programming_ (Weinberg)
| where a mainframe programmer opposed a new program because it
| wouldn 't be as fast as theirs. Except their program produced
| garbage results, and the new one produced correct results.
|
| The priority was in the wrong place (speed) rather than the
| business need (correctness).
|
| There's absolutely nothing wrong with making your program
| fast, so long as it's not to the detriment of correctness or
| while avoiding making it correct. Fighting for performance
| boosts in your data access patterns or data layouts while
| still manipulating the data incorrectly is a fruitless
| endeavor.
| sodapopcan wrote:
| Joe Armstrong, one of the inventors of Erlang, seems to agree
| on your last point. He said: "Make it work, then make it
| beautiful, then if you really, really have to, make it fast."
| I think "make it right" is often a moving target in software
| development (depending on how you're looking at it).
| baxuz wrote:
| Yeah, make "make it work, make it right, make it fast" is
| only applicable if you get to throw out most of the work from
| the first two steps, which is rarely the case.
| rogerkirkness wrote:
| My version of this:
|
| 1. Make it possible (even if it's ugly and expensive to do) -
| Blackberry
|
| 2. Make it pleasant/probable (aka improve the UX to customer
| maximum) - iPhone
|
| 3. Make it profitable/cheap (optimize efficiency/cost to deliver)
| - Android
| lostlogin wrote:
| We all agree step 1 lost the battle.
|
| This implies that the business which did step 3 is more
| successful than the one that did step 2. It would be
| interesting to know what Apple and Google think of their
| businesses relative to each other.
| rogerkirkness wrote:
| By market share, Android is over 80%. But Apple still makes
| 100% of the profit. I think I'm referring more to the
| diffusion of technology than the success of the company in
| the space, there's other examples.
| sjfjsjdjwvwvc wrote:
| Blackberry might not be around anymore but 24 years of
| operation and 85 million users (at peak) is nothing to scoff
| at. I would be glad to have founded such a ,,loser"
| alexwebb2 wrote:
| Lots of variations on this. The one I heard first in my career:
|
| 1. Make it work
|
| 2. Make it work well
|
| 3. Make it look good
| geemee wrote:
| I have always heard this when talking about approach to solving
| problems...
|
| Once to understand the problem, once to understand the solution,
| once to do it properly.
| atum47 wrote:
| I've been doing things like this my whole life. It's very easy
| for anyone to criticize things. You know what's not that easy?
| Building something the people can criticize. Once you have
| something, even a proof of concept working, you can improve it;
| given more time and or resources.
| thebruce87m wrote:
| I agree. I call it "something to throw stones at".
| thomastjeffery wrote:
| There is a difference between criticism and discouragement. The
| first is incredibly valuable.
|
| The problem is that it's very difficult to _articulate_ that
| difference. This is a failure of language (and social norms),
| and it has to be recognized by both the speaker and the
| listener before it can be accommodated.
| progmetaldev wrote:
| Only if you work at a company that values their developers, and
| sees the value in improving the software. Some companies will
| say "good enough" and concentrate on other things, like new
| features, rather than performance or security issues. I'm not
| saying that's right, just how businesses see development.
| j1elo wrote:
| 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.
| sockgrant wrote:
| Yeah 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 wrote:
| I 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.
| mjr00 wrote:
| But 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.
| dylan604 wrote:
| I 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 wrote:
| Discord's never had major performance problems for me, at
| least compared to anything else like Skype.
| mjr00 wrote:
| Of 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.
| dylan604 wrote:
| WARNING: PERSONAL OPINIONS AHEAD!!!
|
| If you're a company with a $27b valuation releasing an
| Electron app, then you're just a shite company. How do
| you have any self respect at that point. I get being a
| small team without subject experts in native apps and
| just need to get something going. If you are a $27b
| valuation small company we might continue the is Electron
| still the right choice conversation. I'd also be very
| curios what your app is doing that a small team can
| operate it and still be valued so highly. Otherwise,
| you're just a shite company making shite decisions and
| have no self respect.
| HalcyonicStorm wrote:
| While I agree with you in that we should have more native
| applications that are more conscious of how much
| resources they're using, making that transition from
| Electron to Native is probably not easy and riddled with
| pitfalls. Unless there's a standard path, how do you sell
| that to your superiors in the company in terms of
| opportunity cost?
| progmetaldev wrote:
| Would they have gotten there if they started off native?
| Most definitely it would have taken longer to get to
| market. If they were to rewrite as a native app, then
| they would need to at least keep the same features their
| current user base are used to. Then you're going to start
| all over with new bugs being found.
| dylan604 wrote:
| when slack started off, were they a $27b valuation
| company? no, they were smaller and yes, needed something
| to get to MVP for getting there. you're saying that after
| reaching the point of receiving a $27b valuation that
| they can not afford to hire subject matter experts into
| delivering a much better tool than the bloated PoC
| released as a product? seriously?
| JohnFen wrote:
| Sure, they could, but if they're making money on a
| substandard implementation, then why would they bother
| making a good one?
|
| This sort of thing is another example of our collective
| race to the bottom.
| progmetaldev wrote:
| One, a valuation is just that, a value of the company.
| Not the company holdings. Also, that doesn't address that
| a rewrite comes with stalled features (often), as well as
| new bugs introduced. How much of a business value is
| there in that rewrite? We're talking about a business.
| These are tools that are usually forced upon people by
| management, and if it works but is a little slow or
| taking large amounts of memory, management will either do
| nothing because they got a discount or upgrade machines.
| At the end of the day, for most it's "good enough".
|
| To be clear, I'm not saying that a developer culture
| shouldn't strive for this, but these are large businesses
| and are out for that dollar, and neither seem to be run
| by developers that would call for a rewrite.
| manmal wrote:
| They could just allow the iOS app to be used on macOS
| (Apple Silicon), I'd happily use that. But for some
| reason, they don't.
| coldtea wrote:
| Based on that their iOS app isn't just a shell for a web
| view?
| Jtsummers wrote:
| > But for some reason, they don't.
|
| It's not that complicated. That's a new-ish capability
| and was not an option when the apps being discussed chose
| Electron (for their desktop incarnations). It's also not
| applicable to all macOS systems (as you already noted)
| out there given that it requires M1-M3 Apple devices.
| They'd still need to support the older macOS systems
| while also working out the issues on newer systems. Or
| they could maintain one solution that works on both.
| dasil003 wrote:
| If it makes you feel better to unilaterally condemn
| decision makers at big companies for not hewing to your
| priorities, then be my guest, it's a fun past-time.
|
| However if you're interested in why this happens you need
| to acknowledge there are legitimate tradeoffs between
| going full native and Electron at any scale.
| Specifically, feature/UI parity and speed of development
| is higher with Electron. Deciding to retool your whole
| engineering org to optimize for highly polished native
| apps is actually a pretty risky decision once you get
| into this position at scale, regardless of how much
| engineering cred it generates HN and other highly
| technical/UX focused circles.
| JohnFen wrote:
| This reads to me like "at a certain scale, it's too risky
| to develop an application that is actually good."
| progmetaldev wrote:
| I'm in complete agreement here. These are businesses, and
| are not run by development teams. Sure, the developers
| could leave because they don't believe in the ethics of
| the business, but they they are going to get more
| Electron developers.
|
| For most people, the software is "good enough." That
| doesn't mean that it's engineered in the best way
| possible. That just means that the business concentrates
| on other concerns (some simply about gaining more market
| share and profit).
|
| I'm always in pursuit to write the best quality code that
| I can, with performance in mind. I also work for a small
| software company where I have that luxury, and also the
| drive to practice outside of my salaried hours (because I
| enjoy it, not because I feel I need to). I would feel
| terrible if my clients were complaining about slow
| performance, and I would find a solution that works
| within my constraints of having other client work to
| perform. Not having to support thousands or millions of
| users with my software makes it a lot easier to work on a
| rewrite than needing to worry about every operating
| system and configuration that is out there, along with
| new bug reports that need to be addressed.
| trobor wrote:
| Electron is an established technology, offers acceptable
| performance for most users and doesn't - for the most
| part - require specific technical skills. You basically
| webdev with it and have a native looking app.
|
| Those could - but don't have to be - valid arguments for
| using it while still retaining self respect, e.g. making
| an informed choice on what is best for the project one is
| working on.
| dylan604 wrote:
| Is app development only a 2 party system: native vs
| Electron? You seem to imply that it is. I disagree.
| coldtea wrote:
| > _You basically webdev with it and have a native looking
| app._
|
| That's a description of the problem.
| alpaca128 wrote:
| > offers acceptable performance for most users
|
| Most users accept it because they have no better choice.
| If an app is terribly slow but a lot of online
| communities and friends use it, what are they gonna do,
| just not interact with others? You want to play recent
| Nintendo games but don't want to regularly replace the
| controllers due to an unfixed issue that affects roughly
| 50 million people and has a perfectly working solution
| for over 20 years? Too bad. But I guess Nintendo calls it
| acceptable for most users because it's not quite bad
| enough that people stop using a product they paid for.
| pixl97 wrote:
| Let's reverse the comparison....
|
| How many companies have $27billion+ valuation and are not
| 'shite' software companies?
|
| I'm just wondering about this, because almost all the big
| companies I know write shite software... in fact it seems
| has nothing to do with how 'shite' your application is,
| but if it has the features the users want.
|
| Is there a reverse correlation? That if you're an
| investor you should shy away from companies writing 'non-
| shite' software because they aren't focusing on
| deliveries?
| justinclift wrote:
| > How do you have any self respect at that point.
|
| Because they have CFOs and other bean counters at that
| point, and there's just no good way to convince those
| people to approve spinning up new teams (or reskilling
| the existing one) to rewrite the application "properly"
| across several platforms.
|
| It's like comparing "$$$ for new feature development"
| (will move us forward) with "$$$ for rewriting the
| application to be more efficient" (with uncertain
| benefits).
| JohnFen wrote:
| I 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 wrote:
| I 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.
| marcosdumay wrote:
| If 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.
| uuddlrlrbaba wrote:
| Because 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 wrote:
| +1
| yashap wrote:
| Agreed, 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 wrote:
| https://www.rhysmills.com/post/2023/02/10/a11y-isnt-
| accessib...
| NooneAtAll3 wrote:
| finally I can express my opinion by linking to someone
| else's
|
| thank you
|
| I hate "ally" thing so much >_<
| justinclift wrote:
| For 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. :/
| PH95VuimJjqBqy wrote:
| Electron is only good enough because the companies themselves
| aren't paying the cost of it (resources and performance).
|
| what gets considered important are things that hurt them
| rather than their users. In many ways it's an abuse of users.
| stouset wrote:
| 100%.
|
| "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 wrote:
| To 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 wrote:
| Reality: 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.
| roenxi wrote:
| "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_ wrote:
| People 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 wrote:
| On 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 wrote:
| I hate to break it to you, some things are _good enough_.
| hoten wrote:
| 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. 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 wrote:
| > _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 wrote:
| No, I said different words than that. Maybe my edit
| clarified.
| coldtea wrote:
| I 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.
| ctvo wrote:
| 1-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 wrote:
| Nothing is more permanent than a temporary solution.
| JohnFen wrote:
| > 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 wrote:
| Always 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 wrote:
| All 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 wrote:
| In 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.
| aimonster2 wrote:
| 0. Don't tell your manager/customer that you first did it or
| there will be no do it right and do it better!
| ChrisArchitect wrote:
| Original posts:
|
| https://twitter.com/addyosmani/status/1739052802314539371
|
| https://addyo.substack.com/p/first-do-it-then-do-it-right-th...
| danielovichdk wrote:
| Fred Brooks. The Mythical Man Month. 1975.
|
| Chapter 11. Plan to Throw One Away.
| dws wrote:
| "This I now perceived to be wrong, not because it is too
| radical, but because it is too simplistic. The biggest mistake
| in the 'Build one to throw away' concept is that it implicitly
| assumes the classical sequential or waterfall model of software
| construction." -- The Mythical Man-Month, 20th Anniversary
| Edition, pg. 265
| tuanx5 wrote:
| A similar phrasing I've internalized is "Make it boring (stable,
| predictable) or make it better"
| OhMeadhbh wrote:
| I used to have a poster on my wall at my office at Borland that
| said:
|
| DO IT. DO IT RIGHT. DO IT RIGHT NOW.
|
| I interpreted it as "start by writing a test or some code. make
| sure the code gives you correct results. only then, when the code
| generates correct results do you jump in and optimize," which is
| pretty close to the OP's message.
| hartator wrote:
| > First do it
|
| Sounds like your codebase will be full of shitty half-backed
| half-non-needed "features" with a lot bugs, legacy, and
| misdirection.
|
| > then do it right
|
| Sounds like your codebase will have a lot of hyped, now-dead,
| trends-of-the-moment frameworks while your team keeps arguing
| what's "right".
|
| > then do it better
|
| Sounds like your codebase will have a lot of rewrite in the new
| hyped, not-yet-dead, trends-of-the-moment frameworks while actual
| business logic will be ignored.
|
| In my experience, this is the worst advice if we are talking
| about software engineering. I would advise the opposite: "Is this
| needed? really needed? nerd out on why it's needed."
| cj wrote:
| Considering the failure rate of startups (assuming we're
| applying the advice in that context), you shouldn't be worried
| about rewriting your codebase or using a hyped framework that
| will be outdated in 5 years because chances are (statistically)
| your startup won't exist in 5 years.
|
| The opposite advice has merit, but you can't take it to the
| extreme. Better to build a MVP in 1 month than to spend 6
| months doing user research and then another 6 months building a
| MVP with perfectly performant and optimized code
| codekaze wrote:
| Seriously, throwing shade at the 'launch fast, iterate fast'
| mantra is like saying the Wright brothers should have aimed for
| a Boeing 747 on their first go. The beauty of the MVP approach
| isn't in launching with a pile of 'shitty half-backed
| features.' It's about getting it in the hands of real users as
| quickly as possible so that you can start to iterate.
| stillbourne wrote:
| >> First do it
|
| POC code doesn't belong as a permanent codebase.
|
| >> then do it right
|
| > Sounds like your codebase will have a lot of hyped, now-dead,
| trends-of-the-moment frameworks while your team keeps arguing
| what's "right".
|
| Doing it right should include a framework. I'd rather use a
| framework that is dead in a month than write 10s of 1000s lines
| of boilerplate to make my own. ASP.NET and Spring come to mind
| as modern reliable frameworks. Even angular is reliable even if
| not popular.
|
| >> then do it better
|
| > Sounds like your codebase will have a lot of rewrite in the
| new hyped, now-yet-dead, trends-of-the-moment frameworks while
| actual business logic will be ignored.
|
| Code should be considered disposable when it has outlived its
| usefulness. Even if that requires a rewrite. I've maintained
| classic asp websites and I have rewritten them in modern
| frameworks. Projects are not immutable. They are only as useful
| as they are until they are not. Then they die or get rewritten.
| pixl97 wrote:
| >I would advise the opposite: "Is this needed? really needed?
| nerd out on why it's needed."
|
| In almost every company I've seen "Is this needed" is always
| followed up by some c-level saying "Of course it fucking is,
| we've sold the product for $X million to $Y company and now we
| need that feature working"
|
| HN has a fair number of commenters that live in a dream world
| where they get to implement the features they choose, but for
| the _vast_ majority of programmers it 's going to be the
| features _sales_ chose.
| stillbourne wrote:
| This has been one of my mantras since I started as a software
| developer.
| dang wrote:
| Url changed from
| https://nitter.cz/addyosmani/status/1739052802314539371, which
| points to this.
|
| It's fine to post workaround URLs in the comments, but please
| don't make them top-level links.
| from-nibly wrote:
| My teacher always said it like this. "Make it work. Make it
| right. Make it fast".
| johnea wrote:
| I've seen it as this:
|
| 1) The first time, get it done the most expeditious way 2) The
| second time, do the way you wished you'd done it the first time
| 3) The third time, automate it...
| yamrzou wrote:
| 1. First make it possible
|
| 2. Then make it beautiful
|
| 3. Then make it fast
|
| 4. Rinse and repeat
|
| Suffering-oriented programming (2012) --
| http://nathanmarz.com/blog/suffering-oriented-programming.ht...
| heresie-dabord wrote:
| Variant:
|
| Listen to the customer so you CAN:
|
| -- Make it fit for purpose.
|
| -- Make it fit for use.
|
| If the above fails,
|
| -- Make it fit for marketing.
|
| -- Make three envelopes.[1]
|
| [1] _ https://news.ycombinator.com/item?id=38725206
| rad_gruchalski wrote:
| Wow, haven't seen this name mentioned in years. Apache Storm
| was a great tool at the time. Good memories.
| lysecret wrote:
| I love that we all have our own version of this saying! Here is
| mine (my dad practically raised me with this haha)
|
| Make it run, make it right, make it fast (if you have to).
| thomastjeffery wrote:
| This is my greatest weakness, and it has a name: executive
| dysfunction. Well, that's the _descriptive_ one.. The technically
| correct - and therefore useful - name is ADHD.
|
| Because I have lived so much of my life generally _unable_ to
| "Just Start Somewhere", I've given the concept a lot of thought,
| and a lot of criticism. I can see my bias clearly today, but I'm
| still not convinced that my criticisms were ever _wrong_.
|
| --
|
| What's the value in doing something? Is it the doing, or the
| something?
|
| If the value is in the doing, then there is no value in progress.
| That's obviously untrue.
|
| If the value is in the something, then where is the doing to make
| that something in the first place? Clearly, some doing is
| necessary, too.
|
| I find that the true value of "doing something" lies in the
| connection between the two. Their interdependence creates
| _structure_. By doing, we build something into something more. As
| a result of the expansion of something, we are better equipped
| for more doing.
|
| --
|
| But what if something could _do itself_? To me, this is the
| ultimate dream of software: the limitless potential of a
| _something that does_. The more time I have spent obsessing over
| this system, the more I have seen the world of software go in the
| other direction.
|
| The problem lies in our goals. What is it that we desire to do?
| What is the something that will get us there? These are obvious
| questions with an obvious answer: application. An application is
| the kind of something that takes us directly to our desires.
| There's one problem with that system: every application must be
| constructed with the same process of doing. There is just enough
| of a platform for this to work, so everyone who is comfortable
| with "just doing the thing" can build an application, and be on
| their merry way.
|
| The platform itself was made with this very category of goal in
| mind. Our foundations are constrained to a single design pattern:
| applications. This was not always the case.
|
| --
|
| Once upon a time, we had scripts. Technically, they are still
| here, but this platform is showing its age. Much like a human's
| ears, there are some features of the script platform that will
| never stop growing. New languages. New toolchains. New protocols.
| The more somethings we build onto script, the more unbalanced the
| overall platform gets. This is the problem that the application
| platform avoids.
|
| But how? There are a few valuable weaknesses that application
| provides:
|
| - Applications are weakly interconnected. If you don't need one,
| you can simply leave it behind. There is no need to cut it out,
| because it was never built in.
|
| - Applications are redundant. An application has all of its doing
| built-in. This allows its UI/UX to be coherent, because it is
| free to define the doing in its own terms.
|
| - Applications are independent. If an application depends on
| another application, that dependency is explicit, and can be
| easily managed. Dependencies can be swapped out with minimal
| work.
|
| As valuable as each of these are, a weakness is a weakness. They
| haven't stopped the world of software from reaching incredible
| goals; but they have been enough to stop me.
|
| --
|
| Is this the end? Is application the final penultimate platform?
| I'm not convinced. I think we can do better. I think we have
| everything we need to create a new platform. This new platform
| can contain the strengths of _both_ script and application. I
| have a mostly-coherent idea in mind: I call it the story
| empathizer.
|
| Now I just need to start building it...
| egotripper wrote:
| The criteria for an effective release tends to be more prickly
| when deployed to a million users and, to certain companies, a
| million users is a tiny audience. Know your audience.
| puttycat wrote:
| https://nitter.net/addyosmani/status/1739052802314539371
| lionkor wrote:
| I've been fixing "this is just a prototype" code for most of my
| professional life. Dont do that. Write good code, dont write
| shitty code and promise youll fix it -- you wont.
|
| What this ends up looking like is really:
|
| - write shitty code with the excuse that you could do better, and
| youll fix it later
|
| - fix it up later by tacking on dirty fixes and removing good
| code others added to fix specific problem (ignoring chestertons
| fence)
|
| - then get tired and rewrite it entirely, throwing away all
| progress. Except for the parts where you just copy paste your old
| shit because everyone forgot how it works
___________________________________________________________________
(page generated 2024-01-02 23:01 UTC)