hdi

  Taking out a competitor is good for Slack, said Butterfield: “There’s fewer choices for people.”

Somewhat interesting but calling an old idea something catchy isn't really revolutionary.

The article makes a lot of assumptions like "In practice, most agree as most projects set the lower bound for coverage to around 80%". Most projects where, which industry, who are these 80% that agree? This is just taken out of thin air in this case. It might be true but should we take the author's word for it?

  There are also some psychological arguments. For 
  example, if you value unit-testability, you would prefer 
  a program design that is easier to test than a design 
  that is harder to test but is otherwise better, because 
  you know that you’ll spend a lot more time writing tests.

I think TDD, unit, integration and E2E testing works. How much of which to apply is entirely project and industry specific and it's up to teams to decide what testing strategy works best for them.

I completely agree and I think that if you take care of the people they will take care of each other (team). So when you've built a well oiled team that trusts each other the company benefits as well as they will be more productive and play well with each other.

I also am not an engineering manager.

I've been wondering about that for a while.

So far, I've not been able to find any examples of test architecture that follows those principles online or in my day job.

I've also been too lazy to do a side project and explore a more decoupled and scalable test suite. Maybe I should get off my arse and finally do it.

I've seen this happen in a previous job. It literally made all the top performers in the team leave.

Get off your high horse for few minutes.

High quality restaurants? Around Edinburgh the 'highest quality' restaurant offered is Pizza Express.

The problem I've seen come out of test after is complete implementations with 0 tests. People will just forget to do it!

Especially if working on few different areas of the code at the same time. And it happens often enough for it to be dangerous.

Another issue I've seen pop up is the amount of spaghetti you see when someone said "Screw the tests can do it after". You could or couldn't do it after, cos sometimes things are so coupled it's impossible to test in a meaningful way. This varies between developers of course, more junior people will be coupling things more.

One approach that has worked for me whenever I'm not quite sure how I am going to implement something is something like this.

- First, prototype your feature, go in and go mad, write 0 tests and just try and find out how you're going to build it. - Then, stash it all away, wipe your workspace clean and start with tests. I've found this works for me when I'm not quite sure how I'm going to piece something new together.

the developer community has largely moved on

How so? Moved on to what?

I've used Jira for about two and a half years and although it wasn't that bad for us, I can see how it might not be a good fit for every team.

Anyway, we ended up using a physical board, which was reflected in Jira for remote teams. I'd take a physical board over Jira and Trello any day, but maybe that's just me.

That's been my experience as well.

But it didn't happen because I was on the lookout for a fat paycheck. It happened because the companies I worked at the time couldn't provide the stimulation, technical capabilities, working environment and personal development I was looking for.

Then I realised very few of them do where I am, so now I do 6-12 month contracts and it's helped with saving a bit of my soul and getting paid a bit more.

How did you negotiate that with your employer, and also are you doing contract/constancy work where an arrangement like that is slightly more realistic?

Got rid of it about 6-7 years ago, mainly due to all the annoying people posting photos of their food and pointless updates and check-ins. Who needs that.. I don't miss it one bit nor do I plan on using it ever again.

I like the general assumption that TDD failed.

Failed at what exactly? Who would think 1 methodology would give them all they need to be a great software engineer?

If TDD supposedly failed, can we hear the process that succeeded at what TDD failed? Please extend an olive branch and enlighten the rest of us.

Because I tell yea, I can't even count the amount of "senior software engineers" I've encountered, that deploy untested production code daily to systems that help you guys buy your coffee in the morning, manage your money and pensions. Oh yea, and they all seem to think TDD is bollocks too.

When that percentage decreases and engineers like that become a rare occurrence, then we can talk again. Peace.

Never got into it and always thought it is a complete waste of time. I advocate to write tests only for critical algorithmic calculations and nothing else.

What great advice! While we're at it let's advocate surgeons didn't use sterile instruments cos it's a waste of time.. well maybe only for heart transplants.