10 ms·

I'm amused by the tone. It's like the author doesn't realize that 99% of software development and deployment is done like this, or much much worse. Welcome to t

I'm amused by the tone. It's like the author doesn't realize that 99% of software development and deployment is done like this, or much much worse. Welcome to the real world. We work in an incredibly immature industry. And trying to enforce better practices rarely works out as intended. To give one example: we rolled out mandatory code reviews on all changes. Now we have thousands of rubber-stamped "looks good to me" code reviews without any remarks. Managers care about speed of implementation, not quality. At retrospectives, I hear unironic boasts about how many bugs were solved last sprint, instead of reflection on how those bugs were introduced in the first place.

siwatanejo 8y ago
This may be the majority of the industry, true. But some devs filter out employers to not feel miserable. Whenever I find an employer like this, either I try to change the status quo, or I leave.
- repomies68 8y ago
  This. Don't except things to change if you happily stay in a workplace where things are done in a half-assed way. There's endless supply of jobs for software people nowadays.
- wDcBKgt66V8WDs 8y ago
  Changing the status quo is kinda fun in these environments. Low hanging fruit, easy work. As long as your head isn't on the chopping block. And everyone benefits. You, the employer, your colleagues, the fresh grads with starry eyes
  - WrtCdEvrydy 8y ago
    'Wanna make some enemies? Try to change something'
  - rectang 8y ago
    It can be rewarding, but there are a couple caveats. First, management has to be willing to assign you to cleanup tasks, rather than have you work on new features. Second, cleaning up spaghetti code safely and turning it into something maintainable is often not easy -- it wasn't written to be maintained! No tests, missing documentation, ill-considered interfaces... It isn't enough to keep your head off the chopping block: management has to be fully on board.
    - wDcBKgt66V8WDs 8y ago
      Yeah in my case I've got my manager and architect on board and they love it. My more senior teammates might be threatened though. I found an impending any-day-now production down scenario last week and got it fixed while learning tremendously and fixing some incidentally related things. It feels amazing. No tests, no docs, no comments, total spaghetti, global variables everywhere, no logs, and I am loving it. What a job. Upper upper management is starting to keep tabs on the "productive" output of my team though. We'll see.
nradov 8y ago
We do intensive root cause analysis on every serious defect that leaks into production. Look into the "5 why's" technique. Usually there's something to learn in terms of a process or training improvement. If the analysis shows the defect could have reasonably been caught during the code review phase then management sometimes has to recalibrate the reviewers. It's also important to select the right reviewers based on the scope and risk of the change. For the largest, most complex changes we sometimes pull in up to 6 reviewers including members of other teams and high level architects.
seanwilson 8y ago
> I'm amused by the tone. It's like the author doesn't realize that 99% of software development and deployment is done like this, or much much worse. Welcome to the real world. Agree with this, a lot of developers are in a filter bubble where they stick to communities that advocate modern practices like automated testing, continuous integration, containers, gitflow, staging environments etc. As a contractor, I get to see the internals of lots of different companies - forget practices even as basic as doing code reviews, I've seen companies not using source control with no staging environments and no local development environments where all changes are being made directly on the production server via SFTP on a basic VPS. A lot of the time there's no internal experts there that are even aware there's better ways to do things instead of it being the case they're lacking resources to make improvements.
- foldor 8y ago
  I wish I hadn't experienced this exact scenario as well. I actually worked at a publishing company where I discovered the previous team building their major education platform didn't know there was such thing as source control. Their method for sharing multiple team members changes was to email the full project to one person every Friday who would manually open a merging tool and merge all changes themselves. They would then send out the updated code base to all people again. Because of this method, they were afraid to delete any stale code, and just prefixed old versions of functions with XX. As you can imagine, inheriting that code base was a nightmare to deal with.
  - WrtCdEvrydy 8y ago
    Someone created a jenkins pipeline that would deploy code in a zip file into prod.
    - mattmanser 8y ago
      Am I missing something? Isn't this exactly how deployment servers actually work? I'm not into Java development, but this sounds fine on the face of it, without you giving the context of how this pipeline is triggered.
