Daily links for the end of the week.

  • Founder Confidence

    “Unfortunately for entrepreneurs, the market doesn’t reset next season. The place you sit and the trajectory you are on, can be very, very difficult to change. Shifting expectations from winning to justifying your place in the market, rarely re-instills confidence.”

    That applies to everyone!

  • Q: Why are banks organised in product silos? A: McKinsey
  • Reasoning, responsibility and run off

    “For my money, Circuit Paul Ricard has had things right for the last decade. High abrasion run-off. But take it up a notch. Coat the run-off areas in such a high abrasion surface that it will not cause punctures or deflation, but will scrub enough rubber off as to ruin that set of tyres. Put a wheel off, let alone all four, and you’ve got to come in and get them changed.


    No more keeping your foot in. No more making up positions. No more taking just a few inches more than you should. Keep it on track, inside the white lines.”

    This applies to more than just F1. The environment you set up (whether physical or otherwise) governs what people will do. As Clinton/Deming would (sorta) say: “It is the system, stupid.”

  • Exacto demonstrates first ever guided .50 calibre bullets – remote control bullets from DARPA!
  • Everyone is obviously right – you have to look at this. I am obviously right.
  • Wolfram Programming Cloud
  • What qualities make a good startup engineer – the first line is important:

    “Not every good engineer makes a good startup engineer.”

    I guess that will be counter-intuitive to many, especially those who simply see “resources” instead of “people” and who think engineers are fungible.

Daily Links: 7-1!!!!!

Daily Links: p2p insurance, a driver and “ethics”

  • Hey Guevara – peer to peer insurance. Just like it used to be in the old days of the Lloyds first coffee house. Shame the site is a bit too hipsterish for me: lots of cool UI, just a shame it doesn’t show me what I want to know straight away. The typo’s all over the place aren’t great either. That said, I LOVE the concept!
  • British Grand Prix: It was a really tough day – Susie Wolff – great to see Susie Wolff being given the chance to have a go in an F1 session. Real shame the car had issues.
  • Research ethics – couldn’t have put it better myself. I don’t have a facebook account because I made the decision, years ago, that I did not want someone else to curate my feeds for me. I find it genuinely astounding that people don’t realise that “their” facebook (or pretty much any other site) is being manipulated on a daily basis for a multitude of reasons.

Daily Links – 3rd July 2014

  • Putting teeth in our public cloud – building out OnMetal @ Rackspace.
  • Challenges in Designing at Scale: Formal Methods in Building Robust Distributed Systems – I think it is the law to post anything James Hamilton puts out!
  • Use of Formal Methods at Amazon Web Services – the stuff that James is talking about in the previous link.
  • The Scientific Problem That Must Be Experienced – turbulence.

    “This transition to turbulence doesn’t happen at the same flow speed for all fluids—more viscous ones can be “kept in line” at higher speeds than runny ones. For flow down a channel or pipe, a quantity called the Reynolds number determines when turbulence appears. Roughly speaking, this encodes the ratio of the flow speed to the viscosity of the fluid. Turbulence develops at high values of the Reynolds number.”

    What is the equivalent concept to viscosity in the product development “flow”? Is there one? If you can find an organisational construct that allows product and engineering teams to be more “viscous” then does that mean that they will have a higher flow (i.e. product delivery) rate?

Daily Links – 2nd July 2014

  • Machine Learning Communities
  • The Elephant was a Trojan Horse: On the Death of Map-Reduce at Google

    “If we are in a data revolution right now, the computational advance that made it possible was not the ‘discovery’ of Map-Reduce, but instead the realisation that these computing systems can and should be built from relatively cheap, shared-nothing machines (and the real contribution from Google in this area was arguably GFS, not Map-Reduce).”

    I think people forget what it was like to be arguing for cheap, shared-nothing machines a decade ago. You were looked on as if you were mad. More than mad. Delusional. It was the talk of crackpots because everyone “knew” how you built “proper” systems. Except they didn’t. On the plus side I got to see what being thought of as a crackpot was like for a decade!

Daily link

  • MH370 – Definition of underwater search areas
  • Search for the Wreckage of Air France Flight AF 447
  • Google papers – 2013
  • Stop producing chaos

    “Companies often suffer high levels of rework and scrap simply because they do not have a clear understanding of the state of control of their process and their capabilities. This can lead to fragmentation of the quality effort and confusion across the organisation – Engineering is frequently at loggerheads with Manufacturing over the setting of specifications which are too often set without reference to the state of control of processes or their potential ability to meet the specs.”

    It is talking about manufacturing process control but it got me wondering about the implications for software development – do you build the “right” system or the one that you are actually capable of building?

Daily Link

Daily Link

  • Minimal Viable Bureaucracy
  • Lock your knees – Habit change is hard. “While the initial trigger (or motivation) is the catalyst that starts the ball rolling, for the change to really manifest into habit forming behavior, you need periodic and regular triggers that keep bringing you back to the specific activity.”
  • Ferrari restructuring must allow engineers to be creative. – Winning, like continuous deployment or any other software activity, is a habit and habits must be formed and maintained. “Ferrari has lost the winning habit and he needs to recreate the culture that existed there under Jean Todt.”
  • Apache Mesos – Cluster management.
  • Erlang 17.1 is out – or via Erlang Solutions.
  • Jim Barksdale quotes:

    “If it works, it’s a product. If it doesn’t, it’s market research.”

    “In the battle between the bear and the alligator, what determines the victor is the terrain.”

  • Creating the future
    “Everything we see is the result of someone, at some point, wondering ‘Wouldn’t it be nice if…?’ or ‘I wonder if….? and they had the guts and the courage to go for it.”
    “We cannot programme our GPS to a destination that doesn’t exist.”

    In talking to a senior executive at a Fortune 500 company about a promotion to VP that the executive doesn’t want to take because of all that accepting the VP position would require:
    Executive: If I say no it will ruin my career
    Gerald: But if you say yes it will ruin your life, which is worse?

  • Site Reliability Engineering

    “The solution that we have in SRE — and it’s worked extremely well — is an error budget. An error budget stems from this basic observation: 100% is the wrong reliability target for basically everything. Perhaps a pacemaker is a good exception! But, in general, for any software service or system you can think of, 100% is not the right reliability target because no user can tell the difference between a system being 100% available and, let’s say, 99.999% available. Because typically there are so many other things that sit in between the user and the software service that you’re running that the marginal difference is lost in the noise of everything else that can go wrong.

    If 100% is the wrong reliability target for a system, what, then, is the right reliability target for the system? I propose that’s a product question. It’s not a technical question at all. It’s a question of what will the users be happy with, given how much they’re paying, whether it’s direct or indirect, and what their alternatives are.

    The business or the product must establish what the availability target is for the system. Once you’ve done that, one minus the availability target is what we call the error budget; if it’s 99.99% available, that means that it’s 0.01% unavailable. Now we are allowed to have .01% unavailability and this is a budget. We can spend it on anything we want, as long as we don’t overspend it”