6 ms·

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 unp

by JackFr 8y ago

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.

danesparza 8y ago
I was immediately struck by the same set of thoughts. I don't know whether to be appalled or just ... sad.
andrenotgiant 8y ago
An outrageously unprofessional software process that created a product worth $50M! https://techcrunch.com/2011/02/02/match-com-acquires-online-dating-site-okcupid-for-50-million-in-cash/ https://techcrunch.com/2011/02/02/match-com-acquires-online-...
- danesparza 8y ago
  The OP is about technical process in the software world. I'm not sure how a company's valuation comes into the conversation...
  - blacksmith_tb 8y ago
    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...
    - stcredzero 8y ago
      Given that technical debt is quite hard for non-technical people to quantify, why wouldn't we expect that most startups would tend to accrue technical debt?
      - theseatoms 8y ago
        Can anyone quantify technical debt? Best case is something resembling a medical diagnosis.
        stcredzero 8y ago
        I think that could be enough. Actuaries have a good idea about when you are likely to die in the next two years. Basically, when you are old and your medical costs suddenly double. Doctors use the same sort of inductive reasoning for their prognosis. The industry probably collectively has all the information to put together useful actuarial tables on technical debt, but it's all silo'd in individual companies.
        theseatoms 8y ago
        Interesting. Are there IT consulting firms that specialize in this field of study?
      - adrianN 8y ago
        Startups accrue so much financial debt, adding some technical debt on top doesn't really make a difference.
        stcredzero 8y ago
        Technical debt doesn't accrue in a linear fashion. Instead, it's synergistic. Up to a certain point, it's a noticeable drag. Past that point, there is a change in the difficulty incurred. In the article, the combination of some "you're-supposed-to-just-not-do-that" with: >If (the database throws an error) { do nothing } resulted in a major mishap.
    - T2_t2 8y ago
      I think the implication is that they achieved the goal they had, to grow a company. Note that goal doesn't mention code at all. It depends what you think software engineering is - a means to an end, e.g. to grow a company, or as a craft you want to perfect and do for your whole career. I think there are more craft coders, because most jobs are at companies that have survived and there is more to lose from errors than gain from moving fast. The craft attitude may not be ideal when you want to go from zero to something, and avoid going back to zero very quickly. Or, perhaps more importantly, if you want to go from zero -> something wrong -> something wrong again -> something almost correct -> Product Market fit.
  - jschwartzi 8y ago
    The point is that engineering decisions need to involve both the business and the technical side of things, and they need to be pragmatic and not tied to any particular dogma from either world.
- mabbo 8y ago
  That's not skill, that's luck. If the bug in question had instead leaked every customer's personal data there wouldn't be a $50m company, there'd be a multi-million dollar lawsuit.
  - TeMPOraL 8y ago
    I agree with your thinking, but with this particular example: you'd wish. See: every other data leak that happened over the last decade. It seems data leaks are harmless to companies.
    - laurent123456 8y ago
      I was going to say "not for a dating website", but I see that Ashley Madison still exists despite the massive data leak in 2015 including data from users who had paid to have their data deleted, so yes looks like there's no real fallback for data leaks.
- JackFr 8y ago
  Created a product worth $50M because of their software process or despite there software process.
merlincorey 8y ago
I washed out of their interview process when I was fresh out of high school for not knowing bit twiddling hacks[1] in the technical phone screen with one of their engineers. After reading this, I can't help but feel like I dodged a bullet there. [1] https://graphics.stanford.edu/~seander/bithacks.html https://graphics.stanford.edu/~seander/bithacks.html
- gwbas1c 8y ago
  Don't feel bad: I cut the phone screen short about 25 minutes into it. I just got a really bad vibe about all of the front-end complexity they were building into a dating site.
