[mvonballmo]

From the retrospective.

> And yet I do know that you can write complex, relatively bug free code without tests, because I did it.

> I do know that you can write complex, relatively bug free code without anyone looking over your code, because I did it.

> If no one uses your app then who cares if it crashes.

> If many people use your app and it crashes, they’ll tell you and then you’ll fix it.

Those four statements are contradictory. What they're saying is not that you don't need testing or code reviews, but that you can get your users to test for you.

I figure the author probably does test their code (everybody tests, even if that just means running the app), but not rigorously or in a way that you could say gives one the security of regression tests.

No-one worth discussing the issue with claims that it's impossible to write complex code without automated testing. I'm a huge proponent of automated testing, and I wrote a relatively large, cross-platform renderer without a single automated test back in the late 90s/early 00s ... it just took a long time, and I became increasingly terrified of making changes.

Edited for formatting.

[kjksf]

(I wrote that blog post).

What I was trying to say is: there's dogma about tests and code reviews.

At Google you would get fired for suggesting skipping code review.

Even at smaller Silicon Valley companies (smaller == less than 10 devs) it's unthinkable to not do code reviews. I haven't worked outside SV so it might be different.

That's the dogma.

My point is that maybe we should apply a bit of common sense on top of that.

I'm not saying Google should stop doing code reviews - the cost (to Google) of google search breaking is so high that you do 100x more than just code reviews.

But maybe those smaller companies don't need to dogmatically review the checkin for a documentation fix.

[VHRanger]

The problem with tests is the TDD dogma, which wastes time and makes code harder to change (because even reasonable changes break a bunch of tests).

There's a good rule of testing top level behaviors described in this talk [1]

For code reviews, it's about knowledge handoff. No one disputes you can write great code alone. The problem is that singular geniuses writing functional but unmaintainable code only they understand and then getting hit by a bus or changing jobs is a real issue.

1. https://m.youtube.com/watch?v=EZ05e7EMOLM

[RNAlfons]

I work in Health IT here in Germany and for the past 3 years we've been "testing" those "smaller companies" for different parts of our business.

It's a mess. We've been paying them serious money for a product. We've never been warned that their product isn't finished yet or that we're the beta testers for the product they'll sell to other clients. Or that we have to invest our own personal and their time to fix their problems and talk to their useless support.

This has become a pattern and I'm done with it. We are slowly moving back to older and larger companies who actually do their work properly before they roll out products and updates.

[wolverine876]

> My point is that maybe we should apply a bit of common sense on top of that.

...

> But maybe those smaller companies don't need to dogmatically review the checkin for a documentation fix.

It's not dogma, it's just the necessities of large groups of people working together. A small organization can use common sense, a function that scales up to (20? 50?). 10,000 people can't operate on common sense; they need another function: rules.

[wg0]

Now I'm ready for massive downvotes here but hear me out.

Much of our professional habits are part of the corporate chains which is optimised to deliver and squeeze as much as possible.

Software developed in the wild does not have those corporate obligations and the sole purpose is to enjoy the process, the sheer joy of creating something. Of programming as a creative medium.

You don't get your paintings code reviewed. It's just that artistry. You like it, then you like it, end of the story, you're not playing for the gallery.

Corporate enslavement works differently. It has moved and distributed the part of the factory shift in charge to the dude sitting next to you, cleverly. Many are just complaining to make sure they're considered the quality sensitive cooperate loyals.

You two might like different pigments for the grass and he'll strike down your painting with a red ballpoint if not to his taste.

Happens to all of us and if not, wait for it.

Declaring a single boolean flag in a corporate environment might cost more then an hour to get to a consensus because one I-am-dffierent-I-care-too-much guy has some objection about some ambiguity in the flag name in some far future and has now swayed roughly half the team on his side.

That doesn't exist in open source. Open source is all about anti status quo. It is pure rebillion. It started that way, it is about hippies and naysayers. The very root of the GNU toolchain, Herd etc are probably there.

EDIT: Typos + corporate software development environment.

[al_be_back]

I'm with the author (op) on this, unless it's critical code, launching a buggy project that gets some use & feedback is way better than holding-on for perfection and face certain project failure.

seek forgiveness rather than permission - gets you launched - gets you better

[naasking]

> I became increasingly terrified of making changes.

That's the main value of automated tests.

[TehShrike]

I rarely feel like tests make it easier for me to make changes later. Types do give me that feeling pretty reliably, though.