Software development is hard work. We have been taught that the best way to solve the tough challenges inherent to software development efforts is to treat software development as an engineering discipline. Stabilize requirements early, followed by implementation and verification. Yet we continue to fail.
We fail not because we do not try. We undergo complex process improvement efforts. We adopt iterative processes that propose attacking risk early. We create detailed artifacts that promise to increase awareness and understanding of the problem we are trying to solve. We attempt following detailed plans that will lead us toward the finish line. We establish steering committees and program managers. We hire teams of architects and designers. Yet we continue to fail.
Software development efforts fail because the traditional ceremonial approach to software development is fundamentally flawed. Worse yet, many adaptations of the most popular iterative and incremental processes are little more than reinventions of faulty practices resulting in slightly varied manifestations of the same problems that have plagued the software industry for years.
Who gets the blame for this mess? We, the humble developer. We are incompetent. Our estimates are wrong. Our code has bugs. The software doesn’t satisfy requirements. For it is us who produces the only artifact upon which a software system is judged. And it is we who must push, fight, and claw for a better way. It is our responsibility to lead the charge, and initiate the transition from the prescriptive and plan-driven processes of yesterday to the adaptive and emergent practices required of today’s software development effort.
Agile Is Good
Yes, I’m talking about agile software development. Many of us will draw comparisons with agile development and Extreme Programming, or agile development and Scrum. We might believe that if we write test cases, we are agile. Or if we refactor. Or practice continuous integration. Each of these may help increase agility, but none guarantee agility.
Agility is not defined by process or practice. Agility is defined by ability. The ability to remain nimble and responsive to change. Increased agility is always good. Why would we want to be anything other than agile? Slow, brittle, and inept are certainly not defining characteristics of success. It’s easier to slow down than speed up. That’s the affect of agility. As in life, remaining agile requires care, attention, and nurturing. This chapter represents a compendium of principles, guidelines. practices, and general thoughts on how to increase agility.
The list below is not exhaustive. One would be challenged to describe all such practices in it’s own book, let alone a single chapter. But it serves as a starting point that can help identify painful aspects of your software development initiatives, and then begin making the transition to a better way. Often times just getting started is the most difficult.
I’ve also omitted some of the more obvious and already well documented practices and techniques, choosing instead to focus on those more obscure and less famous.
While upper management buy-in helps speed the transition, it’s still possible to realize success with support from only peers. How? You control software development’s most important artifact! Ironically, it seems that we often forget the only purpose of a software development effort is to deliver useful software. It is our professional responsibility to fulfill that promise.
The Basic Principles
You might be wondering if the lower case ‘a’ in this chapter’s title is a typographical error. No, it is not. It is a statement. A statement against the software process and methodology wars that have led the software industry astray.
It is symbolic recognition of the agile revolution. Revolution? Revolution! A strong word indeed. But agile development is different from the traditional approach, for it is recognition that we were wrong. Only recently have we begun to understand our craft, and exposed the fundamental principles that will drive the future of software development. Moving forward, we must push for the following ideals.
Most of us have experienced the pain of waste. On many software development teams, we are prohibited from moving forward until the requirements specification is signed, the architecture is defined, and analysis and design complete. Only then can we begin writing code. But code is not written, it is crafted.
Pretending that specifications are stable, architecture is understood, and design is correct before we craft our first line of code is wasteful. Source code is a living entity that is constantly evolving. It is evolving because when change happens, the only artifact that must be modified to support that change is the source code. No other artifact comes with this restriction. If an artifact does not directly contribute to the quality and the integrity of the source code, creation of that artifact must be questioned.
Critics will argue that even to craft code, developers must understand requirements, and those requirements must be documented. I don’t question the value of well-documented requirements so long as any requirements documentation produced is a living breathing document that evolves with the source code. But that requires discipline, and discipline is not a strong trait of software development teams, especially given tight deadlines and immense pressure to meet the date.
Ideally, the most effective artifact is executable against the source. For instance, a suite of user acceptance tests that have received customer approval. Source code is an executable artifact and must be wrapped by practices and processes that verify the correctness of the source.