Defenestresque 8y ago
There is a really, really interesting breakdown of this document on kitchensoap.com [0] The writer breaks down why this document is not a post-mortem despite superficial similarities. >Again, the purpose of the doc is to point out where Knight violated rules. It is not: 1) a description of the multiple trade-offs that engineering at Knight made or considered when designing fault-tolerance in their systems, or 2) how Knight as an organization evolved over time to focus on evolving some procedures and not others, or 3) how engineers anticipated in preparation for deploying support for the new RLP effort on Aug 1, 2012. >To equate any of those things with violation of a rule is a cognitive leap that we should stay very far away from. >It’s worth mentioning here that the document only focuses on failures, and makes no mention of successes. How Knight succeeded during diagnosis and response is unknown to us, so a rich source of data isn’t available. Because of this, we cannot pretend the document to give explanation. He also makes an interesting point related to what you're saying: the SEC says the risk management controls were inappropriate, but clearly Knight thought they were appropriate or they would have fixed it. >What is deemed “appropriate”, it would seem, is dependent on the outcome. Had an accident? It was not appropriate control. Didn’t have an accident? It must be appropriate control. This would mean that Knight Capital did have appropriate controls the day before the accident. Outcome bias reigns supreme here. I'd go into it more but I would instead recommend you take a look at his breakdown as I'd be trying to do a shoddy summary of a really interesting write-up. [0] https://www.kitchensoap.com/2013/10/29/counterfactuals-knight-capital/ https://www.kitchensoap.com/2013/10/29/counterfactuals-knigh...
- guitarbill 8y ago
  This kitchensoap article may be more correct, but man, it's a arduous read. A bit of brevity and humour can work wonders, conversely complete correctness can be detrimental if people lose attention.
  - Defenestresque 8y ago
    It is a lengthy slog for sure, but I found it a great way to kill some time. Maybe you just have to be in one of those reading moods.
badfrog 8y ago
But also for 99% of companies, running the wrong version for an hour won't bankrupt the company and all of its investors.
- Causality1 8y ago
  You live by the AI stock trader, you die by the AI stock trader.
- Bartweiss 8y ago
  I've seen a lot of companies and teams with hair-raising practices, but most of them still manage some basic business-logic safeguards like "don't buy for more than $X" or "if we don't sell anything for 10 minutes, shut it all down and sound the alarms". Generally they can't do worse than "making no money" or maybe "paying full expenses without making any profits". The link here excerpts the full filing, but the real meat wasn't included: > 16... Because the cumulative quantity function had been moved, this server continuously sent child orders, in rapid sequence, for each incoming parent order without regard to the number of share executions Knight had already received from trading centers... 17. The consequences of the failures were substantial. For the 212 incoming parent orders that were processed by the defective Power Peg code, SMARS sent millions of child orders, resulting in 4 million executions in 154 stocks for more than 397 million shares in approximately 45 minutes. Knight inadvertently assumed an approximately $3.5 billion net long position in 80 stocks and an approximately $3.15 billion net short position in 74 stocks. Ultimately, Knight realized a $460 million loss on these positions. Knight did $1.4 billion in revenue per year, but there was no safeguard against adopting $7 billion worth of positions in 45 minutes. The end result was that they lost 4 years of profits in under an hour. That's crazy, and not at all standard.
devinjflick 8y ago
> We work in an incredibly immature industry. I'd add that it's the the incredibly immature economic system, paired with an even more immature(new) industry that leads to this kind of failure. I feel like this is a symptom of tech in capitalism. Where the goal is to maximize profits and minimize effort, rather than doing the job correctly. Fitting that this would befall a high freq trading firm.
StreamBright 8y ago
This is true for the bottom ~80% of the industry. The top ~20% of tech companies actually care about quality (as well as speed of implementation). You cannot deliver a shitty solution quickly and call it a day.
- ergothus 8y ago
  > bottom ~80% of the industry. The top ~20% How are you defining "top" and "bottom" here? I can agree with the 80/20 split, but I don't think it necessarily tracks with, say, name recognition or market cap. Amazon, for example, utterly failed on their last Prime day, and from the discussions of those Amazonians I know, it was pretty much inevitable. The REASON these fast-and-loose habits are habits are because, when they work, they make money. You can't look at a lottery and say the winners "did it right" and the losers didn't - the winners just haven't failed yet. Those companies that AREN'T trying to grow at ridiculous speeds but ARE trying to maintain quality (and are fortunate enough to be in a market niche that supports that) are the ones most likely to have bulletproof reliability. Those won't be the "top" companies by most peoples definitions.
  - StreamBright 8y ago
    >> , for example, utterly failed on their last Prime day, and from the discussions of those Amazonians I know, it was pretty much inevitable I am not familiar what happened. I am also ex-Amzn. I think there is also a dimension to this, scale. With Amazon's scale there are quite different challeges then in a smaller company. There are solutions that could not possible scale to their needs. Fast-and-lose was largely introduced when Google and Facebook got entered the scene. I remember that Google did a survey and most of the users were ok with some breakage and get the newest features ASAP. Many people concluded based on this that all software development is like that. Ironically Facebook lately adopted certain technologies to reduce the amount of bugs in their frontend code (ReasonML). I think there is a large distance between bulletproof and feck-all reliability. Top companies are closer to the bulletproof range of the spectrum while bottom companies closer to the feck-all end.
    - 8y ago
