WebObjects is how all software will be built, says Steve Jobs in Wired, 1996. The Web is the new thing, and Microsoft is not there (yet). Steve sees an opportunity.
In 1996, Wired was to the Web what Rolling Stone magazine was to rock music in the sixties. The legendary magazine, founded by Kevin Kelly, covered the Internet and the Web as a culture, not as a technology. Wired was a lifestyle magazine.
The Web was the new way of living and working for those who were in the know and subscribed. In February 1996, Steve Jobs is on the cover. The next insanely great thing is WebObjects.
Objects are just going to be the way that all software is going to be written in five years – pick a time. It’s so compelling. It’s so obvious. It’s so much better that it’s just going to happen.
Steve Jobs, 1996
In 1996, Steve Jobs was wealthy not because of Apple or NeXT, the company he currently ran, but because of the Pixar IPO in 1995.
But on his mind are WebObjects and a determination to win the Web. Microsoft is not yet there. The big idea was to integrate the Web into desktop applications.
What no one could have imagined was that within a few years, there would be no more critical applications on the desktop. The Web would not be integrated into the desktop. The Web would become the new desktop.
Efficient delivery of software projects is the root problem of Software Engineering. The complexity of requirements analysis, software design, development, testing, maintenance, and delivery is immense! But there are ways to make it work.
A software development project is an endeavour to deliver a specific Scope (features) that customers and stakeholders find valuable before a Release Date within a Budget and with good enough Quality.
Why projects?
Specifically, projects provide the following benefits:
Coordination. The project facilitates coordination between multiple teams, enabling us to build features that no single team could build independently. Coordination cost grows with organisation size. In a startup, it’s low, and you may not even need a project to coordinate. But in most organisations, you need a project to get things done with multiple teams.
Constraints. The software project puts much-needed constraints on development. Time is the best constraint. With time constraints, solutions are not tweaked forever — there is a sense of urgency. This is essential for software development, as it is for any other creative endeavour.
Structure. Ideas are cheap, and legacy maintenance is never-ending. With abundant ideas and legacy work, it’s easy to get overwhelmed. With projects, we can schedule work and available resources and manage expectations with customers, sales, and marketing regarding what we plan to do soon.
The Iron Triangle
The Iron Triangle constrains projects: Scope, Release Date, Budget, and Quality; pick any three. You can only optimise for three of the four. They are interconnected. If you increase the scope, time, quality, or budget are affected, too. A project delivered on time, within budget, and with the full scope of features certainly has low quality — or is an illusion.
The Date is set for what we must assume are good business decisions. Black Friday does not move; sales must start at a specific time to meet a business target. The Budget refers to resources, and adding more people to a software project is known for slowing it down. Lowering Quality always results in some variant of a return rate: a delayed cost with bug fixing and customer support.
The best way to manage a software project is to constantly refine The Scope and fix the other at a good enough level.
Continually refining the scope means delaying decisions to the last moment. This is valuable because decisions can be made with as much empirical information as possible. However, it is also challenging to avoid causing project delays, additional costs, or lower quality.
Empirical process control
The best way to refine the scope is to develop in small incremental steps and iterate based on feedback. This, known as empirical process control, is the fundamental theory in agile methodologies. It relies on transparency (an accessible backlog of all work), frequent inspections (by customers and stakeholders), and adaptability (project scope can change at any time). Agile processes — such as the SCRUM Framework and Extreme Programming (XP) — are based on this thinking. Making decisions as late as possible is also the cornerstone of lean development pioneered by the revolutionary Toyota Production System (TPS).
However, making decisions late in a project without taking a penalty for delays, quality, or cost is tricky. This is why the first approach to a software development process was to make the right decisions early and avoid changes later — the so-called waterfall model. This, we know today, does not work well because of the many unknowns in software development. And not when a project is part of a product-market-fit discovery phase, where nothing is known before the first customer signs up.
But delaying decisions until the last moment is not the whole story. To make it work without taking penalties, it assumes a rapid development process where the project goal is kept steady in front of every engineer who is doing the work, empowered teams make decisions without a central authority, and flexible software design where the marginal cost of change is low and no decision is irreversible. These things must be in place, or delaying decisions will cause more harm than good. Without speed, you cannot delay decisions.
A new book about Apple reports how China made it possible for Apple to build world-class products without building them itself. But the cost was the complicated relationship with China that we see today.
In the past 20 years, most books about Apple have focused on Steve Jobs, the iPhone, and Sir Jony Ive. This excellent new book, “Apple in China: The Capture of the World’s Greatest Company” by Patrick McGee (2025), is different. It tells the story of how Apple can build world-class products without manufacturing any itself. It’s the story of how Apple made China, and then, how China made Apple. It’s the story of how Apple became intricately linked to China. Never before has this modern business tale been told with such detail and breadth. It’s a page-turner from start to finish.
Most Western companies see a path to profit by outsourcing production to cheap labour. Not Apple. Apple saw the infinite resources, the low cost, and the lack of regulations as a path to innovation. Apple did not move manufacturing to China to save costs; they moved manufacturing to unleash innovation that was only possible there.
Workers came in buses from the Chinese countryside. Engineers came in First Class flights from Cupertino. Foxconn, a Chinese manufacturer, saw the potential of working with Apple at any cost. The close collaboration between Apple engineers and Chinese manufacturers made the products Designed For Manufacturability (DFM). Apple out-innovated its competitors with better design and more efficient manufacturing.
The journey into China did not stop at factories. The combination of increasing demand for iPhones and a lack of supply (Apple had only one store in China) served as a lesson in market economy. The unmet demand led to counterfeits, grey imports, and shady business. The iPhone had become a status symbol; one person sold his kidney to buy the latest. China also became a critical market for Apple.
The Cupertino-China knowledge transfer did not stop at the factories. It spread into China as Chinese manufacturers hired ex-Apple factory workers, who had the knowledge. And one day, the Chinese manufacturer Huawei could build phones good enough to compete with Apple; at that time, the Chinese manufacturers had already outcompeted RIM/Blackberry, Nokia, and Motorola in the mobile phone market. It was the US sanctions in 2019 that prevented Huawei from competing with Apple; they could no longer access Google Mobile Services or get access to advanced microchips from TSMC.
But the relationship with China got complicated. Protests against worker conditions and salaries intensified. Global trade and politics did not help. Lately, Apple has started to move some manufacturing to India and other places. But most products remain Designed by Apple in California, Assembled in China.
Mr. McGee is first a reporter and second an author. The writing style is straightforward reporting and easy to read. But it’s reporting at its best. Apple in China stands on its own, but is also complementary to “Chip Wars” by Chris Miller and “Build It” by Tony Fadell.
Here are eight principles that make product organisations effective. A product organisation is effective when it delivers on time, works as ateam, and realises customer value.
1. They deal with uncertainty
Software is complex, and uncertainty is inherent in every endeavour. Teams that ignore uncertainty suffer more stress and burnout than those that effectively manage it.
When uncertainty is communicated in vague language such as ”soon” and ”likely”, it leads to misunderstandings. When developers say five days, customers and stakeholders assume it means exactly five days, but the reality may be between three and seven days. This is perhaps the most common root problem for failed expectations.
The best way to deal with uncertainty is to estimate it. An estimate is a guess, an approximation when an exact measurement is impossible. This means an estimate has a probability distribution. Five is somewhere between three and seven.
To estimate uncertainty, the key insight is the distinction between complexity (Simple vs Complex) and effort (Easy vs Hard).
Effort is subjective; Anna may do something in one day that takes Mustafa two days.
Complexity has to do with how many ”things” must be done to complete a task.
When the team agrees on a high-level solution, counting the number of system components that must change may be a reasonable estimate for complexity. Complexity can be measured objectively.
2. They make every delivery a working system for stakeholders
Teams that focus immediately on tangible results — rather than process, preparation, and planning — receive better customer feedback and are more likely to deliver on customer expectations in the long run. Teams stuck in “setting things up” and “building the platform” never catch up.
By consistently delivering a working system that the customer can try, the customer is closely involved in the project. Initially, the deliverables may be minimum viable products (MVPs), but remember that viable means that something is practically useful. They may be walking skeletons; all system parts are available but implemented superficially (e.g., the database may be a JSON file).
The essential idea is to focus immediately on tangible results – rather than programs, preparations and problem solving – as the first step in launching performance improvement thrusts… It is almost always possible to identify one or two specific short-term bottom line goals for which the ingredients for success are in place..”
Peters J., Thomas and Waterman Jr., Robert H. In Search of Excellence. 1982.
The key insight is to understand the distinction between vertical and horizontal development. Technical systems consist of layers, such as the data layer, business logic layer, and user interface layer. Developers tend to build a technical stack either top-down or bottom-up, one layer at a time.
Customers, however, don’t see or value the layers. Customers expect a steady flow of features, each with a part from each layer in the stack. So, instead of iterating vertically, one layer at a time, it’s better to iterate horizontally.
3. They are autonomous with a clear directional goal
Alignment is the extent to which the team has a specified goal (what they should do) or whether it’s free to do whatever it wants. Autonomy refers to how much of the team’s means (how they work) are specified, or whether they are free to do things as they want.
“Effective team self-management is impossible unless someone in authority sets the direction for the team’s work.”
— J. Richard Hackman. Leading Teams. Harvard Business Press, 2002
When both alignment and autonomy are low, teams are told in detail what to do, but they do not know the overall goals. This is called micro-management.
When teams are free to do what they want, without any clearly stated direction, it’s anarchy. Anarchy can be dangerous, as the team may set off in a direction that is potentially harmful to the company.
When teams have a clear directional goal but not the autonomy to make their own decisions on the means, it’s a waste of human resources.
The most effective teams have “aligned autonomy” (see Henrik Kniberg’s excellent YouTube clip) and create their purpose within the directives set by the overall organisation and processes.
4. They constantly improve their system and don’t depend on “later”
Developers should be permitted to do a great job.
Effective teams don’t depend on fixing it later or waiting for customers to ask them to improve system quality. Customers expect a high-quality system; they will not request platform quality as a feature.
Once the team takes ownership of refactoring and tidying their code, the cost gets built into the estimates, as it should.
“Modernization should be built on adding value, not chasing technology trends”.
– Bellotti. Marianne. Kill it with fire.
Refactor as you go. When new features are estimated, take into account the tyding and refactoring requires to ensure the end result is always a better system.
5. They deliver a collective output
Highly effective product teams collaborate to deliver tasks as a collective outcome. No member delivers anything on their own. This makes the team different from a coordinated group.
6. They fix bugs immediately and always have a working system
”It works on my machine.”
— Unknown Software Developer
The software from effective product teams is always working and free from bugs. When bugs are detected, they are fixed immediately (at the top of the backlog). This policy may initially slow the team down, but because the team is forced to work together and fix all bugs, they eventually grow and become faster.
Bugs are problems that prevent a user from accomplishing a task supported by the system, and there is no simple workaround.
“If some problem occurs the whole production line stops. In this sense it is a very bad system. But when production stops everyone is forced to solve the problem immediately. So team members have to think, and though thinking teams grow.” – Liker, Jeffery. The Toyota Way.
A common mistake is labelling a feature request as a bug. The fact that someone’s favourite feature is missing is not a bug. It’s a feature request and should be prioritised with other features, not as bugs.
Perhaps the most efficient way to reduce the number of bugs in a system is to define what constitutes a bug. There may be fewer than you think.
7. They have a clear Definition of Done (DoD)
They are always there, making every delivery ready for launch when the time comes.
The Definition of Done (DoD) should be a non-negotiable checklist. It’s the contract between the team and the stakeholders. Here are a few things that typically should be on the checklist:
Testing – Does the software work as expected for the customer?
Documentation – How do we know what the code is doing?
Analytics – How do we know what users are doing?
Observability – How do we know what the code is doing when it’s live?
Monitoring – How do we know what the code has done (logging)?
Interfaces – How can other teams access, should they wish to?
When the team and stakeholders have different understandings of what is meant by ”done”, decisions are made on false assumptions.
8. Their backlog is a prioritised list of functionality that the customer finds valuable
Effective teams start with the customer’s needs and work backwards. Their backlog is the functionality that the customer finds valuable, in the order of delivery.
It’s a common mistake to use the backlog as a to-do list and add all kinds of tasks, everything from implementation details to concepts. That’s a big mistake! It makes the backlog impossible to prioritise, and customer focus is lost.
De-clutter the backlog frequently. Remove old items ruthlessly.
Peter Stark / Tech 