swalsh 8y ago
It's a free dating service. They have a responsibility to respect their users' data privacy, but the rest kind of doesn't matter. Eventual stability is more profitable than eventual release if you're not a Bank or making self driving cars.
- skybrian 8y ago
  Yeah, I expect the devs at Ashley Madison told themselves that too. It's possible to build sandboxes where security or privacy bugs are contained, but the shops that don't care much about software quality are probably not doing that. It seems a little too easy for people building a social app to tell themselves they're just building a toy that doesn't matter. Their users might disagree after they get hacked.
KingMob 8y ago
I'm sure the OkCupid folk are nice people but it was: 1) founded by mathematicians and an academic, and 2) written in C++, with a custom templating language Even giving them the benefit of the doubt that the core matching algorithm warranted C++, the whole site really shouldn't have been built that way. I'm really not surprised there's poor technical decision-making there.
ddebernardy 8y ago
Outrageously unprofessional as it may be, they probably ended up laughing on their way to the bank when they got purchased by match.com.
toast0 8y ago
> That's an outrageously unprofessional software process. People who call me unprofessional forget that being a professional just means I'm paid to do it, it's not a pass time.
megaman8 8y ago
You have to judge it in context. If it's entirely a senior team then the value of code reviews is greatly diminished. You rarely catch a bug in a bug review when you're reviewing a Senior software engineer's code. those bugs aren't caught until you do testing.
- nradov 8y ago
  I've seen plenty of defects in senior developers' code that were caught in reviews. Please the purpose of code reviews isn't just to catch defects, it's also to disseminate knowledge of that module across the team in order to reduce the "bus factor".
chasd00 8y ago
it worked well enough until they could do something better. Never let perfect be the enemy of good.
tluyben2 8y ago
In my experience this ‘outrageously unprofessional‘ process is very normal. Most companies are not software companies and they are not going to pay for whatever is not adding to the bottomline. And even in software companies that ofcourse happens. It is unfortunate but the shock and awe are a bit over the top; when I talk with partners (ctos is large corps; banks, insurance, retail), they generally glaze over and mumble about their dreams of doing tests and code reviews but unfortunately it is not possible ‘at the moment’.

by JackFr 8y ago

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.

danesparza 8y ago

I was immediately struck by the same set of thoughts. I don't know whether to be appalled or just ... sad.

andrenotgiant 8y ago

An outrageously unprofessional software process that created a product worth $50M! https://techcrunch.com/2011/02/02/match-com-acquires-online-dating-site-okcupid-for-50-million-in-cash/ https://techcrunch.com/2011/02/02/match-com-acquires-online-...

danesparza 8y ago
The OP is about technical process in the software world. I'm not sure how a company's valuation comes into the conversation...
- blacksmith_tb 8y ago
  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...
  - stcredzero 8y ago
    Given that technical debt is quite hard for non-technical people to quantify, why wouldn't we expect that most startups would tend to accrue technical debt?
    - theseatoms 8y ago
      Can anyone quantify technical debt? Best case is something resembling a medical diagnosis.
      - stcredzero 8y ago
        I think that could be enough. Actuaries have a good idea about when you are likely to die in the next two years. Basically, when you are old and your medical costs suddenly double. Doctors use the same sort of inductive reasoning for their prognosis. The industry probably collectively has all the information to put together useful actuarial tables on technical debt, but it's all silo'd in individual companies.
        theseatoms 8y ago
        Interesting. Are there IT consulting firms that specialize in this field of study?
    - adrianN 8y ago
      Startups accrue so much financial debt, adding some technical debt on top doesn't really make a difference.
      - stcredzero 8y ago
        Technical debt doesn't accrue in a linear fashion. Instead, it's synergistic. Up to a certain point, it's a noticeable drag. Past that point, there is a change in the difficulty incurred. In the article, the combination of some "you're-supposed-to-just-not-do-that" with: >If (the database throws an error) { do nothing } resulted in a major mishap.
  - T2_t2 8y ago
    I think the implication is that they achieved the goal they had, to grow a company. Note that goal doesn't mention code at all. It depends what you think software engineering is - a means to an end, e.g. to grow a company, or as a craft you want to perfect and do for your whole career. I think there are more craft coders, because most jobs are at companies that have survived and there is more to lose from errors than gain from moving fast. The craft attitude may not be ideal when you want to go from zero to something, and avoid going back to zero very quickly. Or, perhaps more importantly, if you want to go from zero -> something wrong -> something wrong again -> something almost correct -> Product Market fit.