oconnor663 8y ago
> We work in an incredibly immature industry Whether or not that's true, I don't know if it's the right framing for the problem. Think about how many new cars or new airplanes or new bridges are designed every year. (One or two per large firm? Less? None by any small firms?) Then think about how many new web services are designed every year. (Several for a small firm, dozens for a large firm?) If "maturing" the software design process means 10x or 100x the cost and time that a project takes today, that isn't going to fly in the market. It might make more sense to point out the discrepancies between the typical software project (low cost for mistakes, high tolerance for downtime) and the atypical finance/medicine/aerospace software project (don't screw up or people die). Maybe the specific part of the industry that needs to mature is the _awareness_ of when you cross that boundary, especially within a single organization. The folks working on the internal HR system and the folks working on the high-frequency trading system need to use different procedures (and different levels of funding and different management expectations), and if they're the same folks on different days that might be very far from obvious.
- tracker1 8y ago
  +1 on this... there's a huge difference in code that may be used by a dozen users to pick where to have lunch and HFT systems that handle millions of dollars worth of capital investment a day. There also is a correlated high burnout. About a decade ago, I was a contractor in a security services team at a large bank. There were systems in place to minimize the impact of our software, which handled requests for access, and the actual access granted. Our software was developed like most, or worse in the beginning. In the end, by separating workflows and agreeing on interfaces, a lot of issues were prevented altogether. Other systems should be designed with similar safeguards and separate certain control flows behind well thought out APIs. Others still should be created much closer to classic waterfall, with adjustments meaning a stop-work, re-evaluate, update design, and proceed process in place. It should really depend on the situation.
inputcoffee 8y ago
You guys think this is bad? In finance, I've seen people compute deals worth billions of dollars using excel spreadsheets and a team of MBAs.
- b_tterc_p 8y ago
  There’s nothing explicitly wrong with this. MBA’s aren’t intrinsically stupid, and excel is a reasonable tool for calculations. It’s just a pure functional language using geometric space instead of a namespace.
- deleted 8y ago
  [deleted]
- antoineMoPa 8y ago
  The team of MBA's can probably help avoid 172k$/second types of mistakes no?
  - Bartweiss 8y ago
    Yep - all the focus on the engineering specifics here seems to miss the sheer magnitude of the thing. Knight risked 4x their annual revenue in under an hour! You can get away with some incredibly crappy systems if you have final-line safeguards like "let's not risk all the money we've ever seen and more without asking a human". The team of MBAs might screw up an Excel formula and lose money on a deal, but presumably if the math comes out to "let's pay $500 billion for Yahoo", somebody's going sanity-check that before they transfer the money.
    - perl4ever 8y ago
      I think companies have on occasion lost billions due to a glitch in a contract, sometimes due to delegating work to a novice who didn't fully understand it. And a contract is not totally unlike a program.
- spookthesunset 8y ago
  Most business deals are done in part based on results from excel spreadsheets. What other tool would you expect to be used?
caprese 8y ago
> we rolled out mandatory code reviews on all changes. Now we have thousands of rubber-stamped "looks good to me" code reviews without any remarks with this practice I have gotten a better habit of looking at the code changes and having a mental image of what things do this coupled with annotation in the IDE helps me really keep up with the code only occasionally do I get an actual WTF that prompts me to leave any remark or not approve the change I'm still better informed about the code change and implementation than not
hartator 8y ago
Every industries are immature. We just saw it more clearly because we are in it.
deleted 8y ago
[deleted]
pwg 8y ago
> I'm amused by the tone. It reads to me like standard RCA (Root Cause Analysis) language/tone.
dragonwriter 8y ago
> It's like the author doesn't realize that 99% of software development and deployment is done like this, or much much worse. Not sure if you are talking about the author of the SEC document (the “bug report”) or the blogger, but in either case, what is okay in 99% of software development may be quite inadequate for critical software used in tightly regulated industries. Context matters. > Managers care about speed of implementation, not quality. Managers care about speed of implementation not quality insofar as quality is often hard to unambiguously measure and hard to assess impact on the bottom line (not just quantity, but whether there is really any impact.) This is a fairly dramatic example of the impact being made concrete.

siwatanejo 8y ago

This may be the majority of the industry, true. But some devs filter out employers to not feel miserable. Whenever I find an employer like this, either I try to change the status quo, or I leave.

repomies68 8y ago
This. Don't except things to change if you happily stay in a workplace where things are done in a half-assed way. There's endless supply of jobs for software people nowadays.
wDcBKgt66V8WDs 8y ago
Changing the status quo is kinda fun in these environments. Low hanging fruit, easy work. As long as your head isn't on the chopping block. And everyone benefits. You, the employer, your colleagues, the fresh grads with starry eyes
- WrtCdEvrydy 8y ago
  'Wanna make some enemies? Try to change something'
- rectang 8y ago
  It can be rewarding, but there are a couple caveats. First, management has to be willing to assign you to cleanup tasks, rather than have you work on new features. Second, cleaning up spaghetti code safely and turning it into something maintainable is often not easy -- it wasn't written to be maintained! No tests, missing documentation, ill-considered interfaces... It isn't enough to keep your head off the chopping block: management has to be fully on board.
  - wDcBKgt66V8WDs 8y ago
    Yeah in my case I've got my manager and architect on board and they love it. My more senior teammates might be threatened though. I found an impending any-day-now production down scenario last week and got it fixed while learning tremendously and fixing some incidentally related things. It feels amazing. No tests, no docs, no comments, total spaghetti, global variables everywhere, no logs, and I am loving it. What a job. Upper upper management is starting to keep tabs on the "productive" output of my team though. We'll see.

nradov 8y ago

We do intensive root cause analysis on every serious defect that leaks into production. Look into the "5 why's" technique. Usually there's something to learn in terms of a process or training improvement. If the analysis shows the defect could have reasonably been caught during the code review phase then management sometimes has to recalibrate the reviewers. It's also important to select the right reviewers based on the scope and risk of the change. For the largest, most complex changes we sometimes pull in up to 6 reviewers including members of other teams and high level architects.

seanwilson 8y ago

> I'm amused by the tone. It's like the author doesn't realize that 99% of software development and deployment is done like this, or much much worse. Welcome to the real world. Agree with this, a lot of developers are in a filter bubble where they stick to communities that advocate modern practices like automated testing, continuous integration, containers, gitflow, staging environments etc. As a contractor, I get to see the internals of lots of different companies - forget practices even as basic as doing code reviews, I've seen companies not using source control with no staging environments and no local development environments where all changes are being made directly on the production server via SFTP on a basic VPS. A lot of the time there's no internal experts there that are even aware there's better ways to do things instead of it being the case they're lacking resources to make improvements.

foldor 8y ago
I wish I hadn't experienced this exact scenario as well. I actually worked at a publishing company where I discovered the previous team building their major education platform didn't know there was such thing as source control. Their method for sharing multiple team members changes was to email the full project to one person every Friday who would manually open a merging tool and merge all changes themselves. They would then send out the updated code base to all people again. Because of this method, they were afraid to delete any stale code, and just prefixed old versions of functions with XX. As you can imagine, inheriting that code base was a nightmare to deal with.
- WrtCdEvrydy 8y ago
  Someone created a jenkins pipeline that would deploy code in a zip file into prod.
  - mattmanser 8y ago
    Am I missing something? Isn't this exactly how deployment servers actually work? I'm not into Java development, but this sounds fine on the face of it, without you giving the context of how this pipeline is triggered.

Defenestresque 8y ago

There is a really, really interesting breakdown of this document on kitchensoap.com [0] The writer breaks down why this document is not a post-mortem despite superficial similarities. >Again, the purpose of the doc is to point out where Knight violated rules. It is not: 1) a description of the multiple trade-offs that engineering at Knight made or considered when designing fault-tolerance in their systems, or 2) how Knight as an organization evolved over time to focus on evolving some procedures and not others, or 3) how engineers anticipated in preparation for deploying support for the new RLP effort on Aug 1, 2012. >To equate any of those things with violation of a rule is a cognitive leap that we should stay very far away from. >It’s worth mentioning here that the document only focuses on failures, and makes no mention of successes. How Knight succeeded during diagnosis and response is unknown to us, so a rich source of data isn’t available. Because of this, we cannot pretend the document to give explanation. He also makes an interesting point related to what you're saying: the SEC says the risk management controls were inappropriate, but clearly Knight thought they were appropriate or they would have fixed it. >What is deemed “appropriate”, it would seem, is dependent on the outcome. Had an accident? It was not appropriate control. Didn’t have an accident? It must be appropriate control. This would mean that Knight Capital did have appropriate controls the day before the accident. Outcome bias reigns supreme here. I'd go into it more but I would instead recommend you take a look at his breakdown as I'd be trying to do a shoddy summary of a really interesting write-up. [0] https://www.kitchensoap.com/2013/10/29/counterfactuals-knight-capital/ https://www.kitchensoap.com/2013/10/29/counterfactuals-knigh...

