There's no shortage of advice on how you should model, design, test, build, and deploy your software project. Every author, trainer, and pundit will swear up and down that "they know the secret." They know how to build great software—they've done it before and all you have to do is follow their lead. Buy their software, read their books, buy their tools, attend their seminars, and do it just like they do it and you'll be a success, right? But somehow it doesn't seem to be that easy. In this column, the first in a series of articles that will explore the different avenues of software development, Andy Hunt and Dave Thomas, the Pragmatic Programmers, begin the journey by revealing that learning software development isn't as easy as the pros make it out to seem. Find out why these books and seminars work for them, but not always for the rest of us.
What Are We Doing Wrong?
One trap we keep falling into is the expectation that we can make developing software a "no-brainer." Everyone would adore it if we could just follow this or that process, just follow those rules, and have it all work out. But software development simply isn't amenable to a "no-brainer" approach; here's one reason why. A few years ago we discovered a helpful tool called the Dreyfus model of skills acquisition. It describes people's needs, how they learn and problem-solve according to their skill level in a particular area. We can use the Dreyfus model to better understand people and the role of process in software development.
For instance, beginners require simple, context-free rules in order to function in a new environment. They don't want to see the big picture—it's overwhelming, confusing, and (to them) irrelevant. Suppose you were giving a recipe to a novice cook. It's not at all sufficient to say "cook until done," because the novice has no experience to determine what "done" means. A novice needs to be told to cook it for thirty-five minutes at 350 degrees. No more, no less. Advanced practitioners, on the other hand, "must" have access to the big picture or they won't be able to function. If you tell an expert chef to cook anything for exactly thirty-five minutes at precisely 350 degrees they will, at best, ignore you. "Cook until done," while meaning nothing to a novice, speaks volumes to an experienced chef. It means taking into account the humidity, the condition of this particular batch of ingredients, the vagaries of the equipment in question (that oven always runs hot), the color of the dish, the aroma, and so on.
Full Brainer
Any process that tries to reduce software development to a "no brainer" will eventually produce just that: a product developed by people without brains. Instead of trying to turn software development into a "no-brainer" activity, we need to recognize that it's a "full-brainer" activity, and deal with it accordingly. Pragmatic programmers realize that everything can be questioned, and hopefully improved upon. Consider the very role of process and rules. In the original Dreyfus research, experienced airline pilots were called on to create rules for the beginners. They did, and the beginning pilots followed them just fine. But then the researchers sneakily turned the tables and made the experienced pilots follow their own rules—strictly.
It killed their performance.
Whether you're attempting to follow eXtreme Programming or achieve CMM Level 5, one size for all the team members simply will not fit. Beginners need rules, but you can't force advanced practitioners to follow them. Not everyone is capable or comfortable working in a pair-programming environment, and very few people are effective or comfortable in producing excruciatingly detailed designs for something they haven't built yet. Both groups (and the shades of gray in between) have different needs, and the successful project accommodates each of them. But that's quite a burden to put on a process or a project manager exclusively, so we'll have to pick up some of the slack ourselves. That means that we as pragmatic, forward-thinking individuals have to get better at two key things.Two Primary Activities
Developing software is largely composed of two activities: learning and communication. Surprised? Those probably aren't the two chief activities that came to your mind first. But in one form or another, that's what fills our days. We're always learning—not just new technology, but the problem domain, the quirks of the users/clients, the characteristics of the evolving system itself. Similarly we're always communicating: with the machine, with the users, with each other, and sometimes even to a family member who wonders just exactly what it is we do all day. These activities, while critical to success, are also very personal. The good news is that you can do something about it yourself, without any corporate mandate.
In this continuing column, we'll look at many different aspects of software development. But underlying it all, we'll be talking about the raw ingredients of software development—us developers, and how we can improve ourselves, our projects, and our teams.
As it turns out, the final frontier isn't outer space at all. It's inner space–our own minds. Join us in stretching the frontier.
