Engineering of software. This means the holistic engineering of all software to improve the application landscape as a whole, as well as the individual point solutions. Practices are needed that help teams engineer their software for capturing requirements and for developing software designed for engineering great products. It also means encouraging innovation in the large as well as the small—innovation of new business and new product opportunities as well as innovation that addresses the total cost of ownership impacting the whole organization, rather than just individual users and applications.

Engineering of methods. Methods should be engineered to support the full range of development challenges faced today and in the future. The emerging best practice should be captured and codified in a way that makes it easy to communicate and share among teams, and enables each team to compose the method they need from this growing set of reusable, proven practices.

Furthermore, moving from craft to engineering provides a robust platform for encouraging, establishing, and sustaining true organizational agility.

Engineering of software. How would software be developed if the craft were already a real engineering discipline? As in other engineering disciplines, it would be engineered by using commonly accepted, consistent practices that would be supported by models and analysis based on a common ground of foundational knowledge.

In the past, such an engineering mindset has been misinterpreted as meaning “big upfront design,” with everything downstream of this being akin to manufacturing rather than engineering. Upfront blueprinting is, indeed, often necessary for the engineering of physical artifacts such as buildings, bridges, and cars. This is done so that proper analysis can be carried out on the upfront models and blueprints, because of the capital cost required to build those things and the difficulty of changing them once built. Software, however, is a different kind of artifact—one that does not require manufacturing in the physical sense.

Agility in software development
takes advantage of this characteristic,
What is needed is, in fact, a merger of
the agile mindset with the engineering
mind-set, combining incremental devel-
opment with the disciplined application
of foundational knowledge. In such an
approach, not everyone will necessarily
be an engineer, but developers will con-
tinue to be treated as skilled craftsmen,
not factory workers. (See the sidebar
“Craftsmanship and Engineering.”)

It is common in agile approaches to talk of the emergence of the design of a software system as that system is iteratively developed. This is the very embodiment of evolutionary design as opposed to big upfront design. It can be very effective in allowing a team to explore alternatives creatively, while still converging on a good solution with a clear overall design.

Such emergent design, however, tends to produce point solutions for specific teams. Serious software development organizations, though, are almost always dealing with multiple teams working on multiple projects within an overall enterprise-level application landscape. Various project-level solutions need to fit into this evolving landscape. Indeed, the development of a large software system often requires multiple teams whose products are components that must fit together to create the overall system.

Dealing with design at this level is the province of software architecture, which, at both the system and enterprise levels, can and should still be evolutionary. Rather than being entirely emergent, however, key architectural decisions, presented in a development roadmap, often need to be made in advance of the corresponding development work in order to provide common guidance across projects and teams. This is where engineering practices can be particularly important, allowing for innovations that benefit the organization as a whole, based on careful analysis of business benefit versus engineering cost.

Engineering of methods. Moving from craft to engineering relies on the codification and sharing of knowledge. What is needed is for organizations to engineer their methods in order to be more effective at engineering their software.

Most methods in use today are at the extremes, either monolithic or tacit. The agile space is experiencing the rise of a number of competing, monolithic scaled agile methods, such as DAD (disciplined agile delivery), SAFe (Scaled Agile Framework), LeSS ( Large-scale Scrum), and SPS (Scaled Professional Scrum). All these methods have their special strengths and weakness-es. They have their own camps of supporters, but their monolithic nature doesn’t make it practical to borrow ideas from one another, even less to borrow complete codified practices. This situation is very similar to what we had in the past with methods such as RUP (Rational Unified Process), Open, Structured Analysis and Design, and

Related to the idea of craft is craftsmanship, performed by a person who practices or is highly skilled in a craft. Software development will always need craftsmanship that can stand on more or less science, more or less engineering, and more or less structured knowledge. We would, for example, describe an engineer as a craftsman using engineering practices in developing software. The new software craftsmanship movement is supportive of many engineering practices—for example, they are strong supporters of design and architecture patterns, domain-driven design, among others. They take pride in using the right tools, techniques, and design methods to achieve high-quality software. They do not believe in heroics, but in quality of work and in tools. They believe in sustainability, and in keeping the system “clean” and able to absorb change and rework. The craftsmanship movement, however, doesn’t fully address the whole engineering space and, in particular, how to systematically grow knowledge about the discipline. Craftsmanship and Engineering