The Nature of Software Development
- We Fail Too Much
- Definitions of Success
- The Standish Group
- Doing the Wrong Things
- Doing the Things Wrong
- Time Goes By, Things Improve
- One Reason: The Civil Engineering Analogy
- Giving Up Hope
- Ignoring Your Mother
- Bridges Are Hard, Software Is Soft
- We Swim in an Ocean of Change
- Accept Change
- Embrace Change
- Capitalize on Change
- A Better Analogy: Evolving Systems
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
To do something well, it helps to understand it. I think we all want to do a good job as software developers, and I think we will have a better chance of doing a good job if we take a little time to investigate the nature of what we are doing.
Once upon a time, I was a Boy Scout. My troop was planning a white-water rafting trip down the Colorado River in the eastern part of California, just above the Imperial Dam. We were given safety training before the trip began, and one thing they emphasized was what to do if we fell out of the raft, which was a distinct possibility in some of the rougher sections.
They said, "If you become separated from the raft:
- Keep your life vest on, and
- Do not fight the current."
Keeping your life vest on means you will be less dense than the water (which is why you float), and not fighting the current means you will not run into the rocks. The current, after all, goes around the rocks, not through them, and as you will be less dense than the water, it will be able to take you around them too.
This can be uncomfortable. The water can go through narrow defiles that are not fun for a person to go through, but it will not slam you into a boulder that can injure you or kill you. So, do not fight it. Let the nature of the river take you.
This lesson has many implications in life, but here I am suggesting that software development has a nature, a way it "wants" to flow. If we follow this by coming to understand it and then align ourselves with it, then everything will get easier, less dangerous, and ultimately more successful.
I'll begin with the notion that software projects fail more frequently than they ought to, and examine why this might be. I'll examine some of the fundamental assumptions that underlie the traditional view of the nature of what we do, and then look for ways to change these assumptions in the light of what we now have come to understand about software and its role in the world. Finally, I'll show how this new understanding will impact the choices we make, the qualities we emphasize, and how design patterns can help us to accommodate change in systems.
We Fail Too Much
For most of my adult life and some of my teenage years, I have been writing programs. I started using Basic and Pascal and then moved on to C and other languages, including such esoteric and unusual examples as PL1 and Forth.
Moving from language to language, platform to platform, era to era, much has changed. But there are some fundamentals that seem to have held their ground. We have looked at some of them (side effects, for instance, always seem to be a concern).
One of these constants, perhaps the one that has stuck in my throat the sharpest, is the notion that the failure rate of software projects is way, way too high.
Of course, for the majority of my career I was never sure if this was just my own experience; maybe I was just not very good at this stuff. I would ask other people, friends, and colleagues who also "cut code" and they would tell me their war stories, projects they had been on that had gone disastrously wrong.
But, I also knew that people like to tell those kinds of stories. It is human nature; war stories are dramatic, exciting, and often lead others to try and "top" them in the sort of round-robin, coffee-klatch conversations that developers often get into.
So, was it just me, this low rate of success? What did I even mean by success, anyway?
I was pretty much responding to a feeling: I did not have the confidence that I would like to have; I did not feel like I had a "handle" on things a lot of the time.