PD fallacy #5: software development is a factory cranking out features
Apologies for the late posting of this article. However, I am happy to share that I just returned from successfully climbing Mount Kilimanjaro.
One of the popular metaphors for software development that annoys me to no end is the notion of a software factory. Even if the underlying concept is concerned with well-defined processes and structured ways of working, the image it draws up in my mind is that of a production line. And it pictures software engineers as mindless factory workers that repeat the same task over and over again.
Interestingly, mechanical design and electronics design are never described as a factory. Everybody understands that a mechanical or electronics engineer is designing a solution and verifying all its necessary properties. Once the design is finalized, we can start manufacturing. And everyone understands that these engineers need to evaluate alternatives, create prototypes, test these prototypes and then arrive at the preferred solution after having explored the design space.
For some reason, when it comes to software, especially for folks outside of the discipline, software development is equated to the manufacturing process, rather than the design process. The implicit assumption seems to be that a requirement that needs to be realized in software doesn’t require a design but is nothing more than an algorithmic translation from human text into code. I can for the life of me not understand why reasonably smart people fall into this fallacy. The only reason I can come up with is that because software doesn’t have associated manufacturing, some may think that software development is manufacturing.
There are at least three concerns with treating software development as a factory. First, it fails to recognize the creative nature of software development. It really is a creative activity where the team as well as individual engineers explore a design space, based on their best understanding of the requirement, the customers and the context in which the functionality will be used. It typically requires exploring alternatives, testing things with customers and using empathy with the user to come to a realization that best serves the intended purpose.
Second, it tends to ignore the larger scope in which a feature or requirement needs to operate. The notion of feature interaction is well established in the software engineering literature and basically refers to the fact that features aren’t simply Lego bricks that can be put together; they almost always interact with already existing functionality. The integration of a new feature into the existing code can be quite challenging and requires careful exploration and design. The whole purpose of software architecture is to minimize feature interaction and, consequently, future maintenance and extension costs, but every architectural decomposition will have some types of functionality that can be easily added and other types that will require changes in many places in the code.
Recommended by LinkedIn
Third, it assumes that all features are worth building and that the specification is the ground truth when it comes to what adds value to customers. With digitalization creating more and more opportunities for DevOps and frequent feedback from the field, the whole notion of building a large set of complete features without frequent, intermediate testing that they actually add value is simply outdated. As we discussed in an earlier post in this series, we need to treat requirements and feature requests as hypotheses that need to be validated. And it’s the job of R&D to do the validation.
One way to think about this is to distinguish between efficiency and effectiveness. Efficiency is the notion of doing work at the lowest cost in terms of resources, defects and time. Effectiveness is concerned with creating maximum output against each unit of input. Optimizing the R&D organization for cranking out as many features per time unit as possible assumes that each of these features is actually used and appreciated by customers. Research shows that this is a completely wrong assumption. In fact, less than half of the features in a system are used sufficiently frequently to justify the R&D investment.
We need to shift the focus of R&D from efficiency to effectiveness. This requires us to build a slice of a new feature, get it out there and in the hands of customers, measure its impact and decide on the right course of action after reviewing the data. And this may mean canceling a feature and removing the initial code for it from the system as it doesn’t deliver the expected value.
Second, rather than focusing on building new features, we should spend more time on revising and experimenting with features that are used frequently. In many cases, we can achieve a significantly higher return on investment by optimizing existing features than by adding new features that aren’t used. For most people with the software factory mindset, that’s a complete blindspot.
One of the ways I gauge the understanding of digitalization in companies I work with is how they talk about software development. Those that use the “software factory” metaphor have real misconceptions about the role of software development and the creative design activity that it really is. Instead, focus on fast feedback loops with systems in the field, iteratively build new features to measure their impact and spend much more time optimizing existing features that are heavily used, rather than adding more and more features. It’s impossible to not end this post with the famous quote from Peter Drucker: efficiency is doing things right; effectiveness is doing the right things. Let’s focus on effectiveness first!
Like what you read? Sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch), Medium or Twitter (@JanBosch).
Driving the digital transformation
1ySoftware developement is some kind of production. Without being able to fokus on a small set of features, commited for a sprint it’s not possible to get a sprint ready within an estimated time frame.
Board Advisor/Mentor/Coach for Startups and Corporations | Visionary Strategist | International Leader | Passionate about Startups and Future Mobility
1yJan Bosch you should connect with Dan Burns CEO of Testifi. He works with some of the big car companies on their transformation.
Bespoke Generative AI for Engineering & Manufacturing (PLM, MES, ERP) | Cloud Native | Air Gapped | System Integration | Concepts, Technologies, Execution
1yLet's do some history first. English-style factories differed from the previous way of manufacturing by life-learning experts/artisans, because they introduced specialization and allowed lower skillset. Ford's invention of conveyor was a step further - an employee was doing most primitive task, and could be both easily trained and easily replaced. The earlier concept of a software engineer was almost a magician, but this is no longer the case. There are people who indeed do magic, but there are very few of them. A lot of developers, especially those in the web and mobile apps are Lego bricks conveyor assembly workers. They are absolutely necessary, but they are also more and more replaceable, including by the tools like CoPilot. Microservices (small set of features + standard interfaces) are helping to make individual "line developer's" contribution even less significant. DevSecOps are catching the issues, protecting the integrity, and funneling the information. It is really a conveyor. A factory produces shoes according to the engineering design, the developers churns out the code according to requirements. The shoes features may change, and the code features list may change. Efficiency and effectiveness can coexist.
System Safety Engineering and Management of Complex Systems; Risk Management Advisor...Complex System Risks
1y"Instead, focus on fast feedback loops with systems in the field, iteratively build new features to measure their impact and spend much more time optimizing existing features that are heavily used, rather than adding more and more features" Actually, after all the confusion with fast loops, AI/ML, IoT, advance automation, hyper-automation, agile processes, advanced digital and system complexity, advanced air mobility, open systems, deep-tech, and advanced technology, 5G assumptions, meta data, super sensors, and hypes… we need to: Maintain control over all automation and advanced technology; Keep the human in the loop; Actually understand system assurance: human, hardware, software, firmware, logic and the human and environmental integrations and apply system safety, software safety, cyber safety, cyber security, system reliability, logistics, availability, human factors, human reliability, quality, survivability, etc.; Design systems to accommodate humans; Systems will fail, inadvertently operate, increase system risk with complexity; Humans will fail; Design systems to fail safe; Design systems to enable human monitoring; Design systems to enable early detection, isolation, correction and recovery…
Associate Director of Engineering | 17+ Years in Software Platform Engineering | Driving Innovation and Scalability at GEP Worldwide
1yThanks for posting "Efficiency is the notion of doing work at the lowest cost in terms of resources, defects and time. Effectiveness is concerned with creating maximum output against each unit of input"