First do it, then do it right, then do it better

https://twitter.com/addyosmani/status/1739052802314539371

by erfanebrahimnia • 3 years ago

205 137 3 years ago

twitter.com

JadoJodo• 3 years ago

I love this saying, though I always heard it as a more SE-specific addage: Make it work, make it right, make it fast.

nwienert2• 3 years ago

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.

Tallain2• 3 years ago

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.

Jtsummers2• 3 years ago

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• 3 years ago

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• 3 years ago

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.

rogerkirkness2• 3 years ago

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• 3 years ago

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.

rogerkirkness2• 3 years ago

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• 3 years ago

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• 3 years ago

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• 3 years ago

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.

atum472• 3 years ago

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• 3 years ago

I agree. I call it “something to throw stones at”.

thomastjeffery2• 3 years ago

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.

progmetaldev6• 3 years ago

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.

3abiton• 3 years ago

Failure is the first step of success. There was a thread few days ago about it.

atum472• 3 years ago

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.

j1elo2• 3 years 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.

sockgrant3• 3 years ago

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• 3 years ago

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.

yokoprime• 3 years ago

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.

mjr002• 3 years ago

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.

dylan6045• 3 years ago

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.

JohnFen5• 3 years ago

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.

myaccountonhn2• 3 years ago

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.

TeeWEE• 3 years ago

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.

M95D• 3 years ago

nobody cares.

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.

marcosdumay• 3 years ago

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• 3 years ago

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• 3 years ago

yashap3• 3 years ago

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.

PH95VuimJjqBqy2• 3 years ago

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.

stouset2• 3 years ago

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• 3 years ago

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.

roenxi• 3 years 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_• 3 years ago

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.

rubyfan• 3 years ago

I hate to break it to you, some things are good enough.

hoten2• 3 years 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. 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.

coldtea5• 3 years 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".

ctvo• 3 years ago

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?

hinkley2• 3 years ago

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.

treprinum• 3 years ago

Nothing is more permanent than a temporary solution.

JohnFen5• 3 years 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• 3 years ago

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!

sanderjd2• 3 years ago

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.

satvikpendem5• 3 years ago

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.

hinkley2• 3 years ago

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.

myaccountonhn2• 3 years ago

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.

cryptonector• 3 years ago

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.

aimonster2• 3 years ago

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• 3 years ago

Original posts:

https://twitter.com/addyosmani/status/1739052802314539371

https://addyo.substack.com/p/first-do-it-then-do-it-right-th...

danielovichdk• 3 years ago

Fred Brooks. The Mythical Man Month. 1975.

Chapter 11. Plan to Throw One Away.

dws• 3 years ago

"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

OhMeadhbh2• 3 years ago

For a book that was written in the 70s, MMM still has a lot of wisdom.

tuanx5• 3 years ago

A similar phrasing I've internalized is "Make it boring (stable, predictable) or make it better"

OhMeadhbh2• 3 years ago

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• 3 years ago

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• 3 years ago

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• 3 years ago

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.

stillbourne2• 3 years ago

> 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.

pixl973• 3 years ago

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.

stillbourne2• 3 years ago

This has been one of my mantras since I started as a software developer.

dang• 3 years ago

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• 3 years ago

My teacher always said it like this. "Make it work. Make it right. Make it fast".

johnea• 3 years ago

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• 3 years ago

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• 3 years ago

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• 3 years ago

Wow, haven’t seen this name mentioned in years. Apache Storm was a great tool at the time. Good memories.

lysecret• 3 years ago

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).

thomastjeffery2• 3 years ago

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• 3 years ago

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• 3 years ago

https://nitter.net/addyosmani/status/1739052802314539371

lionkor• 3 years ago

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

sanderjd2• 3 years ago

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.

ramijames• 3 years ago

I just wrote a similar article called "Iterate relentlessly" which covers much of the same ground.

It's here if you're interested: https://www.ramijames.com/thoughts/iterate-relentlessly

anyonecancode• 3 years ago

I think it's hard to jump straight to "do it right" as step 1, because it's often not actually clear what "right" means until you actually have running code. Editing is easier than writing. Few essays, books, or software projects can skip having at least a first draft.

There are two problems that tend to keep much software in what is essentially the "draft" stage, though. One, articulated by many on this thread, is that business incentives really push to "if it's working well enough, it's working well enough." And as some have noted, that's not necessarily a problem! We're, most of us, writing software for pay here, not for fun or personal expression. But! As engineers, we have more insight into if it's really working "well enough" (assuming that we, as engineers, have also taken the time to make sure we understand the product we're building). Things like performance, security, and maintainability are part of making sure it's "good enough," but our non-technical partners and stakeholders can't necessarily see this, and part of our role is to help them see this so that they are making truly informed decisions on if it really is "good enough."

Second, and I feel bad saying this, there's often a dearth of widespread technical ability to actually take code from "ok" to "good." I don't mean this in an elitist way of saying some programmers are just better than others -- I do truly believe that with proper support and mentoring almost anyone who wants to become a better programmer can (see my user name). But I think that as an industry, we actually do a poor job helping our colleagues advance and deepen their skill. The ratio of skilled programmers to new is too small, and of skilled programmers with ability and inclination to level up their junior colleagues even smaller.

That's a decision by business leaders, who by and large have decided that junior-heavy, cheaper dev teams are "good enough."

First do it, then do it right, then do it better

Related Stories