[theshrike79]

When coding I have a rule: "first make it work, then make it pretty".

The MVP can be a complete spaghetti piece of crap, just make it work. When it works, you can iterate on making it elegant.

Oh, and if you work for a Corporation, don't tell them it's done when the crappy MVP finally works. You're still "working on it" if they ask.

Otherwise the spaghetti crap will end up in production.

[xvinci]

Except I've seen too many spaghetti code craps in production to actually recommend this. There is a plethora of reasons why colleagues (or even you) will end up not waiting until code is production ready (e.g.: A new nice task comes in which you'd rather work on, you get reassigned, you get sick and someone else has to finish, you get a great opportunity to show off and say "hey I'm already done no problem", a tester sees and tests the features and misinforms the customer, etc. etc.) I am not saying your code needs to be perfect and then you only notice the one great flaw which requires re-engineering after weeks of hard work. I am saying find a good (backed by TDD) middle ground of fast work and fitting into existing / designing a decent architecture.

My 2 cents only, and if you can make it work that's great. But I will never go ahead and recommend this to juniors or even younger seniors.

[dahauns]

As someone who otherwise works somewhat similar to OPs workflow, I have to agree. One golden rule for me: The "vomit draft" version cannot be your MVP. It is never Viable for production.

That said, TDD (with emphasis on driven) is no silver bullet either, especially when working that way - the tests are equally affected and I've seen enouph code bases where the initial test surface was so off compared to what was needed/sensible that it ended up being solely a hindrance and stifling to actual rework/refactor - with people ending up throwing it away and rewriting the tests from scratch, or worst case, simply setting them to be ignored on build.

[augustk]

  1. Make it work
  2. Make it right
  3. Make it performant (if too slow).

[qwerty1793]

  1. Make it work
  2. Make it understandable
  3. Make it performant (if too slow).

[Fell]

I disagree.

1. Make it work 2. Make it performant (always, but within reason) 3. Clean up your mess to prevent future mistakes

I claim that "if too slow" can't be judged because you almost never have the slowest possible target device.

[DSingularity]

I disagree with all of you.

Make it work. Then make it maintainable. Then polish it to make it more ideal.

When it works it can be spaghetti and lack testing and filled with hacks. After you make it maintainable it can still be less than ideal — some hacks here and there in leaf functions but things are localized and understandable and non-brittle (ie good testing coverage, design which has appropriate abstraction, refactors to promote test ability, no more spaghetti etc etc). Then in the final step you polish the stuff to gold (ie use better solutions or improve performance). It is the only way.

[MathMonkeyMan]

My teammate says he does this. Writes everything three times, and is careful not to let _anyone_ see the first two, lest somebody tell him it's "good enough."

[llm_sent_me]

My variation on this. Make it work then make it slightly less horrible.

[bdavis__]

Then repeat until you are proud of the work.

[red-iron-pine]

> Oh, and if you work for a Corporation, don't tell them it's done when the crappy MVP finally works. You're still "working on it" if they ask.

I would if I could, but schedules are schedules and stuff has to ship...