- jschwartzi 8y ago
  The point is that engineering decisions need to involve both the business and the technical side of things, and they need to be pragmatic and not tied to any particular dogma from either world.
mabbo 8y ago
That's not skill, that's luck. If the bug in question had instead leaked every customer's personal data there wouldn't be a $50m company, there'd be a multi-million dollar lawsuit.
- TeMPOraL 8y ago
  I agree with your thinking, but with this particular example: you'd wish. See: every other data leak that happened over the last decade. It seems data leaks are harmless to companies.
  - laurent123456 8y ago
    I was going to say "not for a dating website", but I see that Ashley Madison still exists despite the massive data leak in 2015 including data from users who had paid to have their data deleted, so yes looks like there's no real fallback for data leaks.
JackFr 8y ago
Created a product worth $50M because of their software process or despite there software process.

merlincorey 8y ago

I washed out of their interview process when I was fresh out of high school for not knowing bit twiddling hacks[1] in the technical phone screen with one of their engineers. After reading this, I can't help but feel like I dodged a bullet there. [1] https://graphics.stanford.edu/~seander/bithacks.html https://graphics.stanford.edu/~seander/bithacks.html

gwbas1c 8y ago
Don't feel bad: I cut the phone screen short about 25 minutes into it. I just got a really bad vibe about all of the front-end complexity they were building into a dating site.

swalsh 8y ago

It's a free dating service. They have a responsibility to respect their users' data privacy, but the rest kind of doesn't matter. Eventual stability is more profitable than eventual release if you're not a Bank or making self driving cars.

skybrian 8y ago
Yeah, I expect the devs at Ashley Madison told themselves that too. It's possible to build sandboxes where security or privacy bugs are contained, but the shops that don't care much about software quality are probably not doing that. It seems a little too easy for people building a social app to tell themselves they're just building a toy that doesn't matter. Their users might disagree after they get hacked.

KingMob 8y ago

I'm sure the OkCupid folk are nice people but it was: 1) founded by mathematicians and an academic, and 2) written in C++, with a custom templating language Even giving them the benefit of the doubt that the core matching algorithm warranted C++, the whole site really shouldn't have been built that way. I'm really not surprised there's poor technical decision-making there.

ddebernardy 8y ago

Outrageously unprofessional as it may be, they probably ended up laughing on their way to the bank when they got purchased by match.com.

toast0 8y ago

> That's an outrageously unprofessional software process. People who call me unprofessional forget that being a professional just means I'm paid to do it, it's not a pass time.

megaman8 8y ago

You have to judge it in context. If it's entirely a senior team then the value of code reviews is greatly diminished. You rarely catch a bug in a bug review when you're reviewing a Senior software engineer's code. those bugs aren't caught until you do testing.

nradov 8y ago
I've seen plenty of defects in senior developers' code that were caught in reviews. Please the purpose of code reviews isn't just to catch defects, it's also to disseminate knowledge of that module across the team in order to reduce the "bus factor".

chasd00 8y ago

it worked well enough until they could do something better. Never let perfect be the enemy of good.

tluyben2 8y ago

In my experience this ‘outrageously unprofessional‘ process is very normal. Most companies are not software companies and they are not going to pay for whatever is not adding to the bottomline. And even in software companies that ofcourse happens. It is unfortunate but the shock and awe are a bit over the top; when I talk with partners (ctos is large corps; banks, insurance, retail), they generally glaze over and mumble about their dreams of doing tests and code reviews but unfortunately it is not possible ‘at the moment’.