11–20 of 158 posts
Wow. 1. We don't test. 2. We don't code review (or rather if we do, we do it so poorly swallowed exceptions don't raise red flags.) That's an outrageously unprofessional software process.
After reading this, I can't help but feel like I dodged a bullet there.
Earlier quoted context omitted.
An outrageously unprofessional software process that created a product worth $50M! https://techcrunch.com/2011/02/02/match-com-acquires-online-...
The OP is about technical process in the software world. I'm not sure how a company's valuation comes into the conversation...
So the programmer needs to think about all the ways the code can fail. Writing the tests concretely documents that thinking in the source code repository and automates re-checking that thinking. A really good programmer then tries to organize the code, such that it's easy to think about how any given unit of code can fail. Writing unit tests rewards such organization and penalizes bad organization.
That said, TDD doesn't seem to work out that way in practice, most of the time.
Earlier quoted context omitted.
The OP is about technical process in the software world. I'm not sure how a company's valuation comes into the conversation...
I assume the implication is "if OKC can fly by the seat of their pants and still make millions, anyone could!" Which is true, but still not advisable...
How could such a tiny change have such an outsized impact on the site? “That same story happened so many different times,” my old boss David told me. “Someone launched a small, relatively innocuous change that did one of the millions of unexpected things it could have done, which then happened to break some part of the site, and then bring it all down—sometimes bring it down to the point where we couldn’t recover it…
However, the moral of the story was essentially: "software is so complicated that it is bound it break, so you have to be good at fixing it". While that is certainly true, I think that developers have a responsibility to use whatever tools they can to write high-quality software.
(then-CEO Mike Maxim) thought of testing frameworks as somewhat academic, more lofty than practical. ... Mike the CEO, who was also OkCupid’s best engineer... Mystery of the Melting Servers, solved.
My main goal is to at least have the code run in an expected way and produce an expected result. This doesn't catch everything, but it does seem to catch enough problems to be worth it for the time invested.
Edit: I should mention that I also add tests to cover something when I experience a failure, so it at least won't happen again.
How could such a tiny change have such an outsized impact on the site? “That same story happened so many different times,” my old boss David told me. “Someone launched a small, relatively innocuous change that did one of the millions of unexpected things it could have done, which then happened to break some part of the site, and then bring it all down—sometimes bring it down to the point where we couldn’t recover it…
Could you suggest any resources that might help me understand how this can be accomplished in a pure functional paradigm? Something that assumes only a casual understanding of functional programming would be especially helpful.