Taking out a competitor is good for Slack, said Butterfield: “There’s fewer choices for people.”
What a statement! This is why I dislike Slack as a company and as much as I hate Teams (have to use it at work), I have no problem with it if the choice is Slack or Teams.
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.
This is very subjective without examples. The opposite argument can also be made that code which is easier to test is sometimes better. It felt like reading a collection of quotes and articles by other people.
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.
"The outlook for the effectiveness of testing used by itself is bleak. Jones points out that a combination of unit testing, functional testing, and system testing often results in a cumulative defect detection of less than 60 percent, which is usually inadequate for production software."
personally I like write some cursory unit test because it ensures the code logic is correctly decoupled from data retrieval, but most of my unit tests are written from user reports, as part of a large no regression suite.
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.
If you're writing a web application, i've had a reasonably happy time with tests at the controller level, or perhaps right below. You want an interface where values go in and out that correspond to fairly user-level ideas, but which are still tractable for testing.
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.
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.
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.
