Let’s take a look at the typical Agile Software development workflow. First, we would like to clarify what we mean by software development. Paulo has a BSc in Computer Engineering, and a Msc in software Engineering, and all of us have been working with software development for the last 16 years. You would think it would be easy for us to describe what software development is. It turns out, though, that whenever we try to explain what software development is, we use the terms “like” and “similar to”, or we compare it to another industry.
A quick search about software development online (“software development is”, and “software development is not”) and we realize we are not alone:
Software development is engineering…
Software development ismostly an art…
Software development is science…
Software Development is like Manufacturing…
Software development isa design activity…
Software development issimilar to rock-climbing…
Software development is, and has always been, a religion…
Software development is notan engineering discipline…
Software Development is notAnarchy…
Software development is notscience…
Software development is notlike manufacturing…
Software development is notlike many of the “hard” engineering disciplines…
Software development is nota simple process to be achieved in one day, it is a complex process…
Software development is nota Jenga game…
Software development is nota production or a manufacturing activity…
Software development is nota religious experience…
Software development is notan art…
Perhaps this indicates that software development means different things to different people. There is nothing wrong with that.
Lately, our industry has been more inquisitive about software development and the role of the software developer. Much of this is due to the Agile movement. In the last decade eXtreme Programming, and more recently the software craftsmanship movements have, in many ways, rekindled the debate about software development.
This debate has been very good for software development. It has generated many new ideas on how to go about developing software , organizing teams, respecting people and evolving practices.
Prior to the influence of Agile, Birrell, N.D 1985 ’s book APractical Handbook for Software Development has a concise definition for software development:
Software development is the process of creating a computer software. It includes preparing a design, coding the program, and fixing the bugs. The final goal of software development is to translate user needs to software product.
The nice thing about his definition is that it does not compare software development with something else: engineering, science, art, rock climbing or religion. But in order to agree with the definition, you have to consider that coding the program has many activities. For example, writing tests, automating, and integrating are all part of coding the program. Similarly, preparing a design is more than just the design of the system; it should also include the requirements definition, user experience design, and even how to break the work into smaller workable pieces.
The problem with this definition is that it has a very narrow final goal: “The final goal of software development is to translate user needs to software product.” Similarly to Lean Thinking, we would rather look at the goal beyond the simple building of a product. The goal is to enable continuous improvement of teams and processes, in addition to delivering the software product.
In Lean thinking this is the Kaizen concept (translated to English as “continuous improvement”). In Japanese language Kaizen means “change for good”.
Kaizen is both a personal mindset and a practice. As a mindset, it suggests, “My work is to do my work and to improve my work” and “continuously improve for its own sake.” More formally as a practice, kaizen implies:1. Choose and practice techniques the team and/or product group has agreed to try, until they are well understood2. Experiment until you find a better way3. Repeat forever
