Cook Until Done
Cook Until Done
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 week's 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.
Comments
#1 Submitted by Duncan Green on Fri, 10/23/2009 - 1:37pm.
For me the two central activities are communication and reasoning. Both of these are only made possible by the development of consistent and meaningful language. In the context of incremental delivery, this is very hard to achieve. Engineers who realize that the essence of the problem is semantic not technical are very thin on the ground...
#2 Submitted by Rose Eliff on Wed, 01/18/2006 - 10:08pm.
Andy & Dave - You gave me some very interesting points to consider, particularly, the Dreyfus research comparing beginners to experienced practitioners (and the always-erudite John D's French chef example) and the point about learning and communication. Well done, gentlemen! In my experience, we can all do the "communication" part of that equation better. Too often, all the information about the vagaries of a system lie with just one or two individuals; the info is only in their heads, isn't documented for reference by others, and isn't communicated in any forum for others to learn from. When those people either vacation or move on, the remaining team is left to struggle without having those learnings available to them initially. As John D points out, a shared vision is a real key to success.
#3 Submitted by John Daughety on Wed, 01/18/2006 - 7:18pm.
After a lot of experience with many different "models for success", I have found one thing to be true - if any one of many valid processes is chosen, the real key to success is injecting a common, shared vision of this process in every team member. When you go to chef school in Paris, they don't teach you how to read instructions and translate the different shortcuts for amounts of ingredients. They teach you how to "know" when the souffle is just the right consistency, when a merengue has been mixed just the right amount, or when a goose is "done". Upon graduation, each person "knows" in his/her own way how to cook, but there is a common expectation of excellence that never needs to be spoken directly or put on paper. My best experience with developing a shared vision of excellence was with a testing team I managed, where we met every Friday afternoon and reviewed a dozen bugs that had been logged that week. I picked them and made sure they covered the entire range of quality. We discussed the description, whether the severity/priority was accurate and even whether this was the best bug to write given the observed behavior (many times a little more research may have revealed a more fundamental problem that would be easier to fix in code). After a few months I started noticing how our work as a team was becoming consistent, and not because of a strict recipe. It was the "recipe" we developed, reinforced and continuously improved in our weekly meetings that drove our success. I look forward to the next articles that expound on this idea, especially the one titled (loosely) "Who does the dishes???" Thanks!
#4 Submitted by Johannes Trost on Tue, 04/19/2005 - 11:17am.
"learning and communication", I fully agree with you. Since years I have the problem to make that clear to my managers. L&C can not be seen by the customer, therefore it can not be sold, therefore planning is not focussed on L&C. What is paid for is code that in some sense does what the costumer expect produced within minimum time. Learning & Communication is seen as an expensive add-on.
#5 Submitted by Andy Hunt on Thu, 04/14/2005 - 8:40pm.
The previous pooster said "Just remember that one of the main reason for a standard to exist is just that - to make the process for beginners a no brainer." The only way that can work is if the rules are context-free an unambiguous. In the kitchen at Burger King, it seems to work fine. In the domain of software development, that's not usually the case -- context is key, and that causes a great deal of problems. Take patterns, for instance. Patterns have been terribly misued by under-experienced practitioners who lack appreciation of the context in which they should be used. You can't give context-free rules for when and how to apply a pattern; context is everything.The poster also says: "I doubt that a reminder to extract gear before landing would damage any pilot's performance."Actually, it does. But that's a simplistic view. The statement from the Dreyfus research is that "forcing experts to strictly follow rules significantly degrades their performance." Again, most unions recognize this and organize work slowdowns by "working to rule" -- following the prescribed rules regardless of what experience tells them destroys their performance.Finally the poster says "I once had a problem explaining to a experienced developer that ignoring methodologies is a chosen methodology by itself"We're not talkign about ignoring anything; we're talking about allowing the expert to follow his or her intuition that is finely honed beyond the ability to express it in rules. It's what dcotors and other highly trained professionals do, but it's something to which we as an industry we seem adverse.--/\ndy
#6 Submitted by Vitaly Vigasin on Wed, 04/13/2005 - 9:11pm.
The problems with processes that do not work are:1) they are not actually followed2) they are not understood3) they themselves are not goodMy experience is that the processes are most often not understood - and THEREFORE are not followed. Just remember that one of the main reason for a standard to exist is just that - to make the process for beginners a "no brainer". If it does not work, verify either the process itself or how it is understood and followed. You can't specify ABSOLUTELY everything - so make sure that "done" is identically understood by all experienced "chef" in your environment (which is never the case). But please, don't tell me that a chef doesn't need a process - they all follow one! And its basic elements are identical for any guru. I doubt that a reminder to extract gear before landing would damage any pilot's performance. And it's not so obvious for a begineer, isn't it?P.S. I once had a problem explaining to a experienced developer that ignoring methodologies is a chosen methodology by itself...
#7 Submitted by Peter Walen on Mon, 03/28/2005 - 12:54pm.
"Any process that tries to reduce software development to a "no brainer" will eventually produce just that: a product developed by people without brains."Absolutely!
#8 Submitted by Robert M Melendez on Mon, 03/28/2005 - 12:22pm.
I very much like your title. Can I expect to see "Season to Taste" in the near future?
#9 Submitted by Richard Whitehead on Tue, 03/29/2005 - 5:51pm.
I think I agree 100%. Learning and communication? Now that you mention it, absolutely.
#10 Submitted by Tanmay Vora on Tue, 03/29/2005 - 4:03am.
I so agree with you when you say that the two most important ingredients for successful software development are learning and communication. One more key ingredient is the practical application of these learnings - about technology, processes and people. Software development is all about taking a practical approach and using lots of common-sense to get the best results. Look forward to some exciting stuff ahead.