How do we manage systems that are too large to understand, too complex to control, and that fail in unpredictable ways?
“What is surprising is not that there are so many accidents. It is that there are so few. The thing that amazes you is not that your system goes down sometimes, it’s that it is up at all.”—Richard Cook
In September 2007, Jean Bookout, 76, was driving her Toyota Camry down an unfamiliar road in Oklahoma, with her friend Barbara Schwarz seated next to her on the passenger side. Suddenly, the Camry began to accelerate on its own. Bookout tried hitting the brakes, applying the emergency brake, but the car continued to accelerate. The car eventually collided with an embankment, injuring Bookout and killing Schwarz. In a subsequent legal case, lawyers for Toyota pointed to the most common of culprits in these types of accidents: human error. “Sometimes people make mistakes while driving their cars,” one of the lawyers claimed. Bookout was older, the road was unfamiliar, these tragic things happen. Read more…
Introducing a common configuration format and workflow
As the number of developers on a project, the number of projects in an organization, or the complexity of a single project increases, it also becomes increasingly difficult to keep development environments operational. From changing dependencies and differing server versions to developers running completely different operating systems, keeping the process of getting a running development environment sane and repeatable is non-trivial.
Vagrant solves all of this by introducing a common configuration format and workflow for describing and building development environments repeatably across Mac OS X, Windows, or Linux.
More Lessons from the Collapse of healthcare.gov
Last week, I wrote in some detail about some of the specifics of how the Federal healthcare portal seems to have violated basic principles of good software delivery. Now I want to talk a bit about the more general factor that I think led to all those cut corners and shoddy deliverables.
One of the oldest and shortest jokes in the computer industry is “Time. Money. Features. Pick any two.” To some extent, you can swap quality out for features, because poorly delivered functionality is essentially non-existent functionality. In almost all commercial software projects, time and money both end up being the parts that give in the end. In other words, the original feature set almost never gets cut, but the project goes over budget and delivers late.
Worth the Blood, Sweat, and Tears?
Joshua Smith (@kognate) is a Lead Mobile Developer at iRx Reminder, frequent Cocoa Conference speaker and author of an upcoming book with O’Reilly on core data. We recently sat down to talk about core data and its complexities.
You can view the entire interview in the following video:
Why where you put your script element matters
And if you missed the first part of this video series, you can watch it here.
For the next 15 weeks, a new learning video every week.
Probabilistic languages can free developers from the complexities of high-performance probabilistic inference.
Probabilistic programming languages are in the spotlight. This is due to the announcement of a new DARPA program to support their fundamental research. But what is probabilistic programming? What can we expect from this research? Will this effort pay off? How long will it take?
A probabilistic programming language is a high-level language that makes it easy for a developer to define probability models and then “solve” these models automatically. These languages incorporate random events as primitives and their runtime environment handles inference. Now, it is a matter of programming that enables a clean separation between modeling and inference. This can vastly reduce the time and effort associated with implementing new models and understanding data. Just as high-level programming languages transformed developer productivity by abstracting away the details of the processor and memory architecture, probabilistic languages promise to free the developer from the complexities of high-performance probabilistic inference. Read more…
Learn to be a better programmer by taking charge of your interests
If you want to be a better programmer, a good first step would be to choose an area of software development to take additional responsibility for. Now, when we say “responsibility,” we don’t mean the sort of “you’re to blame and you accept it” responsibility that is so commonly thought of. Instead, we mean the willingness to take charge or the willingness to do something about an area.
So select out some area of software development, and decide to be a bit more responsible for it than one was before. The “area” could be simply some additional part of the current project you work on, the whole project itself, some type of software development that you haven’t done before, some aspect of software development you’d like to know more about, etc. If you’re feeling adventurous, try deciding that you’re personally responsible for the quality of the entire software project you’re working on. If you do, you may be surprised at how much easier this makes your life. When you’re trying to maintain the quality of only a piece of a software project, it’s very difficult. You’re surrounded by complexity or confusion, and you have to fend it off at every turn. But when you look at the project as a whole instead and try to decide what should be done with it as a whole, the solution presents itself much more readily. Now, it may seem like quite a bit more work to resolve the problems of the whole project, and it is. But it’s considerably more satisfying, tremendously more effective, and will bring you up to seniority as a software developer much more quickly than just trying to solve the problems of your one particular area.
Three new battles to watch as the mobile hardware gap closes.
The iPhone 5 may or may not be the most beautiful handheld device, but it barely matters anymore. Competitors have rendered its beauty and craftsmanship irrelevant. Amazon has received the message and responded with its latest set of tablets, and Google has responded with the Motorola Droids and the Nexus 7. These devices now have sufficient quality in their materials, specs, and base operating systems so that they can make any consumer happy. So if hardware is a toss up, where will the next battles be fought?
The answer: developers, integration, and discovery.
First, the very best developers will build apps that tap key trends: improved camera quality is making real-world text and face recognition more possible, geofencing data stores are making proximity–based apps more possible, and despite Steve Jobs’ assertion that God gave us 10 styli, there’s clearly a host of applications that are benefiting from pressure-sensitivity and pens. The level to which Apple and Google embrace these new technologies and extend the current state of the art in voice and gesture recognition will factor heavily into the quality and emergence of new applications. In addition, the extent to which Apple and Google can expose these new technologies — like NFC or always-on Glass cameras in Google’s case — will provide an advantage to developers.
Christopher Neugebauer on Android interfaces, Jellybean, and future updates.
Chris recently wrapped up his work on Meebo for iPhone, Android and BlackBerry which was recently acquired by Google. I got a chance to talk to him at OSCON this summer about Android development.
Key points from our full discussion include:
- Great features from Jellybean are available for older OSes. [Discussed at the 2:32 mark]
- Android devices vary greatly in size and shape – design with this in mind [Discussed at the 4:35 mark]
- Developers need earlier access to new versions of the OS [Discussed at the 5:32 mark]
You can view the entire interview in the following video.