3 ms·

> Starting a project I have a feeling you're working from a different set of base assumptions. If you're working for a company that is paying multiple people's

> Starting a project I have a feeling you're working from a different set of base assumptions. If you're working for a company that is paying multiple people's worth of salaries to deliver a project, a project whose definition of done is "delivered to market" and not "earning $X revenue", then yeah, if people are going to be de-tasked after the project is up and migrated to other projects, I absolutely appreciate that whatever project manager is running that project should ensure that it has a nice testing suite to prove that the project works. Behavior-Driven-Development, ideally. I just think that's a monumentally expensive way to develop software, one that executives should have relegated to the trash bin twenty years ago, after the Agile Manifesto. If you're a private sector business then you want to develop quality software at the lowest cost. Guess what? Automated tests, in and of themselves, don't tell you whether you have quality software! The only way you know whether your software has any quality at all is whether people pay money for it! Not whether software fits an arbitrary spec determined at the beginning of the "project".

AnimalMuppet 4y ago
You're using a different definition of "quality software" that is orthogonal to the one that the rest of us are using. Your definition is the one that isn't helped much by automated tests. But for an actual product, you really want both kinds of quality, including the kind that is helped by automated tests.
nibbleshifter 4y ago
> The only way you know whether your software has any quality at all is whether people pay money for it! People pay for poor quality, bug ridden software all the time (see: Atlassian products). I think your definition of "quality" (makes money) is different to everyone else's (isn't a bug riddled heap of shit).
hinkley 4y ago
Detasked is a definite problem, but I’m more concerned about the reverse, which is being overwhelmed by customer input. Once the party starts it’s too late to change some things. Everything is a priority queue and louder more charismatic voices will push out you quality of life concerns. Edit: but in this thread what I’m talking about is skill. The longer you wait to practice a skill that you will need in abundance, the more likelihood that you will fail outright. You need a long runway for operational excellence.
simonw 4y ago
It sounds to me like you're arguing from a position where tests are expensive and time consuming to write. If you have the right habits and testing tools in place, this doesn't need to be the case. I write tests for even my tiniest projects: I estimate I spend less than 20% of my coding time working on the tests - and they give me more than a 20% boost in productivity VERY quickly. But... that's because every one of my projects starts with a pytest test suite in place. Adding new tests to an existing test suite is massively less work than adding tests if there's no test suite and you have to spin one up from scratch.
- hinkley 4y ago
  I’ve seen it go off the rails though. I’ve seen people exhibit traumatic responses to it. Pain is information, but there are less helpful ways to interpret it. There are some architectural decisions I resist energetically because they create a lot of consequences for testing, with not a lot of value added compared to other alternatives. If you introduce something that makes writing code 30% harder you’d better be getting a lot of profit margin out of the deal. Otherwise you’re just torturing people for no good reason
  - hbrn 4y ago
    I haven't seen a single case where it doesn't go off the rails. One problem with tests is that benefits are immediate, but costs are delayed. When you're writing tests it feels like you're creating nothing but value. By the time you realize that tests made your architecture stiff as a board, they have already spread everywhere. I've seen numerous cases where teams were not able to refactor because too many tests were failing. Quite ironic, given that tests are supposed to help refactoring.
    - hinkley 4y ago
      I don’t think it’s an accident that I’ve had more testing mentors than anything else. Testing is hard. There’s a huge number of mistakes you can make and I’ve only made 70% of them so I deflect people calling me an expert. I’m not an expert, but I can look at tests and enumerate all of the rookie and sophomore mistakes, and let me tell you that can keep some people busy for their entire tenure. I don’t say it in front of policy people much, but I immediately suspect anything as hard as this of being done incorrectly.

AnimalMuppet 4y ago

You're using a different definition of "quality software" that is orthogonal to the one that the rest of us are using. Your definition is the one that isn't helped much by automated tests. But for an actual product, you really want both kinds of quality, including the kind that is helped by automated tests.

nibbleshifter 4y ago

> The only way you know whether your software has any quality at all is whether people pay money for it! People pay for poor quality, bug ridden software all the time (see: Atlassian products). I think your definition of "quality" (makes money) is different to everyone else's (isn't a bug riddled heap of shit).

hinkley 4y ago

Detasked is a definite problem, but I’m more concerned about the reverse, which is being overwhelmed by customer input. Once the party starts it’s too late to change some things. Everything is a priority queue and louder more charismatic voices will push out you quality of life concerns. Edit: but in this thread what I’m talking about is skill. The longer you wait to practice a skill that you will need in abundance, the more likelihood that you will fail outright. You need a long runway for operational excellence.

simonw 4y ago

It sounds to me like you're arguing from a position where tests are expensive and time consuming to write. If you have the right habits and testing tools in place, this doesn't need to be the case. I write tests for even my tiniest projects: I estimate I spend less than 20% of my coding time working on the tests - and they give me more than a 20% boost in productivity VERY quickly. But... that's because every one of my projects starts with a pytest test suite in place. Adding new tests to an existing test suite is massively less work than adding tests if there's no test suite and you have to spin one up from scratch.

hinkley 4y ago
I’ve seen it go off the rails though. I’ve seen people exhibit traumatic responses to it. Pain is information, but there are less helpful ways to interpret it. There are some architectural decisions I resist energetically because they create a lot of consequences for testing, with not a lot of value added compared to other alternatives. If you introduce something that makes writing code 30% harder you’d better be getting a lot of profit margin out of the deal. Otherwise you’re just torturing people for no good reason
- hbrn 4y ago
  I haven't seen a single case where it doesn't go off the rails. One problem with tests is that benefits are immediate, but costs are delayed. When you're writing tests it feels like you're creating nothing but value. By the time you realize that tests made your architecture stiff as a board, they have already spread everywhere. I've seen numerous cases where teams were not able to refactor because too many tests were failing. Quite ironic, given that tests are supposed to help refactoring.
  - hinkley 4y ago
    I don’t think it’s an accident that I’ve had more testing mentors than anything else. Testing is hard. There’s a huge number of mistakes you can make and I’ve only made 70% of them so I deflect people calling me an expert. I’m not an expert, but I can look at tests and enumerate all of the rookie and sophomore mistakes, and let me tell you that can keep some people busy for their entire tenure. I don’t say it in front of policy people much, but I immediately suspect anything as hard as this of being done incorrectly.