I just finished Creative Selection by Ken Kocienda, a former Apple developer on the original Safari for macOS and iPhone projects. If you create products of any kind for anyone (including yourself), you should read this book. Kocienda provides a rare glimpse into the product development life-cycle and philosophy of Apple that provides a greater understanding of how Apple develops many of the products we’ve come to use daily. The development methodology of Apple at the time he worked there is elegantly summed up by Kocienda as:
A small group of passionate, talented, imaginative, ingenious, ever-curious people built a work culture based on applying their inspiration and collaboration with diligence, craft decisiveness, taste, and empathy and, through a lengthy progression of demo-feedback sessions, repeatedly tuned and optimized heuristics and algorithms, persisted through doubts and setbacks, selected the most promising bits of progress at every step, all with the goal of reading the best products possible.
Coder Radio listeners will know that’s a little too touchy-feely for me, but I do believe there’s a lot of value despite the sentimentality. Breaking it down to its essence we have three major points small teams, excellence in craft and iteration. These three pillars of Apple’s development methodology also apply to software shops working on contract projects, however, they are often ignored by the vendor or the customer or sometimes both.
Apple basically seems to have followed the pizza rule for the original iPhone software development team; the pizza rule is that your project team should be small enough that they can be comfortably fed with two large pizzas. This is one where both vendors and customers tend to go off track. On the customer side, it’s pretty easy to see how; they have a number of different executives who each has a design or technical advisor or two of choice and all of a sudden a small app development project has upwards of fourteen stakeholders on the customer-side alone. This is understandable in that it’s a pretty obvious error of over-doing it on collaboration under the logic that “if two heads are better than one, then fourteen must be even better!” There’s also sometimes an element of internal politics and turf-protecting on the customer-side that can lead to this. On the vendor side, things can get a little more sinister. Two common models I’ve seen are 1099 based shops that are shops in little than name only and offshore “dev farms.” Both of these models share two things in common — a need to put as many people on a project as possible due to low margins and are little more than a facade of a cohesive organization. Basically, they present themselves as a traditional development shops such as The Mad Botter or Thoughtbot but are just clearing houses for contracts that they then subcontract out. This structure creates a perverse incentive for the vendor to make mountains out of molehills on projects in order to get additional manpower brought onto a project. There’s nothing wrong with a little bit of subcontracting especially for specialty things that the firm doesn’t commonly do but a proper development shop is going to have a core team of full-time staff. As a potential customers (taking a US focus here) be sure to ask if prospect vendors have W2 or 1099 staff, assuming you’re interested in an onshore team. If you’re interested in offshore development, be sure to find out how long the individual developers have been working with the vendor; you don’t want to be someone’s trial project. And of course, keep Apple’s pizza rule in mind; if you’re told you need more than a handful of developers per platform of your application, start asking questions.
One of Kocienda’s early recountings in Creative Selection is of the Safari team’s experience unsuccessfully attempting to bootstrap that project and someone from the outside who had knowledge of the open-source Konqueror got a version of that running on macOS in a matter of days; Konqueror became the basis for Safari as we know it today. The developer showed excellence in the craft of software development not only by having knowledge of another system (Linux and KDE in this case) but being able to re-purpose that knowledge quickly for macOS. At its core, the Safari case was solved by a senior developer who had both a depth and breath of knowledge and experience in his craft. Certainly, there were more junior developers on the team but it was an experienced developer who ultimately got the Safari project on track. It’s common in the consulting world to have a mix of senior developers and more junior ones on a team as well, but what you want to make sure of is that the lead developers for each platform on your project are senior. This is probably the most straightforward lesson from the book.
What can I say about fixed-bid projects that hasn’t already been said about driving 120MPH, in reverse and drunk? Fixed bids don’t work for anything non-trivial. I understand the temptation here on both sides. As a customer you want to know what things are going to cost and sometimes vendors are in a pinch and just need to close a sale or maybe they sincerely believe they’ve bid enough to handle any contingencies — they haven’t and will start cutting corners, such as over-using junior developers, once they realize that and the customer likely doesn’t really know what they want before the project kickoffs anyway. Apple’s process is once again instructive here. In Creative Selection, Kocienda recounts numerous encounters with Apple executives such as Scott Forstall and Steve Jobs during product review sessions, small meetings where developers showcased their work to executives and got feedback. In the common even that there was feedback that required revisions, no developer’s paycheck was held and there was no back-biting regarding scope — the developer or team of developers just went back and start re-working the solution for the next demo. This is called iterative development. If you’ve ever studied Agile, then it should sound awfully familiar to you. Bottom line, this is the correct way to develop products software or hardware. Unfortunately, too many organizations get seduced by the illusion of control that fixed-bid projects so much so that according to IEEE over half of software development projects fail. A primary reason for this is that developing good software is an iterative process and fixed-bids just don’t allow this. They also compound the issues of customers not really knowing what they want before a project starts and developers not being perfect estimators. I believe that fixed-bids are the worst way to build anything and more likely will end in failure so much that I just don’t do them anymore and most reputable development won’t either. Iteration is what allowed Apple to make the iPhone the world-changing product that it became. Why would you want to limit iteration when developing your own product?
Kocienda surely didn’t have software development shops in mind when writing Creative Selection but the lessons he shares about Apple’s product development methodology apply. What do you think? Reach out on Twitter and if you have a software project you’re interested in getting done correctly, reach out to The Mad Botter.
