Forgot your password?
typodupeerror
Book Reviews Books Media

Practices of an Agile Developer 172

Posted by samzenpus
from the stretch-first dept.
Cory Foy writes ""Whatever you do, don't touch that module of code. The guy who wrote it is no longer here, and no one knows how it works." In Practices of an Agile Developer, Venkat Subramaniam and Andy Hunt put that quote as an example of something we are all afraid to hear, but probably have in our careers. They then go on to list a collection of practices which can keep you from hearing, or worse, saying that phrase. How do they do?" Read the rest of Cory's review for the answer.
Practices of an Agile Developer
author Venkat Subramaniam and Andy Hunt
pages 184
publisher Pragmatic Programmers
rating Buy
reviewer Cory Foy
ISBN 0-9745140-8-X
summary A book to become a better developer (even without the agile part)


I was excited when I received this book. Having gotten the chance to meet and talk with both Venkat and Andy, I knew they were passionate about getting developers to understand how to deliver value to the customers. Both are proponents of Agile development in one form or another (XP, Scrum, Crystal etc). But rather than try to sell you on one of the methodologies, they laid out seven goals: Beginning Agility, Feeding Agility, Delivering What Users Want, Agile Feedback, Agile Coding, Agile Debugging, and Agile Collaboration

In the first, Beginning Agility, they lay out the basics of becoming an Agile developer. Things like Working for Outcome (in other words, don't blame people for bugs, find out how to fix them and fix the process that caused them) and Criticize Ideas, Not People. Or avoiding the pitfalls of making quick hacks without trying to understand why the hack was necessary (Quick Fixes Become Quicksand). They finish up the chapter with a key word I personally feel is absolutely necessary in software development — courage. They put this in the context of Damn the Torpedoes, Go Ahead. In other words, if the code you are working on is stinky, and you'd like to throw it away, don't be afraid to bring that up. Or if code you are in the middle of building suddenly becomes the wrong direction, stand up and explain that (being sure that in both circumstances you have alternatives for getting it on the right track).

The second chapter, Feeding Agility, discusses ways to keep the flow going while being Agile. Things like Keeping Up With Change remind us to keep our skills sharp and honed. Invest in your Team shows that if you don't bother to spread your knowledge, they'll be unlikely to spread theirs with you, and if the goal is to deliver the best product we can to our customers, that just seems counterintuitive. Of course, it is just as important to Know When to Unlearn. Sure, that ASP solution you've had for 10 years works Ok, but that shouldn't stop you from exploring other new technologies. When you don't understand something, you should Question Until You Understand and finally Feel the Rhythm that Agile brings.

Now comes the contentious part. If our goal really is to deliver the most value to our customers that we can, then it makes sense that they should be able to drive the process. In Delivering What Users Want we hit some turbulent waters with topics like Let Customers Make Decisions, Let Design Guide, Not Dictate, and Fixed Prices are Broken Promises. But, to me, this is one of the most important chapters, and they do a good job of explaining how to accomplish all that with things like Getting Frequent Feedback, Automating Deployment Early, Integrate Early, Integrate Often, and Keep It Releasable. In addition, the use of Short Iterations and Releasing in Increments helps keep the flow going and communication with the customer high.

In order to keep up with the high level of customer communication (and confidence), you are going to need assurances your system is working properly. In Agile Feedback, Andy and Venkat discusses ways to get feedback in ways other than from your customer. At this point, if you've been on traditional projects, you are probably thinking the only way you could do this is with Angels on Your Shoulders, which they explain how to get with a safety net of automated unit tests. To really get a good sense of how to keep the design clean, they use techniques such as Use It Before You Build It and running it on a build machine other than your own since Different Makes a Difference. Finally, to understand how you are really doing, you have to Measure Real Progress which you can do through Automating Acceptance Testing (using something like FitNesse). Finally, you have to Listen To your Users. Similar to the way that you should treat compiler warnings as errors, customer complaints are a sign that something is wrong — especially if it is a high number of customers experiencing the problem.

Now that you are Agile with your customer, the authors begin to target the specific code you are writing in Agile Coding. This is a list of some key tenants of good development, such as Programming Intently and Expressively and Communicating in Code (and not chiefly through comments, either!). But there are some practices that are harder, but just as important like Keep It Simple, Actively Evaluate Trade-Offs and Code in Increments.

No matter how hard we try, though, defects still creep in. Or, we don't get the chance to work with pretty Greenfield code, but are dropped in the middle of a big ball of mud. How do we get out? In Agile Debugging, Andy and Venkat cover some great techniques including Warnings Are Really Errors (mentioned above), Report All Exceptions, and Provide Useful Error Messages.

But one of the techniques was something I had not done before, and I thought was excellent — a Solutions Log (also called a Daylog). In other words, when you come across a problem, document it, and when you solve it, document it. No doubt, you'll come across that problem again, and when you do you'll be glad to be able to go back and figure out how you solved it — especially if you don't have the code you fixed it in the first time. (I have a tendency to record anything I come across that I know I will see again on my blog, and I tell you that typing a question into Google and the first result being your own website is the perfect way to make you feel like a total moron).

The final section, Agile Collaboration, is my idea of a dream team. First, you have to Schedule Regular Face Time to talk about what is going on in the project — especially if you all are working on the same code base! You have to be able to practice Collective Code Ownership (meaning anyone should have the knowledge to change another part of the system), and also means that Architects Should Write Code. To help grow the team, you can Be A Mentor, but to do it effectively you have to Allow People To Figure It Out. Some final practices are around respecting your team by Sharing Code Only When It's Ready, being available to Review Code, and Keeping Others Informed about what you've learned.

I enjoyed the layout of the chapters too. Each one starts with a "devil" which often times was saying something I've heard on one team or another. It finishes with an "angel", and a section of what it feels like to be doing the practice. Andy and Venkat also pepper the text with plenty of real world situations that reinforce just how bad software development can be.

In summary, if you want to be a better developer, but think Agile is a misused buzz word, go to your local bookstore, put a small piece of masking tape over the word "Agile" in the title, and buy this book. You won't regret it.


You can purchase Practices of an Agile Developer from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Practices of an Agile Developer

Comments Filter:
  • Update on the link (Score:3, Informative)

    by Anonymous Coward on Wednesday November 29, 2006 @04:25PM (#17039062)
    The review here inexplicably links to B & N, who offer the book at a fairly high price compared to Amazon [amazon.com].
  • by LiquidCoooled (634315) on Wednesday November 29, 2006 @04:27PM (#17039098) Homepage Journal
    Then real life gets in the way and your first gen mock up becomes live code (after the boss sees it - "but its working, why do you need to rewrite it...") and you curse yourself every time you open that code.
    We have all got our monsters.
    • Re: (Score:3, Interesting)

      by turbidostato (878842)
      "Then real life gets in the way and your first gen mock up becomes live code (after the boss sees it - "but its working, why do you need to rewrite it...") and you curse yourself every time you open that code."

      Who wrote the code? You!

      You can be sure *you* are the one to blame, not your boss.

      If you are working on a mockup GUI, be sure no functionallity is within the demo.

      If you are working on a mockup funtional unit, be sure is terrifying ugly so no PHB will think it's ready.

      When you are programming, as a ge
      • I don't even go near a computer whilst developing - pencil and paper is best.

        If its something I am testing and playing with in a side project I get time to craft it into a final piece and this works nicely most of the time.
        The code I am talking about is just a tiny fraction of the entire system and I've cursed myself from the moment I opened my big gob (it was just one alternative export routine) and gave a quick demo (I was expecting dev time to move it into the real project properly).
        • by Dunbal (464142) on Wednesday November 29, 2006 @04:57PM (#17039596)
          I don't even go near a computer whilst developing - pencil and paper is best.

                (pulls up another pillow and offers a seat under the tree, on a hill overlooking the valley)

                (rolls up a "special cigarette")

                Man, I'm telling you. Paper and shit is all good. But, you've got to get real mellow like, and think about the problem (takes a drag on the "cigarette"). Yeah man. Mellow, and stuff. Like - what is the program for. What do I want it to do, an shit. And then after a while you can see it all, algorithms, subroutines, data structures, bounds checks. And THEN you get the pencil and paper - here, want some? (cue Indian sitar music)
        • by cmorriss (471077) on Wednesday November 29, 2006 @05:07PM (#17039722)
          Pencil and paper?! Bah! Why get bogged down with those new age mental encumbrances.

          When I get an assignment, I immediately pack my bags for a retreat high atop the canopy in the Amazon. I hunt for food and use the blood of my kill to jot down the design of my project on the backs of baby turtle shells, each representing a piece of functionality. Then I let them loose on the ground and follow them for days. Those that live through the ordeal will have a hollowed place in my design.

          • by Bamafan77 (565893) on Wednesday November 29, 2006 @07:17PM (#17041708)
            I hunt for food and use the blood of my kill to jot down the design of my project on the backs of baby turtle shells, each representing a piece of functionality. Then I let them loose on the ground and follow them for days. Those that live through the ordeal will have a hollowed place in my design.
            I think you misunderstood the chapter on "shell programming". See this is what happens when you bring these VB6-ers over to the Linux world. :)
      • by EnderWiggnz (39214) on Wednesday November 29, 2006 @04:56PM (#17039560)
        Wow, just wow.

        API's first, always. Everything else is easy to change, but if you eff up the API's, you are in a world of shit when they have to change.
      • by computational super (740265) on Wednesday November 29, 2006 @06:12PM (#17040798)
        When you are programming, as a general matter, first comes the comments, second the bound tests,

        third the job search after you get fired for "wasting so much time" and not being "agile enough to meet the business needs by just getting it done".

    • Exactly. We have just a small team of coders doing various projects and take pride in modular development that makes it easy for us to use each others classes when we design a program. It's easy to do while in the safe haven of developers hands. Then it get implemented and all of a sudden X feature needs to be implemented and Y data needs to be stored in Z class (unknown before despite countless design meetings). Now we have a choice, Take the time to modify all these nice classes so they have the added

    • Re: (Score:1, Insightful)

      by Anonymous Coward
      Do it right first time around. Writing good code doesn't take more effort than bad ones. In the long run, you save time.
      • When painting a picture, a pencil sketch can give you an idea of the balance without wasting time.
        If you start with oils and change your mind part way through it becomes a lot more troublesome to modify.

        Coding is the same - sometimes you just want to see something working to test the scope of a plan.
        If you produce production code first time everytime then congratulations to you, personally if its something new it will go through a number of rough sketches.
        • by shmlco (594907)
          "When painting a picture, a pencil sketch can give you an idea of the balance without wasting time. If you start with oils and change your mind part way through it becomes a lot more troublesome to modify."

          Next thing you know you'll be telling me not to do the NYT crossword puzzle in ink...
    • by CaptKilljoy (687808) on Wednesday November 29, 2006 @05:22PM (#17039950)
      The parent post illustrates an important point about Agile clearly.

      If:
      • your team can't say yes to nearly all of the points on the Joel test [joelonsoftware.com]
      • if you spend more time fighting fires than working on your project
      • if you couldn't honestly say your team is better than average
      • if your managment is more focused on getting it out the door than getting it right
      then Agile is not going to solve your problems. The basics of good software development have to be there first.

      Agile helps a good team become excellent, it doesn't fix the problems in a dysfunctional team.
      • by master_p (608214)
        All is well with the Joel test, except for #9 ("Do you use the best tools money can buy?"). Because some of the best tools out there are free/open source!
    • by ShieldW0lf (601553) on Wednesday November 29, 2006 @05:34PM (#17040122) Journal
      Good reusable code is empowering. Make them aware of it by giving that power to them. Example:

      Just last week I got asked to put some quick hacks in one of my clients sites to allow for some more discrete rights management for their client-facing site because they had one large client ask for it.

      I could have written an extra page that those clients get redirected to, some dangling crud in the database to support it and maintain it in an ever growing parallel with the rest of the system, or some other ugly hack that leads to unmaintainable code. That was specifically what they asked me to do.

      Instead I proposed that I extend the internal rights management used for employees to handle the client side of things, which was quite a bit more work, and a fair bit more expensive, but "Oh by the way, if we do it this way, I can trivially exploit this change to allow you to also discretely control rights for all this other functionality your clients are exposed to, and allow you to do it on a client by client basis in the future without needing to pay me to change the code."

      Don't just tell people that in some abstract fashion your "good coding techniques" are superior to the crufty crud that seems to work fine. Think of all the things that become trivial for you to deliver because of those good coding techniques, and make them part of the package.

      In other words, don't tell them you can take 5 days to deliver a "good" implementation that delivers the same functionality as working 2 days to deliver a "cruddy" implementation.

      Instead, tell them you can take 7 days to deliver a "good" implementation, and it will include all this extra functionality that they weren't asking for but what the hell, it's good value and it's the right way to do things too, so why not.

      If you can't find some way or another to make doing it the "right" way pay extra dividends that users can appreciate, maybe it's not really the right way...
      • If you can't find some way or another to make doing it the "right" way pay extra dividends that users can appreciate, maybe it's not really the right way...

        Sometimes the "cruddy" implementation is all they need. Why should they lose extra time and money to functionality they don't need? To borrow from the previous buzzphrase (Extreme Programming), once the unit test is green its good to go.

        Really it depends on the client and the situation. Sometimes (as you suggest) quality, reusability and maintainability

        • by eyeye (653962)
          It might be the shortest time *now* but later when you have to add other functionality on top of your hack then you are already on the slippery slope to a ball of spaghetti - and over time your code will take longer and longer to bugfix and add functionality to. Rushing through software dev is usually a false economy.

          I work with a couple of people who will code some functionality as quickly as they can so they can brag about how it only took them a couple of hours. Over the next weeks and months you find th
          • Again, it depends on the client and the situation. If they explicitly specify in the development contract they want it done the cheapest and fastest way possible, and you know there is no guarantee of you getting the maintenance contract afterwards because that goes out to a separate tender, well that's the way it's gotta be. I agree with you - it is a false economy as far as the client is concerned, and they should have all the information they need to make an informed decision, but ultimately it is theirs
      • by GWBasic (900357)

        In other words, don't tell them you can take 5 days to deliver a "good" implementation that delivers the same functionality as working 2 days to deliver a "cruddy" implementation.

        But sometimes you just don't have the extra 3 days. For example, I have very strict release cycles, yet what goes into a release is negotiable.

        For example, I currently am developing a class where the database takes about 0.25 seconds to return the corresponding row. For 99% of my program, this is fast enough because I'm only lo

    • Re: (Score:1, Informative)

      by Anonymous Coward
      The mock up code is supposed to become live code, you refactor constantly as you go. If you don't spend a significant amount of your time refactoring then A) you are not doing anything remotely agile and B) it's entirely your fault.

      That's the neat thing about agile, you can implements pieces of it at the team level--pulling the responsibility for certain things down a few rungs. Your refactoring time isn't scheduled separately but becomes part of your standard quoted times. Generally this should also imp
  • by Timesprout (579035) on Wednesday November 29, 2006 @04:31PM (#17039172)
    when you can limbo dance all the way to the office.
  • Courage ... (Score:3, Interesting)

    by Salvance (1014001) * on Wednesday November 29, 2006 @04:32PM (#17039174) Homepage Journal
    This was the first book review on here that I REALLY enjoyed. Very informative. I liked the idea of developers showing courage to fight for the right path, although I must add that this is best done without getting emotional or fired up. Courage is great when it is modest and controlled, otherwise you'll just be relegated to an even darker corner and reassigned to mainframe Cobol development.
    • by obender (546976)
      After reading your comment I realized I didn't even read the review. And your comment caught my eye only because it's next to a +Funny one.

      Now I am facing this dilemma: should I scroll up and read the review? That's like three maybe four page-ups.

      Nah, I have to set a limit. Next time I'll be reading the articles if I go on this path.

  • by Anonymous Coward on Wednesday November 29, 2006 @04:33PM (#17039188)
    So instead of:

    The guy who wrote it is no longer here, and no one knows how it works.

    It goes something like this:

    The guy who wrote it is so stupid, they promoted him, and everyone knows how it works because we all were forced to completely rewrite it.

    • So instead of:

      The guy who wrote it is no longer here, and no one knows how it works.

      It goes something like this:

      The guy who wrote it is so stupid, they promoted him, and everyone knows how it works because we all were forced to completely rewrite it.

      More like: The guy who wrote it is so stupid he's no longer here, and everyone knows how it works because we all were forced to completely rewrite it.

      At least that's what I've seen in my limited experience.

  • by neimon (713907) on Wednesday November 29, 2006 @04:34PM (#17039208)
    "Things like Working for Outcome (in other words, don't blame people for bugs, find out how to fix them and fix the process that caused them) and Criticize Ideas, Not People. Or avoiding the pitfalls of making quick hacks without trying to understand why the hack was necessary (Quick Fixes Become Quicksand). They finish up the chapter with a key word I personally feel is absolutely necessary in software development -- courage. They put this in the context of Damn the Torpedoes, Go Ahead. In other words, if the code you are working on is stinky, and you'd like to throw it away, don't be afraid to bring that up. Or if code you are in the middle of building suddenly becomes the wrong direction, stand up and explain that (being sure that in both circumstances you have alternatives for getting it on the right track)." I try to teach a) help desk people b) network engineers c) operators d) everyone I can ...to do these very things. It's called "giving a shit about your work and how it affects other people." Also known as "doing a good job." 'nuff said.
  • by Rhett's Dad (870139) * on Wednesday November 29, 2006 @04:37PM (#17039258) Homepage

    I read this about two months ago, and mostly enjoyed it. I don't remember anything earth-shattering or particularly enlightening from it, but then again I had previously read some other books that probably put a damper on what this book had to teach me:

    • Pragmatic Version Control
    • Pragmatic Unit Testing
    • Pragmatic Project Automation
    • Ship It!
    • Extreme Programming Explained
    • Art of UNIX Programming
    • Practice of Programming

    Seems like most of what the Agile book had in it was for me a rehash of the three Pragmatic books. So, to me, a good book by itself, but I'd recommend the three Pragmatic books instead of you have the time for that much reading.

    • by kfg (145172)
      I'd recommend the three Pragmatic books instead of you have the time for that much reading.

      And if you don't, guess what?

      Surprise! You're a code monkey, not a programmer.

      Which is all well and good if that is the path you chose in the first place. It's a living and someone has to do the assembly line type of work.

      But if you had something else in mind when you were 16 sitting in your room at 3 A.M. thinking "Oh, wow man!" it's time to make some changes.

      KFG
  • There is a pretty good audio interview with Andy Hunt about the book at http://perlcast.com/2006/07/12/practices-of-an-agi le-developer/ [perlcast.com].
  • ...all you actually need. Good code comments are nice, and explicit variable naming (instead of lazy naming) are pluses as well.

    "I have to implement feature , the requirements doc (if any) can be found at: A synopsis of the feature is: In order to satisfy those needs architecturally, I've decided to implement like because we want to avoid using because it prevents us from in the future..."

    These docs are usually a page in a half for a complicated feature that has a potentially confusing architectur
  • Worth a read (Score:5, Informative)

    by Taagehornet (984739) on Wednesday November 29, 2006 @04:45PM (#17039402)
    Martin Fowler has written a few words on the subject Is Design Dead? [martinfowler.com]

    Highly recommended, grab a cup of coffee ...or two ;)

  • I'm about to finish Venkat's semester long class on software engineering at the University of Houston. Actually I have a team demo in a few hours! (what am I doing on Slashdot.. hehe)

    I've been very impressed with Venkat's teaching and am convinced that Agile development models are beneficial for commercial application development. The main advantages are its adaptive planning and methods for predicting how long development is going to take mixed with customer communication.

    That said, I'm not yet con
    • by zurmagus (409978)
      I'm in Venkat's Software Enginnering class also. When I read the opening quote I immediately recalled him saying that in one of the lectures so I just knew the name Venkat would follow it.

      He is an excellent professor (but sadly he is only teaching for one more semester) and his viewpoints on software development are always insightful. Anyone who has an opportunity to take classes from him or go to a development conference where he will be speaking should definately take advantage of it.

      Everyone can learn so
    • by Safety Cap (253500) on Wednesday November 29, 2006 @08:24PM (#17042444) Homepage Journal
      I've been very impressed with Venkat's teaching...

      Yes, he's very enthusiastic about whatever subject he's teaching. Too bad he took so much time out of class to travel and lecture at other companies, though.

      ...and am convinced that Agile development models are beneficial for commercial application development.
      You might want to read a dissenting opinion [blogspot.com]. Having been on both Agile and non-Agile development projects, my own experience is that some Agile techniques are beneficial for some projects, but anyone who says that Agile is the magic pill that will ensure maximum productivity is both smoking and selling you something.
  • by ShaunC (203807) * on Wednesday November 29, 2006 @04:51PM (#17039486)
    It's clear that to be an agile programmer, you simply have to Create Catchy Techniques and learn how to Capitalize On the Shift Key. I'm about ready to Pry Out my Eyeballs...
  • by mollymoo (202721) on Wednesday November 29, 2006 @05:00PM (#17039626) Journal
    Am I the only person who had to Stop Reading the Book Review half-way through because of Capitalisation Overload? There Are other ways to emphasise or to indicate a "phrase from the book" which are much Less Annoying Than Doing This.
    • by sammy baby (14909) on Wednesday November 29, 2006 @05:14PM (#17039832) Journal
      There Is Historical Precedent For This.

      (Unfortunately, that doesn't make it any less annoying...)

      XP [wikipedia.org], arguably the 600 pound gorilla of the "agile methodologies," was created by Kent Beck, Ward Cunningham, and Ron Jeffries. It was a direct outgrowth of their work the "Chrysler Comprehensive Compensation (C3) System," and information about their brand new methodology was publicized on a little web site Cunningham had put together.

      It just so happened that the "little web site" was the very first Wiki [c2.com]. One of the side effects here is that since each of the XP principles got its own page, it also got its VeryOwnNameInCamelCase. The weird capitalization of the rules is an artifact of agile methodologies' debt to the wiki format.

      Or something. I think.
    • Re: (Score:2, Informative)

      Those are TOC sections.
    • I always found john DVORAK's columns to be annoying, though I think in the one or two that I've read in more recent years, he may have dropped the habit of making every tenth word bold.
    • by Anml4ixoye (264762) on Wednesday November 29, 2006 @09:51PM (#17043452) Homepage
      (Disclaimer: I'm the reviewer)

      Someone else already pointed it out, but those are the sections. Trust me, I wouldn't have written it that way if it wasn't.
  • arrrggghhhhh (Score:3, Insightful)

    by mlwmohawk (801821) on Wednesday November 29, 2006 @05:00PM (#17039634)
    I just can't stand it. How many books and programming fads must we endure in our careers?

    "Agile" programming? ATF, sorry, but come on.

    Like all the other programming fads, there are elements of good standard practices that, if you've been writing code for any length of time, already do, but then they go on to preach their own brand of mumbo jumbo.

    Now, some PHB is going to want to push "agile" programming. Just stupid.

    OK, rant. THE CUSTOMER SHOULD NOT DRIVE DEVELOPMENT. There I've said it. The customer has no figgen clue about what development is or means.

    Short story: I was working at a company years ago, a VP of development wanted to be able to dial out and use a terminal programs on his PC from our office phone system. I asked him, point blank, tell me exactly what you need. He responded, "I just need to be able to connect to a modem and dial out." (exact words burned into my brain)

    So, we bought $20,000 worth of phone equipment that did just that, alowed a PC's modem to be plugged into a wall, and dial out.

    He came to my office and said, I can't use this system. I asked why? He said the modem banks weren't "hayes compatible." I looked at him, told him his exact words after being asked "exactly" what he needed, and he said (rather annoyed) "well, you should have known I needed "hayes compatible."

    Moral of the story: the user don't know squat about what they want, let alone are able to navigate the technical landscape.

    As engineers, we have to learn with the customer knows and apply it to the program, but do not confuse this with letting the customer drive!
    • Re: (Score:3, Insightful)

      by chromatic (9471)
      The customer has no figgen clue about what development is or means.

      If the person paying you to write software doesn't get to tell you what the software should do, who does?

      I went to a fancy restaurant like that once. You pay $150 and get whatever the meal of the day is. Unfortunately, the main course was salmon and I'm allergic to fish, so I left. I heard it was nice, though I've never gone back.

      • Re: (Score:3, Interesting)

        by mlwmohawk (801821)
        If the person paying you to write software doesn't get to tell you what the software should do, who does?

        The customer does not pay me to "write software" they pay me to provide a tool that helps them accomplish a task. It is a fine line, for sure, but an important one. It is up to me, and any other engineer, to understand what our customer knows and apply it to what ever we are developing.

        Letting the customer drive the product is a bad idea. Too often the customer is reluctant to see beyond their immediate
        • Re: (Score:3, Insightful)

          by turgid (580780)

          Ultimately, the customer will be dissatisfied with anything they have a hand in producing, because it will be limited by their own immediate needs.

          ...and their own imagination.

          Can someone please inscribe this on a granite tablet and install it in the British Museum for all to see?

    • Re:arrrggghhhhh (Score:4, Insightful)

      by Ramses0 (63476) on Wednesday November 29, 2006 @05:26PM (#17040010)
      """He responded, "I just need to be able to connect to a modem and dial out.""""

      Engineer says: "B.S. - Be Specific", what is your app, what is the requirement, why do you need to dial out, what do you need to connect to, etc. And in any case, once the customer asks for "X", signs off on it, and it turns out they really needed "Y", it's best to get that over with as soon as possible and start working on "Y".

      The user actually knows *exactly and precisely* what they want, it's just that they have a tough time expressing it most of the time, and it's quite probable that what they want is not possible in the timeline / budget / etc. that they have allocated for that need.

      So, figure out what a customer *wants*, keep them FAR away from anything remotely technical, but make sure the technical decisions that the engineering team makes satisfy what the customer *wants*.

      --Robert
      • by mlwmohawk (801821)
        The user actually knows *exactly and precisely* what they want, it's just that they have a tough time expressing it most of the time, and it's quite probable that what they want is not possible in the timeline / budget / etc. that they have allocated for that need.

        I stongly disagree, I've been doing to stuff for a while, and let me tell you, I witnessed people resisting wordprocessors in the office because they thought they were more complicated, harder to use, etc.

        The customer who is used to using typewrit
        • by jchenx (267053)

          I stongly disagree, I've been doing to stuff for a while, and let me tell you, I witnessed people resisting wordprocessors in the office because they thought they were more complicated, harder to use, etc.

          The customer who is used to using typewriters will NEVER be able to help you spec out a word processor.

          They DON'T understand what technology can do and thus can not fully understand how to apply it.

          That's a really bad attitude. Granted, there are some Luddites that don't understand technology, are afraid o

        • by Bertie (87778)
          And nor should they. That's your job. Watch what they do, find out what works, find out what doesn't, and give them a new solution that builds on the strengths and alleviates the weaknesses of the old one. If the application of clever technology is the right way to achieve this, that's what you do. If it isn't, and sometimes it isn't, don't force it down their throats.

          Then give your solution back to them, watch how they get on with it, see what they think of it. Learn your lessons and roll them back in
          • by mlwmohawk (801821)
            I am amazed that no one who has responded noticed that I said you have to learn what your customer knows.
    • Re: (Score:3, Insightful)

      by Harri (100020)
      The customer makes decisions in business terms, not in technical terms. It's your job to translate their business needs into technical needs - and to ask the right questions to be able to do so. You're the expert about the technology - but you're not the expert about their business.
      • by mlwmohawk (801821)
        The customer makes decisions in business terms, not in technical terms. It's your job to translate their business needs into technical needs - and to ask the right questions to be able to do so. You're the expert about the technology - but you're not the expert about their business.

        A previous post reminded me about early word processing adoption.

        In the late 70s and early 80s, there was serious resistence to word processors, because people didn't want them. They saved paper, made tasks easier, allowed better
        • Re: (Score:3, Interesting)

          by Harri (100020)
          For sure, it's possible for engineers to invent things that customers wouldn't have imagined. But those innovations are still going to have to produce business value for the customers, or else the innovations are of no use (or nobody will pay for them, which is just as bad for the engineers).

          It's still possible to say to the customer "We can make exactly what you do a little easier, for $X, or we can provide you with the following extra benefits to your business for $Y - which would you like?". Ultimately,
    • by Petersko (564140) on Wednesday November 29, 2006 @05:36PM (#17040162)
      Short story: I was working at a company years ago, a VP of development wanted to be able to dial out and use a terminal programs on his PC from our office phone system. I asked him, point blank, tell me exactly what you need. He responded, "I just need to be able to connect to a modem and dial out." (exact words burned into my brain)...So, we bought $20,000 worth of phone equipment that did just that, alowed a PC's modem to be plugged into a wall, and dial out...He came to my office and said, I can't use this system. I asked why? He said the modem banks weren't "hayes compatible." I looked at him, told him his exact words after being asked "exactly" what he needed, and he said (rather annoyed) "well, you should have known I needed "hayes compatible."

      So you, the technology expert, bought $20,000 worth of equipment on a one sentence verbal spec... and it's HIS fault?

      Isn't this a rather collosal, and unforgiveable, failure on your part?
      • by mlwmohawk (801821)
        So you, the technology expert, bought $20,000 worth of equipment on a one sentence verbal spec... and it's HIS fault?

        Well, trying to make a long story short, it wasn't merely verbal, he did sumit a requisition, it was approved, etc.

        It didn't make a difference, he didn't even know what he wanted,
        • Well, naturally. (Score:3, Insightful)

          by Petersko (564140)
          "It didn't make a difference, he didn't even know what he wanted,"

          Well naturally he didn't. If he knew exactly what he wanted, he'd just order it himself.

          I don't have quite the background that some here do (6 years in support followed by 8 years in development), but even early on in my career I knew that "tell me exactly what you want" never, ever works. Even for relatively trivial things.

          I'd like to know how you found hayes-incompatible equipment though - that must have taken some work!
      • So you, the technology expert, bought $20,000 worth of equipment on a one sentence verbal spec... and it's HIS fault?

        You're suprised at that?
         
        Reading Slashdot one finds an endless parade of excuses from IT workers why every failure, big and small, is not their fault. It's always the boss, the methodology, the particular shade of green on the walls of the office bathroom...
        • I'm blaming the people skills of most geeks. I.T. people tend to be less people oriented. Gross generalisation alert: For some reason the more tech you are the less people and vice-versa.

          I.T, whether programming, database management, system administration or whatever, is all about working for a business, run by people. Please them, and you'll get the job done, right. (I'm guilty of forgetting users. Occasionally I need to pour a large glass of perspective and soda).

          I remember my University days, precious li
      • by Stormie (708) on Thursday November 30, 2006 @12:51AM (#17045070) Homepage
        Isn't this a rather collosal, and unforgiveable, failure on your part?
        Well, he did say that he was working at that company. Past tense. I'd have fired his ass, too.
    • I used to think like this as well, but as I've been on more and more projects, I've found that an interview with the stakeholder is typically well worth the time taken, even if they don't know what they want, you can provide options and allow them to pick. Hindsight is always 20/20 but I promise you that if you ask the tougher questions by learning the business process behind it, your job will become much easier.
      • by mlwmohawk (801821)
        I used to think like this as well, but as I've been on more and more projects, I've found that an interview with the stakeholder is typically well worth the time taken, even if they don't know what they want, you can provide options and allow them to pick. Hindsight is always 20/20 but I promise you that if you ask the tougher questions by learning the business process behind it, your job will become much easier.

        In my original post I say, point blank, we have to learn what the customer knows. We have to be
    • by Quintios (594318)
      I'm probably going to get flamed for this, but I have to ask: Why didn't you test the system against his computer? Seemed like he was asking for a specific solution to his problem (the problem of not being able to dial out using HIS computer). Maybe I'm missing the point here, but it sounds like you never verified that the equipment you were installing worked with the existing equipment, i.e. you installed equipment that was not compatible because you never verified that it would work with the existing
      • by mlwmohawk (801821)
        I'm probably going to get flamed for this, but I have to ask: Why didn't you test the system against his computer? Seemed like he was asking for a specific solution to his problem (the problem of not being able to dial out using HIS computer). Maybe I'm missing the point here, but it sounds like you never verified that the equipment you were installing worked with the existing equipment, i.e. you installed equipment that was not compatible because you never verified that it would work with the existing inst
    • by Coryoth (254751)

      Short story: I was working at a company years ago, a VP of development wanted to be able to dial out and use a terminal programs on his PC from our office phone system. I asked him, point blank, tell me exactly what you need. He responded, "I just need to be able to connect to a modem and dial out." (exact words burned into my brain)

      So, we bought $20,000 worth of phone equipment that did just that, alowed a PC's modem to be plugged into a wall, and dial out.

      He came to my office and said, I can't use this sy

      • I'm beginning to think that working with customers to develop a specification is actually a suffciently hard job that it should be a specialised position - lord knows enough developers seem to have little in the way of an idea about it.

        There's a job title of "sales engineer" though too often the person AND the job the person fills falls way short of the goal.
    • "I just need to be able to connect to a modem and dial out."
      you should have asked, "Our digital PBX system isn't compatible with a computer modem, can we run a decicated phone line to your computer which will cost about $500.00 to install and $45.00 a month afterwards instead spending $20,000 on a bank of PBX modems?"
      People don't know what they want or need, they only know what they think they want or need, the hard part is first getting their wants and needs to coincide, then to get their real wants and ne
    • by Bertie (87778)
      Well, if that's your idea of requirements capture, you deserved all the pain you got.

      Customers know what they want. But they can't express it. Your job is to make sure you both arrive at the same understanding of what the customer wants, and you get there by asking the right questions.

      Think about it - I hand you a blank piece of paper and say "draw me a picture". A lot of people have trouble with this - they don't know where to start, they don't know what they want to draw, they don't know what I'd like
    • by o'reor (581921)

      OK, rant. THE CUSTOMER SHOULD NOT DRIVE DEVELOPMENT. There I've said it. The customer has no figgen clue about what development is or means.

      "the customer *usually* has no figgen clue" would be a better way to put it.

      Here I am in a position where my company, as a customer, has asked a software company for a piece of software (a Java GUI for the hardware we produce, to be specific) a few months ago, with a number of evolutions on that software. The trouble was, since that company could not afford to have a

  • Nice review. This just reminds me again that I need to take time out regularly to study not only new technology, new methodologies. Thanks for pointing out what appears to be a good book!
  • "... Nobody here is really sure what the code does, the programmer has left. We think that the ?answerset methods were added as part of an incomplete implementation without disabling the static behaviour which we think is of no use. If this doesn't make things clear than can we continue by phone .."
  • There's a lot of focus on the methodologies the Developers need to focus on to achive agility. For me the biggest challenge in my current organization has not been the developers doing things the agile way but getting the customer (or in our case product development... the customer's representative) to be able to think in smaller, self-contained chunks. Some of this may be that we are dealing with a complete rewrite of an existing system... perhaps agile is better suited towards incremental improvements of
  • This is the hangover from Extreme Programming and downsizing. Welcome to deferred costs.

If a 6600 used paper tape instead of core memory, it would use up tape at about 30 miles/second. -- Grishman, Assembly Language Programming

Working...