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.
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.
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.
I 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.
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.
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.
Most people don't actually know any better, to be able to care. That includes not just normal users, but programmers, web admins, team leaders and managers too.
They never had to unload a TSR because there wasn't enough conventional DOS memory available. They never used Win3.10, where even the button light/shadow colors could be changed, yet fit into 1 MB RAM and 20 MB disk. They never browsed via 3KB/s dialup. Many never saw a website 1.0 without JS. Of them 99.999% never saw a 64K intro/demo. They don't know it's possible.
> If people did care, you'd have someone writing a highly optimized chat/voip app from the ground up
That does happen, rarely, and even then, it doesn't change the situation.
1) Very very few people are capable of writing apps. Out of them, very very few are capable of writing apps, optimized or not, that don't import the entire internet as a dependency. That's because that's how they were educated: "don't waste time rewriting code", "you'll repeat the mistakes", and other BS arguments that lead to nodejs and other monstrosities.
2) Those very few people are the same ones that actually wrote Discord, Slack, Teams. Most of them want to finish quickly and jump ASAP to the next big fancy project that caught their interest. So they import the entire internet as a dependency instead of writing again a 2-line function. These are the people that didn't care.
You won't see anymore people like Christian Ghisler who write and maintain some piece of software for their entire life.
3) Someone recently wrote a Windows terminal app faster, smaller, better than the official, just as a tech demo. Most people (99%) won't find out about it. I'm sure there are Teams alternatives. Nobody finds out about them because Google and M$ control what everyone sees.
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.
For companies selling hardware with software it does matter. Look at Apple. An iPhone has way less memory than an android and the profit margins are higher for Apple. Apps are running faster on lower hardware. I’d argue that this is a reason why people want iPhone. Good enough is often not good enough.
It’s extremely wasteful, people buying new phones because their calendar or slack app are sluggish on their 5 year old phone is insane to me. It’s so bad for the environment.
“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.
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.
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.
The Last Responsible Moment matters tremendously for the things that you 'have to get right' as well, and people who "need closure" can complect such negotiations.
If the problem is hard, you have to start thinking about it early. But every day you've thought about it a little without committing, you have a little more information about how it'll feel to take each path, and how it's likely to affect your operations people and customers.
Also Observation Bias may cause you to read that one article that explains why one of the choices seems like a good idea but is a trap. Or why you definitely should or should not use the latest major version, because of some change for the better or worse.
Frustratingly, some people see any discussions about such things as non sequiturs, distracting them from today's problems.
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?
>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".
> 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.
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!
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.
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.
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.
Another 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.
My 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.
It'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.
"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.
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.
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.
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.
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.
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.
I didn't mean failure per se. My case for instance: I've spent the last year building a house for myself. It was a lot of work. Sure it's easy for some people (my older brother) to come over and say things like "this part here could've been better". Well, of course it could have. But if i were to overthink every single piece of it, I'd still be living in my old apartment.
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."
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.
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
> 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.
>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.
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.
> 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.
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).
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.
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.
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.
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
See, I share your experience of spending most of my time improving things that aren't great, but I see it as a good thing. A full two thirds of "do it, do it right, do it better" is about making improvements to something that is already working and useful.
Sure, there is some inefficiency in re-doing already-working things to improve them, but in my view, less so than in spending more time creating a more perfect thing, but which is often the wrong solution or a solution to the wrong problem altogether.
If it were possible to perfectly know that you are creating the definite right solution to the definite right problem, then sure, go nuts! But in the real world this is essentially never the case, so it is better to first "do it", then if that "it" turns out to be useful, to "do it right", and then since that still inevitably won't actually be "right", to "do it better", and then to "do it better" again and again, until "it" is no longer useful.
Readit News
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.
Optimizing as step one is a very good way to not ship on time and miss opportunities to competition.
what gets considered important are things that hurt them rather than their users. In many ways it's an abuse of users.
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.
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.
I don't agree.
Most people don't actually know any better, to be able to care. That includes not just normal users, but programmers, web admins, team leaders and managers too.
They never had to unload a TSR because there wasn't enough conventional DOS memory available. They never used Win3.10, where even the button light/shadow colors could be changed, yet fit into 1 MB RAM and 20 MB disk. They never browsed via 3KB/s dialup. Many never saw a website 1.0 without JS. Of them 99.999% never saw a 64K intro/demo. They don't know it's possible.
> If people did care, you'd have someone writing a highly optimized chat/voip app from the ground up
That does happen, rarely, and even then, it doesn't change the situation.
1) Very very few people are capable of writing apps. Out of them, very very few are capable of writing apps, optimized or not, that don't import the entire internet as a dependency. That's because that's how they were educated: "don't waste time rewriting code", "you'll repeat the mistakes", and other BS arguments that lead to nodejs and other monstrosities.
2) Those very few people are the same ones that actually wrote Discord, Slack, Teams. Most of them want to finish quickly and jump ASAP to the next big fancy project that caught their interest. So they import the entire internet as a dependency instead of writing again a 2-line function. These are the people that didn't care.
You won't see anymore people like Christian Ghisler who write and maintain some piece of software for their entire life.
3) Someone recently wrote a Windows terminal app faster, smaller, better than the official, just as a tech demo. Most people (99%) won't find out about it. I'm sure there are Teams alternatives. Nobody finds out about them because Google and M$ control what everyone sees.
“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.
If the problem is hard, you have to start thinking about it early. But every day you've thought about it a little without committing, you have a little more information about how it'll feel to take each path, and how it's likely to affect your operations people and customers.
Also Observation Bias may cause you to read that one article that explains why one of the choices seems like a good idea but is a trap. Or why you definitely should or should not use the latest major version, because of some change for the better or worse.
Frustratingly, some people see any discussions about such things as non sequiturs, distracting them from today's problems.
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?
So he basically says "It will either rain, or it will not rain".
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.
In both cases if originally building in Electron was a substantial productivity boost then it sounds like it was the right choice.
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.
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.
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.
Deleted Comment
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.
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.
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...
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
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."
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
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.
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.
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.
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.
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.
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.
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
Sure, there is some inefficiency in re-doing already-working things to improve them, but in my view, less so than in spending more time creating a more perfect thing, but which is often the wrong solution or a solution to the wrong problem altogether.
If it were possible to perfectly know that you are creating the definite right solution to the definite right problem, then sure, go nuts! But in the real world this is essentially never the case, so it is better to first "do it", then if that "it" turns out to be useful, to "do it right", and then since that still inevitably won't actually be "right", to "do it better", and then to "do it better" again and again, until "it" is no longer useful.