In this paper, I am going to assume that all process problems have been solved. I'm not sure whether this is true or not, but we have been dealing with process issues over the last twenty years or so. So if they have not been solved, they probably won't be. But, we know that some teams are able to produce good software in reasonable amounts of time, and have fun doing it. Since the machine of "process" seems to be humming along nicely for those people, let's take a look at what other issues they have. What is it like to be a developer on a project that is functioning well? Since we've solved the process problems, we can delve deeply into the core experience of people who develop systems.
It's hard being a developer. Half the time, the people you work for don't know what they want, or they want it yesterday. Sometimes, you do what you think is the best work in your life, and it gets scrapped for some reason completely out of your control. It is particularly hard when you love the thing that you are making. A bridge, a movie, a program. It takes substantial time and effort to make the "thing." You grow to love it or hate it. It takes on a life of its own.
Some people relate better to things and concepts than people. Many of those people become engineers. They love systems and things for what they are, and what they tell us as engineers: that we are good, we created something out of nothing with our hands, we solved the problem, won the day, etc. We get the thrill of solving a problem, but with a caveat, it is a rare engineer who is completely happy doing useless work.
As a consultant, I go around and help teams. The thing that interests me the most is to notice how team members value themselves in a work situation. There are in incredible number of ways this can happen. Here are some of the most typical ones:
I feel good about myself at work because..
There are a couple of things we can notice about this list. First of all, there certainly isn't an even distribution of these valuation mechanisms across developers. But, more importantly, only the last one hints at ownership. The idea that a developer can value their participation in the decision of whether a project will continue or not.
My position is that once people get to the point of being able to deliver software effectively their next battle is often coming to terms with what it means to be developers. To create artifacts, of limited lifespan, which may or may not be used. This isn't particular to software. Any worker has to deal with the fact that they are creating something for someone else, the split between their valuation and the market's, but I think that it is often more agonizing for developers.
Prior to consulting, I knew several people who quit software development because they were so unnerved by the fact that they could spend a good deal of time working on something and have it discarded capriciously. The people I've known who have avoided that trap have chosen to get their valuation elsewhere. Often they've joined professional organizations, and formed peer groups. Some of them attend conferences. But, in most cases, there is a fork in the path that they choose. They choose either to value themselves predominately on what they can do technically, or how they relate to people. The latter ones tend to have a stronger base. The former tend to have trouble adjusting in the agile situation, where everyone and everything is leveraged to get better at shipping software.
I don't know what to do about that divide. And, I don't want to make it sound like a clean dichotomy. It certainly isn't. Many developers are happy as clams if they can share their latest creation with someone else, but unhappy if there is no one to show.
To me, one of the central issues of development is team culture. It is hard to catalyze culture, but it is essential. Process and culture are two sides to a coin, you can not affect one without affecting the other, and if you are blocked on one you are blocked on the other. When I help people change their process, these valuations are the things that cause the most trouble. At the core, is the dilemma of the engineer. Engineers create artifacts, of limited lifespan, which may or may not be used. The way that developers broaden their self-valuation seems, to me, to be one of the key human issues in software development.