Posts for Quote Category

One of the smartest articles on software development and what it means that I’ve read:

Software is different. Just by editing the text in a file somewhere, the same hunk of silicon can become an autopilot or an inventory-control system. This flexibility is software’s miracle, and its curse. Because it can be changed cheaply, software is constantly changed; and because it’s unmoored from anything physical—a program that is a thousand times more complex than another takes up the same actual space—it tends to grow without bound. “The problem,” Leveson wrote in a book, “is that we are attempting to build systems that are beyond our ability to intellectually manage.”

Our standard framework for thinking about engineering failures—reflected, for instance, in regulations for medical devices—was developed shortly after World War II, before the advent of software, for electromechanical systems. The idea was that you make something reliable by making its parts reliable (say, you build your engine to withstand 40,000 takeoff-and-landing cycles) and by planning for the breakdown of those parts (you have two engines). But software doesn’t break…[In the case of major failures such as with Intrado:] The software did exactly what it was told to do. In fact it did it perfectly. The reason it failed is that it was told to do the wrong thing. Software failures are failures of understanding, and of imagination…

This is the trouble with making things out of code, as opposed to something physical. “The complexity,” as Leveson puts it, “is invisible to the eye.”

Another one of my favorite posters at Facebook declares in big red letters, “Done is better than perfect.” I have tried to embrace this motto and let go of unattainable standards. Aiming for perfection causes frustration at best and paralysis at worst. I agree completely with the advice offered by Nora Ephron in her Wellesley commencement speech when she addressed the issue of women having both a career and family. Ephron insisted, “It will be a little messy, but embrace the mess. It will be complicated, but rejoice in the complications. It will not be anything like what you think it will be like, but surprises are good for you. And don’t be frightened: you can always change your mind. I know: I’ve had four careers and three husbands.

Taleb believes in tinkering – it was to be the title of his next book. Trial and error will save us from ourselves because they capture benign black swans. Look at the three big inventions of our time: lasers, computers and the internet. They were all produced by tinkering and none of them ended up doing what their inventors intended them to do. All were black swans. The big hope for the world is that, as we tinker, we have a capacity for choosing the best outcomes.

“We have the ability to identify our mistakes eventually better than average; that’s what saves us.” We choose the iPod over the Walkman. Medicine improved exponentially when the tinkering barber surgeons took over from the high theorists. They just went with what worked, irrespective of why it worked. Our sense of the good tinker is not infallible, but it might be just enough to turn away from the apocalypse that now threatens Extremistan.

1) All teams will henceforth expose their data and functionality through service interfaces.

2) Teams must communicate with each other through these interfaces.

3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.

5) All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.

6) Anyone who doesn’t do this will be fired…

There are without question pros and cons to the SOA approach, and some of the cons are pretty long. But overall it’s the right thing because SOA-driven design enables Platforms…

A product is useless without a platform, or more precisely and accurately, a platform-less product will always be replaced by an equivalent platform-ized product.

My excerpts are shit. Taking so much of the personal observations out of it. Read the whole thing. It’s an incredibly insightful piece of writing. A few years later, I read another angle of this from Brad Stone in his The Everything Store:

In the engineering department, employees were constantly trying to fix a technical infrastructure that was now an aging, sprawling mess. The company had outgrown the original framework devised by Shel Kaphan in the 1990s, the monolithic code base dubbed Obidos that for years was held together by what Amazon executive Werner Vogels later called “duct tape and WD40 engineering.” And when Amazon cloned its clunky code base to run the websites of Target and Borders, those deals were lucrative but they magnified the company’s infrastructure problems. Instead of fighting flames emanating from a single building, engineers often had to deal with a neighborhoodwide inferno.

Like a lot of other technology companies at the time, Amazon got an education in the wisdom of moving to a simpler and more flexible technology infrastructure, called service-oriented architecture. In this kind of framework, every feature and service is treated as an independent piece and each can easily be updated or replaced without breaking the whole.

Led by Amazon’s chief technology officer at the time, an avid pilot named Al Vermeulen, whom colleagues fondly called Al V., the company rebuilt its technology infrastructure as a series of these independent but interconnected parts. The awkward and extended transition to this new code base, one element of which Amazon called Gurupa (after a section of the Amazon river where the tributaries diverged), took over three years and caused all kinds of excruciating pain…

“I’m a firm believer in the chaotic nature of the creative process needing to be chaotic. If we put too much structure on it, we will kill it. So there’s a fine balance between providing some structure and safety—financial and emotional—but also letting it get messy and stay messy for a while. To do that, you need to assess each situation to see what’s called for. And then you need to become what’s called for.”

Building 20 was a “hastily erected” wooden building at MIT during World War II as an emergency war measure to house the scientists collaborating to work on technology for the war. It was always considered “temporary” during it’s 50+ years of existence and never received a formal name. But it housed some of the world’s greatest scientists who had breakthrough after breakthrough while working in this ramshackle building. In his meandering but insightful exposition on how disorder has often led to great things, Tim Hartford including Building 20 as one of his prime examples, pointing to the building’s hodge podge of different scientific disciplines, to the poorly thought out office numbering which lead to people getting lost

