Allen Holub

You can't just inject after-the-fact "security" into a system because you can't inject quality into a system. Both characteristics infuse the code. The only way to make an insecure system secure is to replace that code with high-quality code. Band-aids don't work.
2/2

I will never understand how people do not see the tight coupling of security and quality. You can't have the former without the latter. They call it an "exploit" because the hacker is exploiting a bug.
1/2

Yes. I was CTO at an internet-security infrastructure company, so this comment hits a nerve with me. I will never understand how people do not seem to understand the tight coupling of security and quality. You can't have the former without the latter.

It's actually Mark Zuckerberg who said that. He wasn't quoting anybody. He was the boss, in fact, not just another engineer. He also said: "Unless you are breaking stuff, you are not moving fast enough."

I once had a conversation with Steve Ballmer on precisely this subject. For him, it was a business decision. Given their quasi-monopoly position, why spend money on quality if it doesn't impact revenue? Can't fault that reasoning. Pre-monopoly products were higher quality.

It depends on the architecture. In a system of components w/ hard boundaries (e.g., microservices), every component has its own database. An authentication component needs nothing beyond key/value pairs at first. You won't need to replace that with a database unless the number of users requires it.

Actually, the problem with Challenger, at least according to the official report, was not saving money; it was about slipping boundaries. You push something to the limit, and it still works, so that limit becomes the new center. Repeat that process, and things blow up.

California is not the only government bogged under bureaucracy. It goes with the territory.

Beta testing is a big-batch concept. You beta-tested the entire application (before burning it to a CD 😄). When the batches are very small and the code is well tested, you're determining whether the users find something useful. To me, siloing dev and prod is a bad idea. Product + DevOps for the win.

It helps to be a monopoly.

In general, pure research (of the "Design Thinking" variety, for example) doesn't yield particularly good results. People tend to need something that works in front of them to assess adequately. Otherwise, they're just guessing. Tiny released increments work better.

Solar panels won't work unless you're located in a desert and can blanket many square miles with panels. Of existing technologies that are ready to go, safe nuclear is a better option (e.g. liquid-salt thorium). Hydro can work given a big enough river. Microsoft bought Three-Mile Island, of course.

So, I’m not sure about breaking things, but building fast is always a good idea. You just have to go about doing it sensibly.
12/12

I’ve often released a small thing devoid of most of the features and bells and whistles I thought I needed, and the feedback was “this is great!” At that point, I’m done. Those bells and whistles were cruft. Build the thing that alleviates the most pain first, then get feedback.
11/12

The most dramatic speed improvements come from not building entire features that nobody wants. Work very small to get code into your customer’s hands as quickly as possible, and then get feedback from them in a continuous conversation. Why build things nobody cares about?
10/12

You do not need an architecture or infrastructure that supports 100,000 users until you have 100,000 users. You do need an incremental-friendly architecture--one that can evolve as it scales. Eminently doable, but it’s a learned skill.
9/12

If you have 100 customers, for example, you probably don’t need a database—a flat file with JSON in it will do. You almost certainly don’t need that slick UI (you need a good UX, but you can often get that with a very simple UI).
8/12

Whole-team development—where all the skills needed to get something out the door are available within the team—eliminates dependency delays.

The next set of speed improvements comes from not building infrastructure you don’t need.
7/12

The first is to change the way you work. Traditional Lean thinking—remove waste; work on one thing at a time (reduce WIP to 1)—cuts development time in half or more. Working collaboratively (e.g., mob/ensemble programming) eliminates coordination and integration overhead.
6/12

Also, buggy systems drive customers away. No startup can afford that. Buts erode trust, and attempts to regain that trust by releasing a slightly less buggy version in a month are doomed. People have long memories.

There are constructive ways to move fast, though.
5/12

Every change to buggy code is painful (and time-consuming), particularly when you have no tests because you have “no time to write them.” You have no time not to write them. The best way to move fast is to increase quality and be serious about testing.
4/12

Fast gets you two essential things: you get revenue sooner, and you get the feedback you need to ensure you’re building something the market actually wants.

“Move fast” doesn't mean: get low-quality buggy garbage out the door faster. That slows you down.
3/12

Even if you’re a startup, though, breaking things makes no sense at all unless you’re talking about breaking the status quo in a moribund product space. Who has time to fix broken stuff?

"Move fast” is more interesting.
2/12

Let’s talk about “Move fast and break things.” First of all, Facebook itself changed its motto to “Move fast with stable infrastructure” in 2014. So much for breaking things, at least if you’re a soulless corporate behemoth.
1/12

Wow. It's interesting that you go there. How about "any way," as in realizing the precepts of the Agile Manifesto and Lean thinking, or working collaboratively, or creating humane work conditions?

Not if you move fast by, for example, not building unnecessary stuff. There are lots of ways to move fast. Organizations that take "sustainable pace" seriously (e.g., no long hours, etc.) move faster than those that burn people out. Fast isn't the problem; bad management is.

It was not convenience, it was cost. Many startups would never have succeeded if they had to run their own data centers. There are benefits of putting everybody's computer in one place. Overall, it uses less power than a large number of small data centers, for example.

Not just them, though. People aren't talking enough about the environmental cost of AI, though the need for power could drive clean-tech solutions like liquid-salt thorium reactors.

Even if we don't break things, moving fast is still essential. Time, quite literally, is money when you're doing development. It's also not just about profit. E.g., we need rapid feedback from small increments—difficult for stand-alone, non-cloud systems.

Didn't Microsoft just effectively force you to put all your data in the cloud? Even if it's still on the disk, it's so well hidden you can't find it.