guitarbill 8y ago
This kitchensoap article may be more correct, but man, it's a arduous read. A bit of brevity and humour can work wonders, conversely complete correctness can be detrimental if people lose attention.
- Defenestresque 8y ago
  It is a lengthy slog for sure, but I found it a great way to kill some time. Maybe you just have to be in one of those reading moods.

badfrog 8y ago

But also for 99% of companies, running the wrong version for an hour won't bankrupt the company and all of its investors.

Causality1 8y ago
You live by the AI stock trader, you die by the AI stock trader.
Bartweiss 8y ago
I've seen a lot of companies and teams with hair-raising practices, but most of them still manage some basic business-logic safeguards like "don't buy for more than $X" or "if we don't sell anything for 10 minutes, shut it all down and sound the alarms". Generally they can't do worse than "making no money" or maybe "paying full expenses without making any profits". The link here excerpts the full filing, but the real meat wasn't included: > 16... Because the cumulative quantity function had been moved, this server continuously sent child orders, in rapid sequence, for each incoming parent order without regard to the number of share executions Knight had already received from trading centers... 17. The consequences of the failures were substantial. For the 212 incoming parent orders that were processed by the defective Power Peg code, SMARS sent millions of child orders, resulting in 4 million executions in 154 stocks for more than 397 million shares in approximately 45 minutes. Knight inadvertently assumed an approximately $3.5 billion net long position in 80 stocks and an approximately $3.15 billion net short position in 74 stocks. Ultimately, Knight realized a $460 million loss on these positions. Knight did $1.4 billion in revenue per year, but there was no safeguard against adopting $7 billion worth of positions in 45 minutes. The end result was that they lost 4 years of profits in under an hour. That's crazy, and not at all standard.

