Cultivate is O'Reilly's conference committed to training the people who will lead successful teams, now and in the future.
Attend Cultivate July 20 and 21, in Portland, Oregon. Cultivate is our conference looking at the challenges facing modern management and aiming to train a new generation of business leaders who understand the relationship between corporate culture and corporate prosperity.
Leadership has changed — and in a big way — since the Web started upending the status quo two decades ago. That’s why we’re launching our new Cultivate event; we realized that businesses need new types of leaders, and that O’Reilly is uniquely positioned to help engineers step up to the job.
At the start of the 21st century, Google was in its infancy; Facebook didn’t exist; and Barnes & Noble, not Amazon, was the dominant force in the book industry. As we’ve watched these companies grow, we’ve realized that every business is a software business, and that the factors that made Google, Facebook, and Amazon successful can be applied outside the Web. Every business, from your dentist’s office to Walmart, is critically dependent on software. As Marc Andreessen put it, software is eating the world.
As companies evolve into software businesses, they become more dependent on engineers for leadership. But an engineer’s training rarely includes leadership and management skills. How do you make the transition from technical problems to management problems, which are rarely technical? How do you become an agent for growth and change within your company? And what sorts of growth and change are necessary?
The slogan “every business is a software business” doesn’t explain much, until we think about how software businesses are different. Software can be updated easily. It took software developers the better part of 50 years to realize that, but they have. That kind of rapid iteration is now moving into other products. Read more…
The real challenge going forward: we can't trust anything.
A few weeks ago, I wrote about postmodern computing, and characterized it as the computing in a world of distrust.
This morning, I read Steve Bellovin’s blog post, What Must We Trust? — Bellovin explains that “modern” (my word) security is founded on the idea of a “Trusted Computing Base” (TCB), defined (in part) in the United States’ Defense Department’s Orange Book. There were parts of a system that you had to trust, and you had to guard their integrity vigilantly: the kernel, certainly, but also specific configuration files, executables, and so on.
The TCB has always been problematic, particularly since (at least initially) it did not consider the problem of network connections. But networking aside, Bellovin argues that recent events have blown the idea of a “trusted” system to bits. We’ve seen attacks against (Bellovin’s list) batteries, webcams, USB, and more. If Andromedans (Bellovin doesn’t want to say NSA) have managed to infiltrate our disk drives, what can trust mean? And it would be naive to think that this stops with devices that have disk drives. Our devices, from Fitbits to data centers, have been pwnd even before they’re built. Read more…
Empathy, communication, and collaboration across organizational boundaries.
I might try to define DevOps as the movement that doesn’t want to be defined. Or as the movement that wants to evade the inevitable cargo-culting that goes with most technical movements. Or the non-movement that’s resisting becoming a movement. I’ve written enough about “what is DevOps” that I should probably be given an honorary doctorate in DevOps Studies.
Baron Schwartz (among others) thinks it’s high time to have a definition, and that only a definition will save DevOps from an identity crisis. Without a definition, it’s subject to the whims of individual interest groups, and ultimately might become a movement that’s defined by nothing more than the desire to “not be like them.” Dave Zwieback (among others) says that the lack of a definition is more of a blessing than a curse, because it “continues to be an open conversation about making our organizations better.” Both have good points. Is it possible to frame DevOps in a way that preserves the openness of the conversation, while giving it some definition? I think so.
DevOps started as an attempt to think long and hard about the realities of running a modern web site, a problem that has only gotten more difficult over the years. How do we build and maintain critical sites that are increasingly complex, have stringent requirements for performance and uptime, and support thousands or millions of users? How do we avoid the “throw it over the wall” mentality, in which an operations team gets the fallout of the development teams’ bugs? How do we involve developers in maintenance without compromising their ability to release new software?
What the future of science will look like if we’re bold enough to look beyond centuries-old models.
Over the last six months, I’ve had a number of conversations about lab practice. In one, Tim Gardner of Riffyn told me about a gene transformation experiment he did in grad school. As he was new to the lab, he asked two more experienced scientists for their protocol: one said it must be done exactly at 42 C for 45 seconds, the other said exactly 37 C for 90 seconds. When he ran the experiment, Tim discovered that the temperature actually didn’t matter much. A broad range of temperatures and times would work.
In an unrelated conversation, DJ Kleinbaum of Emerald Cloud Lab told me about students who would only use their “lucky machine” in their work. Why, given a choice of lab equipment, did one of two apparently identical machines give “good” results for a some experiment, while the other one didn’t? Nobody knew. Perhaps it is the tubing that connects the machine to the rest of the experiment; perhaps it is some valve somewhere; perhaps it is some quirk of the machine’s calibration.
The more people I talked to, the more stories I heard: labs where the experimental protocols weren’t written down, but were handed down from mentor to student. Labs where there was a shared common knowledge of how to do things, but where that shared culture never made it outside, not even to the lab down the hall. There’s no need to write it down or publish stuff that’s “obvious” or that “everyone knows.” As someone who is more familiar with literature than with biology labs, this behavior was immediately recognizable: we’re in the land of mythology, not science. Each lab has its own ritualized behavior that “works.” Whether it’s protocols, lucky machines, or common knowledge that’s picked up by every student in the lab (but which might not be the same from lab to lab), the process of doing science is an odd mixture of rigor and folklore. Everybody knows that you use 42 C for 45 seconds, but nobody really knows why. It’s just what you do.
Despite all of this, we’ve gotten fairly good at doing science. But to get even better, we have to go beyond mythology and folklore. And getting beyond folklore requires change: changes in how we record data, changes in how we describe experiments, and perhaps most importantly, changes in how we publish results. Read more…
BioCoder 6: iGEM's first Giant Jamboree, an update from the #ScienceHack Hack-a-thon, the Open qPCR project, and more.
Once again, we’re interested in your ideas and in new content, so if you have an article or a proposal for an article, send it in to BioCoder@oreilly.com. We’re very interested in what you’re doing. There are many, many fascinating projects that aren’t getting media attention. We’d like to shine some light on those. If you’re running one of them — or if you know of one, and would like to hear more about it — let us know. We’d also like to hear more about exciting start-ups. Who do you know that’s doing something amazing? And if it’s you, don’t be shy: tell us.
Above all, don’t hesitate to spread the word. BioCoder was meant to be shared. Our goal with BioCoder is to be the nervous system for a large and diverse but poorly connected community. We’re making progress, but we need you to help make the connections.
Marco Arment did an excellent job of offering constructive criticism to a company that he genuinely loves.
The point he made is one I’ve tweeted about (though not written about) a number of times over the years. The big problem facing Apple isn’t a deficit of innovation, but bitrot creeping into their codebase. You don’t have to look far to see it: for example, there’s a race condition in text handling that has been there since at least OS X 10.3.
The point needed to be made by someone who knows and loves Apple, someone who is a leader in their developer community, and someone who has a reputation for being fair and even-handed. That’s Marco. He did an excellent job of offering constructive criticism to a company that he genuinely loves.
Yes, there is a risk that anything you write will turn into a media storm. That’s a risk you have to live with; it’s unfortunate, but it’s not going away. It’s also important to say what needs to be said. Self-censorship is not the way forward. Read more…
A look at what lies ahead in the disenchanted age of postmodern computing.
Sometime last summer, I ran into the phrase “postmodern computing.” I don’t remember where, but it struck me as a powerful way to understand an important shift in the industry. What is different in the industry? How are 2014 and 2015 different from 2004 and 2005?
If we’re going to understand what “postmodern computing” means, we first have to understand “modern” computing. And to do that, we also have to understand modernism and postmodernism. After all, “modern” and “postmodern” only have meaning relative to each other; they’re both about a particular historical arc, not a single moment in time.
Some years back, I was given a history of St. Barbara’s Greek Orthodox Church in New Haven, carefully annotated wherever a member of my family had played a part. One story that stood out from early in the 20th century was AHEPA: the American-Hellenic Progressive Association. The mere existence of that organization in the 1920s says more about modernism than any number of literary analyses. In AHEPA, and in many other similar societies crossing many churches and many ethnic groups, people were betting on the future. The future is going to be better than the present. We were poor dirt farmers in the Old Country; now we’re here, and we’re going to build a better future for ourselves and our children. Read more…
Drones might never find meaningful retail delivery work, but they might find practical employment in warehouses.
After writing my short post about the use of drones to deliver packages, it occurred to me that there’s one more realistic use case. Unfortunately (or not), this is a use case that you’ll never see if you’re not an Amazon employee. But I think it’s very realistic. And obviously, I just can’t get drones out of my head.
As I argued, I don’t think you’ll see drones for retail delivery, except perhaps as a high-cost, very conspicuous consumption frill. What could get more conspicuous? Drone pilots are expensive, and I don’t think we’ll see regulations that allow autonomous drones flying in public airspace any time soon. Drones also aren’t terribly fast, and even if you assume that the warehouses are relatively close to the customers, the number of trips a drone can make per hour are limited. There’s also liability, weather conditions, neighbors shooting the drones down, and plenty of other drawbacks.
These problems all disappear if you limit your use of drones to the warehouse itself. Don’t send the drone to the customer: that’s a significant risk for an expensive piece of equipment. Instead, use the drones within the warehouse to deliver items to the packers. Weather isn’t an issue. Regulation isn’t an issue; the FAA doesn’t care what you do inside your building. Autonomous flight isn’t just a realistic option, it’s preferable: one massive computing system can coordinate and optimize the flight paths of all the drones. Amazon probably has some of that system built already for its Kiva robots, and Amazon is rather good at building large computing architectures. Distance isn’t an issue. Warehouses are big, but they’re not that big, and something (or someone) has to bring the product to the packing station, whether it’s a human runner or a Kiva robot. Read more…
Biological products have always seemed far off. BioFabricate showed that they're not.
The products discussed at BioFabricate aren’t what I thought they’d be. I’ve been asked plenty of times (and I’ve asked plenty of times), “what’s the killer product for synthetic biology?” BioFabricate convinced me that that’s the wrong question. We may never have some kind of biological iPod. That isn’t the right way to think.
What I saw, instead, was real products that you might never notice. Bricks made from sand that are held together by microbes designed to excrete the binder. Bricks and packing material made from fungus (mycelium). Plastic excreted by bacteria that consume waste methane from sewage plants. You wouldn’t know, or care, whether your plastic Lego blocks are made from petroleum or from bacteria, but there’s a huge ecological difference. You wouldn’t know, or care, what goes into the bricks used in the new school, but the construction boom in Dubai has made a desert city one of the world’s largest importers of sand. Wind-blown desert sand isn’t useful for industrial brickmaking, but the microbes have no problem making bricks from it. And you may not care whether packing materials are made of styrofoam or fungus, but I despise the bag of packing peanuts sitting in my basement waiting to be recycled. You can throw the fungal packing material into the garden, and it will decompose into fertilizer in a couple of days. Read more…