Reject original specs. Do the bare minimum MVP that works and solves problems people actually have, and not problems you think people have.
Improve it if needed.

In my experience, software projects don’t live long enough to outgrow the MVP. If they do, it happens way down the road. At that point, business will change, and the original spec will become irrelevant.

It’s a paradox: 90% of the spec was discarded, but the business is happier than if we followed the spec word by word.

Also, static typing and unit testing solve nothing. I’m sorry.

Unit testing is a chore but dynamic typing is a bitch. Creates all sorts of problems in runtime and hard to compile time check.

Unit testing caught me more than one bug already, especially on very unspecific edge cases. But i still hate it.

Don't worry, the AI will keep humans around to perform useful duties - they'll just blend in as other humans, so we won't notice the overthrow.

What's your testing + defined data type trauma @kiki?

Unit testing solves some of the problems. Of course only when done correctly and not just "for the sake of it", hunting coverage percentage.

Static typing and compile time checks in general solves a lot of problems. Again, if done correctly. It‘s not enough to just slap TS on top of JS and force devs who hate it, to use types.

Gotta love MVPs

oh my god, how did they launch spacecraft with… w… with LISP? But types! Are they crazy? Dynamic typing bad! It's unreliable! H… how?

@aviophile yh, in theory a lot of tests could be just generated. Also for overflow checking e.d.

@Katakompe I consider unit tests a break.

@herringbur already happened and you noticed nothing indeed.

@Bibbit I have a friend who started a company only doing that - so always only the rum stuff. Genius

@kiki do you like dynamic types?

@retoor if you know how to structure your code, dynamic types is all you need. Neither static types nor unit tests can catch everything. The only thing they can do is to provide a false sense of security.

No automated solution can save your sloppy code if you're not paying attention. If you are, you don't need those solutions.

@kiki I agree that automatically generated unit tests are mostly useless in strictly typed compiled languages. They are more useful for dynamic stuff, though.

And of course it‘s true that unit tests and static types can‘t catch everything. But it can catch a lot of stuff. More than you think. Depends on the language though.
This alone is a huge benefit.

I rather get 90% of bugs catched at compile time and 5% by unit tests than none of them.

@kiki nice answer. I'm working for a while on interpreter in C but saw a guy on YouTube writing a whole programming language doing so much beautiful stuff you could never do in C. He was also explaining the theory behind it and it was clear he really knew what he's doing. Python and C both are my favorite and now implementing Lua in an editor. That editor is thousand lines of C and it's beautiful so I decided to extend it with Lua support to add functionality and leaving the editor original and clean. Only added some hooks in main method. Lua is so f-ing clean codebase. Very yagni && kiss

It's mostly confirmation bias at this point. No one really tracks how many bugs they had before unit tests vs after, or how much time they spent on those bugs vs on writing tests. No one tracks how many times they got false errors from unit tests. But everyone notices when a test catches some edge case, because that's what they're expecting to happen with unit tests.

@kiki in my opinion (well-written) unit tests allow you to validate whether a function on its own does what you would expect it to do. Like the very basic confirmation you would want.
This allows you to think about actually complex stuff which is, as you highlight, harder or sometimes even impossible to validate using something like unit tests.

@Bibbit I have a degree. I also did TDD professionally. I know how it works.

That said, I can say with confidence that for me both static typing and unit tests are redundant at best, pointless and harmful at worst. On one hand, me not needing them shouldn't be the reason you abandon them too. On the other hand, my code was regarded by many to be quite unorthodox.

The scope of my work is very limited (mostly web stuff, frontend and backend). I don't write interpreters and compilers professionally. Maybe that explains it.

@kiki yeah very true that there are various cases where TDD is not as useful as advertised for some other use cases.

Never assumed you wouldn't know what you're talking about btw ;) Just wanted to share my personal opinion/experience with tests.

I am curious what your unorthodox code would look like though... Never experienced something being called that lol

It’s not like you have to commit to full TDD or no unit tests at all.
The best way is always something in between. Apply some unit tests only where it makes sense.

@Lensflare committing is something you do with one os and nothing else

@retoor I don’t even commit on one os ^^

@Lensflare Slut

I agree. New projects begin with tons of planned bonus features but once the MVP is launched that often ends up being good enough.

The problem is there's rarely any user research done after the launch of a decent MVP to find out if it should evolve further in some direction.

Teams love to act agile as if the MVP is just a first step and analytics or user research will drive the next step, but most of the time there's no second step unless it's a huge flop or huge hit. (Maybe that's OK)

When working in a team with a limited budget, I’d say they are quite useful. Of course, geniuses such as myself do not need them because we are as close to perfect as one can be, but I am happy the plebeians can use them sometimes.

Very nice write-up!!!
Stil disagree on the last sentence but that's all right. I know we will never see eye to eye on some subjects.
I do wonder; are you completely against all automated tests?

@Bibbit @Bibbit @hitko @Katakompe flip the pyramid, just do end-to-end/integration tests mostly. That will verify everything is actually working (and not just with all the crap fakes and mocks). Only do unit tests for complex logic heavy code that is easier to test directly and likely to contain mistakes. Those unit tests should read as documentation and help locate high level test breakage, nothing more.
TDD and other testing gurus focus on a slew of unit tests and that is just a lot of work and stupid.
I've seen codebases that maintained ±20% of tests for nice edge cases that can't ever be hit (because the code isn't used at all or not able to be called that way).

I think unit tests are often a bit of a time waste of time compared to e2e tests (like starting the app, mocking apis and asserting rendered html)

Most problems I find are I'm between units. My formatter unit works great but I forgot to use it in a few places in my view, or chained it together with something in the wrong order.

I do use some unit tests for complex units which have historically proven to be tricky or have lots of edge cases.

But gotta say the mantra "Tests work as documentation" is a lie. It might to test fanatics. But not to others. The new guy is not gonna read your large test suite full of edge cases as an introduction to the codebase. And when he finds a weird function he's probably not even gonna notice it's covered by a test. (cause the test is usually somewhere else)

Can’t agree more.
Unpopular opinion tho.

But u need the mvp to bring investors even if by the time they come codebase is basically outdated and many new features ideas have already popped.
What’s the most frustrating is when the investor come and decide to change the market target and the whole think must be recomcieved from scratch.