This absurdly inefficient way of organizing a building meant that people were constantly getting lost and wandering into places they didn’t intend to go. Better still, because Building 20 was low-rise and sprawling, when chance meetings occurred, they didn’t happen in elevators, the eternal home of the glib, tidy monologue we call the “elevator pitch.” They began in long corridors, where a genuine conversation could develop.

More important, the combination of people who could have those conversations was strange and wonderful. In the early 1950s, Building 20 contained departments that were wartime holdovers—nuclear science, flight control, the “Guided Missiles Program Office”—but also plastics research, the adhesives lab, the acoustics lab, the electronics lab, and even an outpost of the architecture department: a lighting design shop…

This unlikely mess made possible chance interactions among innovative researchers that paid such spectacular dividends. Who would have guessed that throwing the electrical engineers in with the Model Railway Club would result in hacking and video games? Or that the electronics specialists, the music department, and the acoustics lab would end up spawning technology pioneers such as the Bose Corporation and Bolt, Beranek and Newman? Nobody would have guessed, and nobody tried to guess, either. The hodgepodge of Building 20 was the result of simple expedience and neglect…

But also important, perhaps more so, was that the building’s occupants felt empowered to make changes:

Another key element of Building 20’s success was that the space was easy to reconfigure. Its services—water, phones, electricity—were exposed, running along the corridor ceilings, supported by brackets. This was ugly but convenient. Researchers thought nothing of tapping into them directly for whatever experimental needs they had. Paul Penfield, a longtime occupant of Building 20, recalled: “You know that if you want to run a wire from one room to another, you don’t call Physical Plant, you don’t plunk down a thousand dollars to call an electrician and a carpenter, instead you get out a power drill or a screwdriver, and you jam it through the wall, and you string the wire, and you take care of things right away, and you do it in one afternoon, rather than waiting six months for a purchase order to come through.” …

Building 20’s true advantage wasn’t so much that it was reconfigurable by design, but that the building’s inhabitants felt confident that they had the authority (if only by default) to make changes, even messy changes. It was that it was so cheap and ugly that in the words of Stewart Brand, author of How Buildings Learn, “Nobody cares what you do in there.”

Lazaridis had a blueprint inspired by Clayton Christensen’s acclaimed 1997 management book, The Innovator’s Dilemma. The Harvard professor argued that for established companies to succeed against disruptive competitors, they had to empower small, cloistered teams. These autonomous groups, unsullied by the parent company’s set ways, would develop disruptive technologies of their own and could eventually subsume other parts of the organization. It was tumultuous but necessary to stay at the forefront of innovation.

Dyson mentions this while explaining how pulse-coded IFF (Identification Friend or Foe) radar systems were developed during World War II. Defensive systems had relied upon someone visually seeing a plane approaching, and then the person who saw it identifying if it were an enemy or not, before deciding to shoot. Radar made it possible to hit objects out of visual range, and immediately led to a number of friendly fire incidents. This led then to the development of pulse-coded responses to radar that allowed planes of each side to be identified.

For all the times people say, “I had that idea first…” or…my original insight was to do what everyone else was doing, (but better!)… There’s one thing that all technology entrepreneurs seem to agree on… Ideas aren’t enough for success.

The foundation of success is the right team and good timing:

Ideas without implementation, or without an exceptional team to implement them, are like assholes and opinions: everyone’s got one.

For the past 5 years at TransPerfect, I’ve been empowered to run an intrapreneurial team (the term makes me cringe, but it fits) creating solutions that have helped the different pieces of the company communicate and do their work. This is the extraordinary thing compared to what I’ve heard from many of my friends: there wasn’t some managerial dictat that the projects I worked on should be done. (Many of the most impactful projects I worked on were side projects that I came across because of a chance conversation.)

I was entrusted by my manager to find opportunities, things that weren’t efficient – and to spend some time and resources getting something done. And it worked. Today, nearly 70% of the company’s work has at least 1 workflow step (sometimes as many as 10) go through products my team has built and we run one of the company’s flagship properties, TransPort.

Having the idea though accomplished little. Ideas always evolve as they are implemented. The success that I’ve been able to have isn’t because I had ideas – but because of the team I’ve been lucky enough to work with – from my core team members, to being empowered by senior management, to the extended network of technology, production, and sales that have been part of every success.

This has been the core of my success, and I would wager, of the company’s success in general.

Here is a key insight for any startup: You may think yourself a puny midget among giants when you stride out into a marketplace, and suddenly confront such a giant via litigation or direct competition. But the reality is that larger companies often have much more to fear from you than you from them.

For starters, their will to fight is less than yours. Their employees are mercenaries who don’t deeply care, and suffer from the diffuse responsibility and weak emotional investment of a larger organization. What’s an existential struggle to you is merely one more set of tasks to a tuned-out engineer bored of his own product, or another legal hassle to an already overworked legal counsel thinking more about her next stock-vesting date than your suit.

Also, large companies have valuable public brands they must delicately preserve, and which can be assailed by even small companies such as yours, particularly in a tight-knit, appearances-conscious ecosystem