4 ms·
> The bottom line is that rather than using more correct tools and engineering practices, it is simply far easier and more economical to hedge software risk wit
by solatic 6y ago
> The bottom line is that rather than using more correct tools and engineering practices, it is simply far easier and more economical to hedge software risk with non-technical approaches. Moreover, if you throw enough bodies writing Java at a project for a long-enough period of time, it will produce a result or fail with a fairly predictable set of cashflows, which is itself a low quantifiable risk that’s very easy for a business to plan for.
This is a very MBA-like lens through which to examine software development. It's not wrong, but it's also a recipe for mediocrity, which is a great way to damage your culture and sit around wondering why you can never get ahead of your competition.
The deeper question is why is software quality only loosely correlated, if at all, with business outcomes?
The pessimists will point to Equifax et. al. and tell you that the market simply doesn't care, that businesses can go through downtime after leak after catastrophic failure and their stock will never take a hit. And there's some truth to that. The end consumer actually doesn't really care about the bad news. There's not much that any company in the business can do about that.
But the optimist understands that great engineering will leapfrog competitors and leave them in the dust. The value of correctness isn't in the two months after you begin, it's in the two months after your latest release five years from now. It requires vision, patience, already-available human capital, and leadership to realize the benefits.
> If the talent pool is illiquid or geographically locked, that’s a non-starter. If there isn’t a large corporate vendor to go to to sign up for a support contract, then that’s a non-starter. If there isn’t a party to sue as an insurance policy against failure, then that’s a non-starter.
If you give your talent the opportunity to work on a Haskell project and they're walking out the door when it's difficult to find Haskell work to begin with, then you, the manager, failed in deciding which talent to hire. If you're looking for a support contract to hedge against the loss of in-house talent, then you've already failed. If you think that legal solutions will protect you against market failure, then you've already failed. Haskell isn't trying to market to these people in the first place, why should it start?
- dehora 6y agoTo the poster's credit, he does frame this in terms of balancing concerns. I'd argue the post overstates the non-technical mitigation, but they seem worth being aware of, and even as a rhetorical device, overstating helps bring them into focus. > The deeper question is why is software quality only loosely correlated, if at all, with business outcomes? Because quality is on a spectrum and context specific: commercial domains need quality levels—you have to set magnitude or quantify in some way. The software profession such as it is, tends to come at this a binary matter (cite pretty much any debate about speed vs quality). That gets, I think, amplified in technical communities where correctness is deemed more important or simply more attainable in terms of claims. > But the optimist understands that great engineering will leapfrog competitors and leave them in the dust. I agree with the sentiment; I actually do think we're in a phase where engineering leverage is underestimated, but would qualify it and say this is different to correctness. What great engineering can do is offer a short term technical advantage (eg "secret sauce") and/or a sustainable one (eg "organisational speed"). It's not clear correctness provides that kind of benefit, unless we want to frame as increasing precision/accuracy/reproducibility of results.
- WJW 6y ago> but it's also a recipe for mediocrity This is framed as a downside, but to be mediocre it can't be so bad it doesn't work at all. Most software that is great from a technical standpoint is made by a relatively small team, which translates into a relatively large risk for the business since it compresses all the volatility into retaining that team or not. With average tenure in tech around two years, you can see how that is not an attractive proposition for most companies. If all the competition is also (at best) mediocre, you can simply try to compete on other (nontechnical) fields like marketing or customer support. There is a secondary level of incentives that is present in most larger companies: delivering a fantastic product will make the owners rich and the people involved will maybe get a raise. Delivering a spectacularly failed project ends your chances of career advancement. This really diminishes the appetite for taking technical risk amongst decision makers. Mediocre is often good enough.
- marcosdumay 6y ago> delivering a fantastic product will make the owners rich and the people involved will maybe get a raise. Delivering a spectacularly failed project ends your chances of career advancement. Aren't ~90% of the software projects failures? Mediocre software is failure. There is no upside to avoiding all risks.
- WJW 6y agoOf course there is upside in avoiding all risks, as long as you are happy with the status quo. I understand if you personally are not happy with it, but we just have to look around to see conservative people everywhere.