Increasing speed trumps any other improvements R&D can provide to the company. As a process, methods, or tools professional, there is only one measure that justifies your existence: how have you helped teams move faster?
There is exponential growth between the introduction of a technology and the full economic exploitation of that technology. No efficiency improvement will outperform cycle-time reduction. So don’t optimize efficiency, optimize speed. “If you’re a fast race car, everything is efficient.”
“If you are not moving at the speed of the marketplace, you’re already dead–you just haven’t stopped breathing yet.” – Jack Welch
Apply web 2.0 rules to software development, e.g., Google 3 x 3 (3 persons x 3 months), Amazon two-pizza rule (no team larger than can be fed with two pizzas), weekly not monthly release cycles, continuous development. Short cycles are key for agility, speed, and decoupling.
Architecture–3 API rule–no team should worry about more than three APIs during development. Architecture should focus on simplicity. Current focus is on building really smart architectures that no one understands.
Requirements and roadmapping: traditional roadmapping is done with a large roomful of people trying to hash out an idea. But the cost of overlapping teams is much lower than cost of synchronized, planned roadmaps and plans.
Use architecture, not process, to manage coordination and alignment. The illusion of control provided by emphasis on process can be organizationally costly. This approach causes unacceptable complexity and coordination cost.
2. BUILDING DELIGHTFUL PRODUCTS
Hierarchy of consumer needs: (1) pleasure, (2) usability, (3) functionality. If you don’t manage to delight your customer, you’re in trouble. Pleasure has an architectural component. Groundbreaking products are the exception to the rule.
Software engineering is at an inflection point from “integration-oriented” to “composition-oriented” software engineering. Design for automated compositionality, not manual integration. Don’t take aspirin for a problem that needs a surgeon. Minimize dependencies and release parts of the systems independently. Focus on small teams of engineers, give them direction, and get out of their way.
Products as experiment systems. Product teams develop solutions for ideas, then test with subset of customers.
Architecture plays important role. Architecture has to support the releasing of small chunks of functionality to subsets of customers to collect feedback about products being built. “Ideas are a dime a dozen; only validated concepts count.” In themselves, ideas are worthless. Test an order of magnitude more ideas on a regular basis. Use experimentation to figure out what the customer really wants.
Innovation is centrally important and can’t be outsourced. This has architectural implications in how you design and build your systems. Ideas are worthless in and of themselves. Only concepts validated by the customer count.
3. SOFTWARE ECOSYSTEMS
Software architecture is key to building delightful products in context of software ecosystems. Architecture happens (in parallel). Simplify, simplify, simplify. Decouple components, teams, organizations.
Traditional approach for Quickbooks was for of a monolithic platform with three product lines on top. Vision is to move to a software ecosystem where other developers and outside parties can contribute to the Quickbooks ecosystem.
Atomisation–Build in small chunks, allow applications to be pieced together by customers. Traditional product lines are pre-packaged offerings. We are moving toward customer-assembled, componentized platforms. Make it easy to take and create different configurations.
Software ecosystem approach: thousands of developers build solutions within ecosystems. “Data not opinions” (Intuit). Deciding what to build next is usually based on opinions. You get to base this decision on data by having a layer on top of the core product that allows for experimentation. Ecosystem developers make apps that get absorbed into platform when they’ve proven themselves with data.
Companies must share responsibility for innovation with partners. Layer of functionality in the middle defines the essential value that the company provides to the customer. At the top are those features that provide competitive advantage. How do you keep the top layer frothy? By moving to an ecosystem where you do a lot of experiments, but also by allowing others to do these experiments for you. You can share the cost of innovation with others in the ecosystem. Ultimately, you can’t build everything yourself anymore, you must make it possible for others to join you.
Implications for software engineering: Innovations from web 2.0 will come down pipe to embedded systems; emphasis will be on speed, delightful products, ecosystems.
– Bill Pollak and Jack Chen