devinjflick 8y ago

> We work in an incredibly immature industry. I'd add that it's the the incredibly immature economic system, paired with an even more immature(new) industry that leads to this kind of failure. I feel like this is a symptom of tech in capitalism. Where the goal is to maximize profits and minimize effort, rather than doing the job correctly. Fitting that this would befall a high freq trading firm.

StreamBright 8y ago

This is true for the bottom ~80% of the industry. The top ~20% of tech companies actually care about quality (as well as speed of implementation). You cannot deliver a shitty solution quickly and call it a day.

ergothus 8y ago
> bottom ~80% of the industry. The top ~20% How are you defining "top" and "bottom" here? I can agree with the 80/20 split, but I don't think it necessarily tracks with, say, name recognition or market cap. Amazon, for example, utterly failed on their last Prime day, and from the discussions of those Amazonians I know, it was pretty much inevitable. The REASON these fast-and-loose habits are habits are because, when they work, they make money. You can't look at a lottery and say the winners "did it right" and the losers didn't - the winners just haven't failed yet. Those companies that AREN'T trying to grow at ridiculous speeds but ARE trying to maintain quality (and are fortunate enough to be in a market niche that supports that) are the ones most likely to have bulletproof reliability. Those won't be the "top" companies by most peoples definitions.
- StreamBright 8y ago
  >> , for example, utterly failed on their last Prime day, and from the discussions of those Amazonians I know, it was pretty much inevitable I am not familiar what happened. I am also ex-Amzn. I think there is also a dimension to this, scale. With Amazon's scale there are quite different challeges then in a smaller company. There are solutions that could not possible scale to their needs. Fast-and-lose was largely introduced when Google and Facebook got entered the scene. I remember that Google did a survey and most of the users were ok with some breakage and get the newest features ASAP. Many people concluded based on this that all software development is like that. Ironically Facebook lately adopted certain technologies to reduce the amount of bugs in their frontend code (ReasonML). I think there is a large distance between bulletproof and feck-all reliability. Top companies are closer to the bulletproof range of the spectrum while bottom companies closer to the feck-all end.
  - 8y ago

oconnor663 8y ago

> We work in an incredibly immature industry Whether or not that's true, I don't know if it's the right framing for the problem. Think about how many new cars or new airplanes or new bridges are designed every year. (One or two per large firm? Less? None by any small firms?) Then think about how many new web services are designed every year. (Several for a small firm, dozens for a large firm?) If "maturing" the software design process means 10x or 100x the cost and time that a project takes today, that isn't going to fly in the market. It might make more sense to point out the discrepancies between the typical software project (low cost for mistakes, high tolerance for downtime) and the atypical finance/medicine/aerospace software project (don't screw up or people die). Maybe the specific part of the industry that needs to mature is the _awareness_ of when you cross that boundary, especially within a single organization. The folks working on the internal HR system and the folks working on the high-frequency trading system need to use different procedures (and different levels of funding and different management expectations), and if they're the same folks on different days that might be very far from obvious.

tracker1 8y ago
+1 on this... there's a huge difference in code that may be used by a dozen users to pick where to have lunch and HFT systems that handle millions of dollars worth of capital investment a day. There also is a correlated high burnout. About a decade ago, I was a contractor in a security services team at a large bank. There were systems in place to minimize the impact of our software, which handled requests for access, and the actual access granted. Our software was developed like most, or worse in the beginning. In the end, by separating workflows and agreeing on interfaces, a lot of issues were prevented altogether. Other systems should be designed with similar safeguards and separate certain control flows behind well thought out APIs. Others still should be created much closer to classic waterfall, with adjustments meaning a stop-work, re-evaluate, update design, and proceed process in place. It should really depend on the situation.

inputcoffee 8y ago

You guys think this is bad? In finance, I've seen people compute deals worth billions of dollars using excel spreadsheets and a team of MBAs.

b_tterc_p 8y ago
There’s nothing explicitly wrong with this. MBA’s aren’t intrinsically stupid, and excel is a reasonable tool for calculations. It’s just a pure functional language using geometric space instead of a namespace.
deleted 8y ago
[deleted]
antoineMoPa 8y ago
The team of MBA's can probably help avoid 172k$/second types of mistakes no?
- Bartweiss 8y ago
  Yep - all the focus on the engineering specifics here seems to miss the sheer magnitude of the thing. Knight risked 4x their annual revenue in under an hour! You can get away with some incredibly crappy systems if you have final-line safeguards like "let's not risk all the money we've ever seen and more without asking a human". The team of MBAs might screw up an Excel formula and lose money on a deal, but presumably if the math comes out to "let's pay $500 billion for Yahoo", somebody's going sanity-check that before they transfer the money.
  - perl4ever 8y ago
    I think companies have on occasion lost billions due to a glitch in a contract, sometimes due to delegating work to a novice who didn't fully understand it. And a contract is not totally unlike a program.
spookthesunset 8y ago
Most business deals are done in part based on results from excel spreadsheets. What other tool would you expect to be used?

caprese 8y ago

> we rolled out mandatory code reviews on all changes. Now we have thousands of rubber-stamped "looks good to me" code reviews without any remarks with this practice I have gotten a better habit of looking at the code changes and having a mental image of what things do this coupled with annotation in the IDE helps me really keep up with the code only occasionally do I get an actual WTF that prompts me to leave any remark or not approve the change I'm still better informed about the code change and implementation than not

hartator 8y ago

Every industries are immature. We just saw it more clearly because we are in it.

deleted 8y ago

[deleted]

pwg 8y ago

> I'm amused by the tone. It reads to me like standard RCA (Root Cause Analysis) language/tone.

dragonwriter 8y ago

> It's like the author doesn't realize that 99% of software development and deployment is done like this, or much much worse. Not sure if you are talking about the author of the SEC document (the “bug report”) or the blogger, but in either case, what is okay in 99% of software development may be quite inadequate for critical software used in tightly regulated industries. Context matters. > Managers care about speed of implementation, not quality. Managers care about speed of implementation not quality insofar as quality is often hard to unambiguously measure and hard to assess impact on the bottom line (not just quantity, but whether there is really any impact.) This is a fairly dramatic example of the impact being made concrete.