DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Testing, Deployment, and Maintenance
  3. DevOps and CI/CD
  4. Continuous Delivery and Apple

Continuous Delivery and Apple

Jez Humble user avatar by
Jez Humble
·
Oct. 08, 12 · Interview
Like (0)
Save
Tweet
Share
10.28K Views

Join the DZone community and get the full member experience.

Join For Free

The case of Apple sometimes comes up in discussions around continuous delivery and the lean startup. For example, Richard Durnall described Apple’s strategy to me on Twitter as follows:

Brilliant and unwavering product vision from a few amazing folks going to market infrequently with huge ceremony.


That seems to be the exact opposite of what both lean startup and continuous delivery preach. It’s hard to know what happens behind the scenes at Apple because of their notorious secrecy about their product development process. Furthermore, there’s no way of knowing if the information we do have accurately represents what really goes on there. But if we look at Apple’s history, there are a couple of examples that strongly suggest that the principles behind continuous delivery and the lean startup were very much in play in Apple’s early years.

Exhibit A is the Apple I. Created in Steve Wozniak’s parents’ garage, and sold without a keyboard, display, power transformers or even a case, it is – as Eric Ries has pointed out – a great example of a minimum viable product.

Apple I on display at the Smithsonian, taken by Ed Uthman


Apple I on display at the Smithsonian, taken by Ed Uthman

Exhibit B is “The Macintosh Spirit”, an entry from folklore.org – the excellent compilation of stories from the creation of the original Macintosh, submitted by members of the team that built it.

This entry – which describes “The attitudes and values of the team forged the spirit of the Macintosh” – is short and worth reading in full (as is the whole site if you have the time – it’s available in book form too). Here’s a paragraph describing the Macintosh team’s product development process (my italics):

Other groups at Apple had an elaborate formal product development process, mandating lengthy product requirement documents and engineering specifications before implementation commenced. In contrast, the Mac team favored a more creative, flexible, incremental approach of successively refining prototypes. Burrell Smith developed a unique hardware design style based on programmable array logic chips (PAL chips), which enabled him to make changes much faster than traditional techniques allowed, almost with the fluidity of software. Instead of arguing about new software ideas, we actually tried them out by writing quick prototypes, keeping the ideas that worked best and discarding the others (see Busy Being Born). We always had something running that represented our best thinking at the time.


Given that we’re talking about events that were happening 20 years ago, it’s hard to improve on this as a description of how to do continuous delivery on an embedded system1. This example also resolves a common misconception — just because you’re “going to market infrequently with huge ceremony” doesn’t mean you can’t do continuous delivery (which is why I am careful to distinguish continuous delivery and continuous deployment, and also to differentiate between the terms “deployment” and “release”). Rather, continuous delivery is one of the things that enables successful “high ceremony” launches: if you’re doing it right, the high-risk technical work happens long before the product launch, which becomes purely a marketing event – in the case of the Macintosh, one of the most spectacular in advertising history.

'1984' commercial for the launch of the Macintosh

’1984′ commercial for the launch of the Macintosh


1 For a more up-to-date example, check out how the HP LaserJet firmware team moved to a continuous delivery model, including checking in to trunk to do continuous integration, and performing automated functional testing using real logic boards to test the processing algorithms and timing.

And be sure to check out the Continuous Delivery presentation series going on now.
Continuous Integration/Deployment Delivery (commerce)

Published at DZone with permission of Jez Humble. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Hidden Classes in Java 15
  • Best Practices for Writing Clean and Maintainable Code
  • Core Machine Learning Metrics
  • Implementing Adaptive Concurrency Limits

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: