3 ms·

Let's not forget about the social aspect -- testing is seen by many in the industry as a less prestigious activity, one which you hire barely competent "develop

Let's not forget about the social aspect -- testing is seen by many in the industry as a less prestigious activity, one which you hire barely competent "developers" and can hurt career progression if accepting a job doing it (exceptions always exist).

im_down_w_otp 10y ago
It seems like the marketplace has decided that it's usually okay to push/deliver/ship questionable software. We even have a cute colloquial industry term for this, "MVP". Minimally viable. That's Grade-D beef... by design. When the focus is pushing out Grade-D goods what's the point of rigorous testing? If you get it wrong, it barely matters. If it matters at all. Perhaps the social view of software testing is just a corollary to the state of software engineering?
- ethbro 10y ago
  I feel like MVP design winning is the market clearly deciding that it values features over stability. I'm curious if the economics of this will change when / if we come to the end of exponential hardware growth.
  - im_down_w_otp 10y ago
    I think to some extent the boundary of friction that's going to grow between software creators and hardware manufacturers as various shapes of Smart-thing-X become more prevalent might ebb this a bit. Because as more feature-laiden software is written to facilitate growth in consumer and industrial markets that is deployed on something more akin to an embedded device than a PC or server there's going to have to be more rigor applied to the correctness of the software to compensate for how tightly coupled it is to the largely immutable use-specific hardware.
    - ethbro 10y ago
      Frighteningly possible counter-alternative: continue to ship bad software on embedded devices and just toss network connectivity in there in the event the device becomes popular / customers demand an update.
      - im_down_w_otp 10y ago
        Yeah. I certainly fully expect a certain cross-section that is shaped just like that. Take "Nest" as an example. Unless the "smart" thermostat can somehow manage to burn my house down by turning the heat up way, way too high... then the fact that it's almost comically broken as a "smart" device doesn't really matter. Just keep pushing updates to it. However, I think there's a growing surface area where our consumer expectations for iteration and features are going to bleed into places that were previously left largely untouched by such demands. "Smart" cars are probably a good example. There's growing and intensifying competition for the ownership of the experience in the cabin/cockpit of the car, and in order to draw lines of competition there's a lot of focus on how to integrate that space with the rest of your normal and your digital lifestyle. That ends up being a place where, to avoid ending up the subject of very public screw ups, some amount of rigor that's applied to the lower-level stack will also eventually bubble up to the feature/application level at the same time that enablement for features/applications (network connectivity, new kinds of input devices, etc.) will end up being forced into the lower levels of the stack. Or at the very least a useful set of stable abstractions and tools will be built to prevent today's software developers from having to care very much about applying that rigor and the abstractions/tools will just take care of it for them.

im_down_w_otp 10y ago

It seems like the marketplace has decided that it's usually okay to push/deliver/ship questionable software. We even have a cute colloquial industry term for this, "MVP". Minimally viable. That's Grade-D beef... by design. When the focus is pushing out Grade-D goods what's the point of rigorous testing? If you get it wrong, it barely matters. If it matters at all. Perhaps the social view of software testing is just a corollary to the state of software engineering?

ethbro 10y ago
I feel like MVP design winning is the market clearly deciding that it values features over stability. I'm curious if the economics of this will change when / if we come to the end of exponential hardware growth.
- im_down_w_otp 10y ago
  I think to some extent the boundary of friction that's going to grow between software creators and hardware manufacturers as various shapes of Smart-thing-X become more prevalent might ebb this a bit. Because as more feature-laiden software is written to facilitate growth in consumer and industrial markets that is deployed on something more akin to an embedded device than a PC or server there's going to have to be more rigor applied to the correctness of the software to compensate for how tightly coupled it is to the largely immutable use-specific hardware.
  - ethbro 10y ago
    Frighteningly possible counter-alternative: continue to ship bad software on embedded devices and just toss network connectivity in there in the event the device becomes popular / customers demand an update.
    - im_down_w_otp 10y ago
      Yeah. I certainly fully expect a certain cross-section that is shaped just like that. Take "Nest" as an example. Unless the "smart" thermostat can somehow manage to burn my house down by turning the heat up way, way too high... then the fact that it's almost comically broken as a "smart" device doesn't really matter. Just keep pushing updates to it. However, I think there's a growing surface area where our consumer expectations for iteration and features are going to bleed into places that were previously left largely untouched by such demands. "Smart" cars are probably a good example. There's growing and intensifying competition for the ownership of the experience in the cabin/cockpit of the car, and in order to draw lines of competition there's a lot of focus on how to integrate that space with the rest of your normal and your digital lifestyle. That ends up being a place where, to avoid ending up the subject of very public screw ups, some amount of rigor that's applied to the lower-level stack will also eventually bubble up to the feature/application level at the same time that enablement for features/applications (network connectivity, new kinds of input devices, etc.) will end up being forced into the lower levels of the stack. Or at the very least a useful set of stable abstractions and tools will be built to prevent today's software developers from having to care very much about applying that rigor and the abstractions/tools will just take care of it for them.