Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Programming Books Media Book Reviews IT Technology

Lean Software Development 135

Posted by timothy from the jack-sprat's-second-marriage dept.
Jim Holmes writes "Mary and Tom Poppendieck's Lean Software Development: An Agile Toolkit is a great read for anyone interested in agile software development. That includes developers, leads, and managers interested in speeding up development cycles, improving quality, and getting their customers the best value. This book's been out since May, 2003, but it's well worth picking up. The concepts within are absolutely applicable now, and will continue to be for quite a few years." Read on for the rest of Holmes' review.
Lean Software Development: An Agile Toolkit
author Mary and Tom Poppendieck
pages 240
publisher Addison Wesley
rating 9
reviewer Jim Holmes
ISBN 0321150783
summary Toolkit for getting agile development in your organization.


Lean Software Development is full of pertinent comparisons between the current state of software development and the massive changes in manufacturing over the last three decades, specifically demonstrated by the Toyota Production System, and 3M's innovative atmosphere for bringing products to life. The Poppendiecks make a great case as to how similar changes in software development can reap great benefits in the software production industry.

Who It's For

The book's very useful for anyone involved in or around the software development process: developers, leads, managers, and corner-office types. Corner-office types won't get as much out of the book as those in the trenches, but the Poppendiecks' arguments against overly-constraining process management systems may help high-level managers come to understand that such systems can actually hurt production.

Who It's Not For

This book isn't for closed-minded folks who think the waterfall method and a preponderance of documentation and process control are the bee's knees. The book talks specifically about how Six Sigma, Capability Maturity Model (CMM), Capability Maturity Model Integration (CMMI), and Project Management Institute (PMI) certification can drag down development productivity and quality. Also, it's not for folks who are unwilling to consider that shorter delivery cycles improve feedback, quality, and lower cost.

(Note that the authors specifically point out that agile development does not mean tossing out all documentation and process.)

What It Covers

The book is labeled a "toolkit" for lean development, and it describes 22 "tools" -- that is, approaches which will help an organization move to a leaner development system. The authors start off with a great explanation of what lean practices are and how they can benefit software development. They then move on to more detailed coverage of important principles.

The book's broken into chapters covering the seven principles the Poppendiecks lay out as fundamental to agile practices: eliminating waste, amplifying learning, deciding as late as possible, delivering as fast as possible, empowering the team, building in integrity, and seeing the whole. Those seven principles may sound like marketing blabberspeak, but the Poppendiecks nail each section down with terrific discussions of applicability.

They've also got great examples tying the principles into how manufacturing has so drastically improved its processes. Each chapter concludes with a "Try This" section aimed at getting your group moving in a lean direction.

The second biggest benefit after the book's content is the extensive reference list. There's an impressive bibliography, and each chapter is loaded with footnotes referencing various books, articles, etc. This gives interested folks a great guide for further reading.

The book's summary chapter is especially good. It concisely wraps up the book in the somewhat tongue-in-cheek format of an instruction sheet for the tools the Poppendiecks have laid out. The "Caution - Use Only As Directed" section is particularly useful because it shows how one should not use the principles: "Eliminate waste does not mean throw away all documentation," and "Deliver as fast as possible does not mean rush and do sloppy work." The summary also breaks out high-level details for implementing in large and small companies. The authors are particularly helpful in pointing out strategies for dealing with difficult process improvement programs such as Six Sigma, CMM, and/or CMMI. They point out the political aspect of how to approach implementing agile methodologies in organizations constrained by such "helpful" policy systems.

There's also a note for folks working in safety-related fields where regulations and immense processes dictate how to do work: Shortening cycles in such environments can better ensure people aren't killed by software failure.

What It Doesn't Cover

Despite the great coverage of the principles and tools, this book isn't a detailed guide for implementing agile processes at your organization. The authors are very adamant that no two organizations function alike. Implementing agile processes requires some careful forethought before jumping in. The authors don't advocate any one methodology over another, so don't look to this book for help in deciding whether you want XP, FDD, SCRUM, or any one of the other alphabet-soup-of-the-day agile buzzwords.

Additionally, I thought a few items were given pretty cursory coverage. One example is in the chapter on late decisions where the authors breeze right over implementing a quick persistence layer to put off deciding on exact database implementation. I particularly would have liked more detail in that item. On the flip side of that; however, is the great detail given to value stream mapping, feature implementation burn rates, and several other very, very useful items - so my complaint is really that one particular item I'm working on right now wasn't covered as well as I'd have liked.

Bottom Line

This really is an important addition to your reading list if you're at all interested in learning how an agile environment can increase your speed, quality, and cost effectiveness. It's a great book if you're in need of guidance on how to look at and improve your current environment. It's also a great book if you need backup for convincing either your co-workers or management that a move to agile is necessary.

You can purchase Lean Software Development: An Agile Toolkit 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.

Lean Software Development More

Lean Software Development

Comments Filter:
  • What an unfortunate last name the authors have.

  • eXtreme Programming? (Score:3, Funny)

    by Karma_fucker_sucker ( 898393 ) on Wednesday August 31, 2005 @02:18PM (#13448066)
    What's this? A repackaging of eXtreme Programming?

    I'll have to write a book myself: "Anorexic Programming" by Smart Ass. "The Ultimate in Lean and eXtreme Programming"!

    • It's like the Taco Bell Menu. Extreme Programming is more spicy, has more cheese, sour cream, etc... Lean programming, is with chicken, diet soda, and "lite" sour cream.
    • I don't know the timeline so I can't say if this is repackaging XP, or vice versa. But Lean Programming has been around for awhile.

      There are a lot of similarities to XP. God forbid we have two similar development methodologies. What's next? One operating system;')

      • Re:eXtreme Programming? (Score:3, Informative)

        by dubl-u ( 51156 ) *
        There are a lot of similarities to XP.

        And there's no competition there. The Poppendiecks led several sessions at Agile 2005 [agile2005.org], the big XP conference in the US. XP is much more about what goes on at the team level, while the Poppeniecks are more interested in broader business and corporate culture issues.
    • I'll have to write a book myself: "Anorexic Programming" by Smart Ass. "The Ultimate in Lean and eXtreme Programming"!

      I'll wait for the follow-up, "Bulemic Programming: Avoiding Binge and Purge Coding." That's a title that would grab my attention. We've been doing that here long enough that the code base needs a major purge (refactor). I just hope I don't end up with it on my shoes....

    • Requirements? (Score:2, Insightful)

      by I_Want_This_ID ( 678839 )
      I don't have a problem with most of these development methodologies perse, but most of them seem to lack the entire concept of DATA and INFORMATION.

      I haven't read the theoreticals of a lot of these methodologies but have worked in several places that say they practice them. What I've found is a bunch of developers (not saying anything about their programming skills) that don't understand databases or design of data structures. I find it difficult to extend many of these systems that are frankly poorly desig
      • Good code comes from good programmers. Whatever the methodology, you wont get a clean design from somebody who doesnt have experience. I think quite a few managers forget that. If you hire a guy just out of a technical school because you can pay him only 50K/year than dont wonder if you get dirty code.
        The book talk quite a bit about the importance to have competent people at the right place (seems like an obvious advice, but ...)
      • I don't have a problem with most of these development methodologies perse, but most of them seem to lack the entire concept of DATA and INFORMATION.

        You should check out things like Agile Modelling [agilemodeling.com] and Agile Data [agiledata.org] for more information. I don't think it's core to agile methods, as not every application uses a database. But if you're big into databases, these sites can help you see how agile approaches could work in your environment.

        Do these methodologies include some prep work on gathering business requirement
    • I'll have to write a book myself: "Anorexic Programming" by Smart Ass. "The Ultimate in Lean and eXtreme Programming"!

      If you can somehow emphasize the naturally low-carb properties of this programming technique I think you'll have a winner...
    • Lean manufacturing was around in the 70's, based on the Toyota Production System. Agile is an application of lean princples to Software Development. Or more accurately, if you apply lean principles and tools to software development, you get Agile practices, since Agile practices are the natural result of Lean thinking.

      More importantly, Mary has delivered real product from more projects than most of us have ever attempted. She brings real credentials earned in product development to the table. What do yo

  • Close-minded persons (Score:3, Funny)

    by lilrowdy18 ( 870767 ) on Wednesday August 31, 2005 @02:18PM (#13448067)

    I think the waterfall method and a preponderance of documentation and process control are the bee's knees.

    Seriously, who uses the phrase "bee's knees" anyway and what is so great about bee's knees?

    • Re:Close-minded persons (Score:5, Informative)

      by ch-chuck ( 9622 ) on Wednesday August 31, 2005 @02:26PM (#13448131) Homepage
      A bee's "corbiculae", or pollen-baskets, are located on its tibiae (midsegments of its legs). The phrase "the bee's knees", meaning "the height of excellence", became popular in the U.S. in the 1920s, along with "the cat's whiskers" (possibly from the use of these in radio crystal sets), "the cat's pajamas" (pyjamas were still new enough to be daring), and similar phrases which made less sense and didn't endure: "the eel's ankle", "the elephant's instep", "the snake's hip". Stories in circulation about the phrase's origin include: "b's and e's", short for "be-alls and end-alls"; and a corruption of "business".

    • Seriously, who uses the phrase "bee's knees" anyway and what is so great about bee's knees?

      I guess it's more PC than saying something is "the cat's ass". Much like saying "poop" or "#2" instead of "shit".
    • They're perfectly formed, smooth and supple, thats whats great about them.

      I flex them regularly, and rub them with baby oil every evening.

      Ive just ordered the book, so I will wear shorts, place the book between my perfect patellas, walk down the street, and passing people will exclaim "Cor Blimey!" and "What a fantastic threesome!".

  • Yeah right. (Score:4, Insightful)

    by BluedemonX ( 198949 ) on Wednesday August 31, 2005 @02:18PM (#13448071)
    RE: "Eliminate waste does not mean throw away all documentation,"

    Cobblers!

    I remember distinctly reading on some Agile XP whatever site that CRC cards (the documentation is the code and unit tests!) are used long enough to get the devs on board with what to do AND THEN THEY ARE DISCARDED.

    Stuff's real good if you're doing your comp sci 101 homework but in the real world you need a process.
    • I remember distinctly reading on some Agile XP whatever site that CRC cards (the documentation is the code and unit tests!) are used long enough to get the devs on board with what to do AND THEN THEY ARE DISCARDED.

      CRC cards are not documentation. They are an artifact of the development process. You can hang onto them for historical records if you find them useful, but they are inherently out of synch with the final product (except by coincidence).

      • Re:Yeah right. (Score:4, Interesting)

        by ChaseTec ( 447725 ) <chase@osdev.org> on Wednesday August 31, 2005 @03:30PM (#13448634) Homepage
        CRC cards are not documentation. They are an artifact of the development process. You can hang onto them for historical records if you find them useful, but they are inherently out of synch with the final product (except by coincidence).

        Remove the mention of CRC cards and you've perfectly described documentation.

    • Re:Yeah right. (Score:4, Informative)

      by dubl-u ( 51156 ) * <<ot.atop> <ta> <2107893252>> on Wednesday August 31, 2005 @04:49PM (#13449291)
      I remember distinctly reading on some Agile XP whatever site that CRC cards (the documentation is the code and unit tests!) are used long enough to get the devs on board with what to do AND THEN THEY ARE DISCARDED.

      Yeah, people often freak out about that. I tell them, "Ok, then you can keep the cards." They will happily put them in a box and then never look at them again. Myself, I don't use CRC cards much, I just sketch UML on the whiteboard. I do tend to leave the last few months of story cards up on the wall, though.

      Note that the most important documentation on an XP project is the acceptance tests, which you can think of as either machine-verifiable specs or automated versions of what QA people often do manually. Those say what the product is supposed to do. One framework for this is FIT [c2.com], which uses specially structured tables in HTML documents.

      Unit tests, on the other hand, are where developers say what individual chunks of the code are supposed to do.
  • What the hell is anorexic programming, would that be like...aww screw it I can't think of anything.

  • Seems to me like it's an oxymoron... (Score:4, Insightful)

    by GecKo213 ( 890491 ) on Wednesday August 31, 2005 @02:22PM (#13448098) Homepage
    This book isn't for closed-minded folks who think the waterfall method and a preponderance of documentation and process control are the bee's knees.

    Most upper management are only about those things! Besides, having coded for companies before, I know that if you don't properly document your code and make sure you have a preponderance for process control in place typically the whole thing goes to shit. And what is this about the bee's knees!?

    • Besides, having coded for companies before, I know that if you don't properly document your code and make sure you have a preponderance for process control in place typically the whole thing goes to shit.

      The Agile movement is about the notion that there's another way to keep things from going to shit.

      And what is this about the bee's knees!?

      A quick Google search [google.com] gets you three explanations in the first 10 results.

    • Re:Seems to me like it's an oxymoron... (Score:4, Insightful)

      by kaoshin ( 110328 ) on Wednesday August 31, 2005 @03:11PM (#13448475)
      "the issue is one of understanding, not of documentation, therefore you should not overrate the value of documentation. Your goal is to ensure that maintenance developers understand how the system works so they can evolve it over time, not to produce a mound of documentation that they may or may not use."

      -Taken from this essay on agile documentation [agilemodeling.com]

      I agree with the above, but it is my experience that the reinforcement on developers generally needs to be in creating more documentation. The environment will naturally make all the difference. In the nasty corporate arena (my habitat), many people feel that being the only one who knows something, is their ticket to job security. As a result, they will not comment code or divulge information to anyone, etc. Unfortunately, management encourages these insecure people through among other things, a lack of employee loyalty and an eagerness to cut costs by giving valuable and veteran employees the axe, among other nasty things. Thats my take anyway.

      Bed goes up. Bed goes down. - Homer Simpson

      • I agree with the above, but it is my experience that the reinforcement on developers generally needs to be in creating more documentation. The environment will naturally make all the difference. In the nasty corporate arena (my habitat), many people feel that being the only one who knows something, is their ticket to job security. As a result, they will not comment code or divulge information to anyone, etc.

        Ask yourself what goals you're trying to achieve with documentation. It sounds like you care most abo
    • You go into any corporate software "design" or "requirements" meeting and over half the attendee's will contribute nothing but useless documentation or Microsoft Project files about the 2-3 folks who actually do the work.

      Process employs these losers. We need PROCESS!! And LOTS of IT.

  • Lean Six Sigma? (Score:4, Informative)

    by notdanielp ( 244035 ) <dpritchett&gmail,com> on Wednesday August 31, 2005 @02:27PM (#13448144)
    Is this a derivative of the methodologies behind Lean Six Sigma [isixsigma.com]?

    There's big money in that, my graduate software engineering course last semester had a speaker in from a NASA contractor that pushed LSS as a way to manage all kinds of different engineering and production variances e.g. misfiring rocket engines.

    • Re:Lean Six Sigma? (Score:4, Informative)

      by etedronai ( 35656 ) * on Wednesday August 31, 2005 @03:32PM (#13448647)
      I don't think that six sigma and agile software development are derivatives of each other. Agile Software Development is actually meant to attack a different kind of problem than Six Sigma, even Lean Six Sigma, is meant to attack. The idea behind Six Sigma is that you can get more efficiency out of a process by always doing things exactly the same way. Try to cut down on the variance as much as possible. This is why it does well with production line/engineering type activities.

      The idea behind agile software development is that you can not apply production line type ideas to software development because two software development projects are never the same. This is why estimating and planning for them is so difficult. Agile software development says that you should just admit that developing a software product is more like research and less like running a production line and plan it accordingly. This means doing short explorative iterations that slowly build up to a larger deliverable and constantly inspecting the process and the schedule and making course corrections on the schedule.
      • I agree with your points on Agile Development. It is definitely meant to allow maximum mobility for a development team in the hopes of ensuring relevance and focus.

        I would say that LSS is somewhere in the middle, recognizing that a large enough project needs some structure while allowing a certain amount of mobility within said structure.
        • ... recognizing that a large enough project needs some structure ...

          Do you agree with that? In my experience, the size of the project is independent of the "structure". I use a CM system whether I'm working by myself or part of a 50 person team. I require having a way to repeatably build and test the product. I make sure that assembling all the artifacts for a release is as simple as pushing a button.
          • While I feel that all projects deserve structure, I also feel that the possibility of fininshing an unstructured project is inversely proportional to project size.
      • Six sigma is more about production processes, but Lean product development certainly has a lot in common with agile methods. It takes a bit more rigourous approach to the process though -- development certainly isn't research and there are lots of opportunities for reuse of old lessons and/or artifacts, for example.
    • Lean Six Sigma is an application of Lean practice and principles to Six Sigma quality control.

      They both come from the same background, which is nicely summed up in The Machine That Changed The World [amazon.com], by James Womack. Lean, Total Quality Management, Six Sigma, and Agile all owe substantial debts to Toyota, and this book describes it nicely.
    • Is this a derivative of the methodologies behind Lean Six Sigma?

      No, it's based on the ideas behind lean manufacturing like the Toyota Production System. It kind of parallels the book Lean Thinking which was a followup to The Machine That Changed The World. Both books cover the Toyota Production System.

      It's also not a repackaging of XP. Lean Software Development is based on a set of principles that can be applied whether you are doing XP, Waterfall, Scrum, RUP or whatever.

  • Bees Knees? (Score:3, Funny)

    by Shadow Wrought ( 586631 ) <.moc.liamg. .ta. .thguorw.wodahs.> on Wednesday August 31, 2005 @02:29PM (#13448161) Homepage Journal
    Banana oil, I say!
  • but don't like the Slashdot whore-link: clickey [barnesandnoble.com]

  • Just went thru this (Score:4, Insightful)

    by bobalu ( 1921 ) on Wednesday August 31, 2005 @02:34PM (#13448182)
    We just went through this with a new project. One of the usual suspects started putting out huge emails with a hundred questions/requirements/concerns such that you'd need to solve desktop fusion before protyping the thing and the lead architect just basically slapped him and said no, I'm not even going to answer this - let's keep it informal, get it going first and see what we can do and what makes sense. Probably saved the company $100k that day.

    Doesn't work for everything, but when it does, use it.

    • Re:Just went thru this (Score:4, Interesting)

      by RingDev ( 879105 ) on Wednesday August 31, 2005 @03:29PM (#13448619) Homepage Journal
      And will cost $500k in the long run. Those questions, concerns, requirements, etc should have all been recorded. The future user who just got smacked down for expressing his/her concerns will likely develop a less then positive view of the IT department, and be significantly less likely to partake in future design meetings where those requirements and concerns will become much more imporant.

      I have been dragged through numerous develop now, design later! projects, and each one of them has gone over schedule. I'm still trying to clean up this current project that I got hired into. The users were still bringing us new requirements for the invoicing system 2 months after it went live. Not to mention the actual framework that the app was built off of was a hodge podge of misc code. Finally we are getting things standardized and working on a solidified portal and framework system. Poor planing, a complete lack of requirements gathering, a complete absence of a clear unified design, and many other poor initial lead and management decisions have us still working on corrective maintenance for an app that was released six months ago. All for the sake of developing and releasing the first version in 4 months. No thanks, I'd take 4 months of design and huge emails up front in exchange of 8 months corrective maintenance any day.

      -Rick
      • Not sure documenting early will save much ... In the project I'm working for the moment, there has been about 200 pages of docs before we had a single line of code. Every aspect they were thinking is there. But guess what ... after 3 months of developpement, only about 10% of that docs is still valid.
        One of the issue is to know when to document and when to keep it an informal discussion. An out of sync documentation is probably worse than no docs.
        And as all things, the best aproach depends of the project. I
        • True enough, I had one of those 200 page documentor bosses before. And it didn't help any. Primarily becuase it was too much information in no useful layout.

          This project, we have some useful information in a well formated layout. It's wonderful when I can open a folder and goto the specific module I'm working on, see the original requirements, notes, and update requirements, sample output, etc. Unfortunatly, not all of the folders are full or accurate. But if we had that documentation in place when we st
      • I have been dragged through numerous develop now, design later! projects, and each one of them has gone over schedule. [...] No thanks, I'd take 4 months of design and huge emails up front in exchange of 8 months corrective maintenance any day.

        If that's how your agile attempts are going, you're doing it wrong. In particular, I suspect you're not writing unit tests and acceptance tests, you're not devoting sufficient time to refactoring, and I'd bet that the person making feature choices is not in the roo
        • I've come to the belief that software is developed, goes through a repeated cycle of use and enhancement, and is then finally abandoned. But it is never "done".

        • Re:Just went thru this (Score:5, Insightful)

          by fupeg ( 653970 ) on Wednesday August 31, 2005 @05:37PM (#13449630)
          You guys are both wrong. It's not the method that matters, it's the people. Good software engineering is the key in either system, and neither system is perfect for all situations.

          The key to agile programming is being able to actually handle massive requirement changes. I'm talking about the kind of requirement changes where all of those precious unit tests and acceptance tests you wrote get invalidated overnight. If your requirement changes are more minimal, then they're not going to be a problem with either method. They key to being able to handle massive requirements changes is good software design. Excessive coupling between components means that when one component becomes worthless (because of said changes) its hard to salvage other components that are still valuable because they are too tied to the deprecated component. Without good software design, agile programming won't help in the worst case scenario. This is especially important for agile programming, because its approach increases the likelihood of the worst case scenario.

          Now I will say that a waterfall approach leads to several bad practices. First, it leads to a mythical man-month type of fallacy. Management tends to think that because of all the documentation present that they can manipulate "resources" like pawns in a game of chess. Second, it encourages bad design because you think you know everything. Third, and this is the worst to me, it gives false value to low value assets, i.e. people who don't actually produce anything. When a company values its process more than its employees, then it winds up hiring lots of people whose only function is to manage the process. Of course this is not unique to waterfall companies, but their emphasis on process does encourage this.

          Agile programming also encourages several bad things. It encourages the over-valuing of development and under-valuing of design. I've often seen programmers with the attitude that's ok to build something that sucks because they will make it better in the future. Second, it tends to encourage overly-conservative programming. Its faster cycles discourages tasks that don't easily fit into these shorter cycles.

          Of course the biggest limitation of agile programming comes from its roots. It clearly shows its consulting roots with its need for customer involvement. The kind of customer involvement it wants is very expensive for the customer (if we're talking enterprise software, maybe it's cheaper for consumer software.) If the customer is already paying you to build the software, then they might be willing to make this investment. If instead the customer is only a potential customer who might buy the software when it's done, then they are much less likely to make such a large investment.
          • Nice write up! I agree with you completely, there are situations where short deployment cycles and rapid turn over work well. but it is very situation dependant. I also agree the proper design is the fundamental requirement of either Lean/Extreme, rapid, or standard development. We can expect processes to change, to need refinement, and to be outright abandoned and recreated. A solid modular framework can help that a LOT. If you have the time and money to sink into developing a solid vehicle for your custom
      • I do understand your point, but in this case the individual I mentioned (who IS in the IT dept.) does nothing but obstruct, and his method is bureauocracy (sp?) in the extreme. Trust me, nothing but termination will keep him from grandstanding in meetings and bringing up superfluous problems, so this is not a worry.

        We're re-engineering a process, throwing stuff out and discovering what's do-able and what's not. The concerns and issues involved are real, but many are simply what I'd call "dragging the walrus
      • The arguments that you make against agile software development are actually dealt with in a quick "myths about agile software development" in the start of this book. This argument, and many other made against agile, are classic straw men -- you are attacking a weaker argument, never made by proponents of lean or agile software development.

        The example you give is a POORLY managed project, and would have failed no matter what methodology was used. Someone might have been using "agile" or "lean" as an excuse t
        • I never said I was against agile software development. I am against shunting users/customers. Expecially ones that have enough at stake with the software to come up with a list of requirements and concerns.

          And the problems I have run into have almost entirely been due to poor management. Not due to one style of development or another, just poor management in general, or in specific situation that have consistantly caused delays. There are the occasional technical issues, but where a bad technical decisio
          • My apologies, it looks like I didn't read far enough up the thread to understand the context properly.

            I very much agree that shunting off user requirements can be costly. It might make initial project development cheaper, but it makes the product worth less. One of the things I like about iterative development, is that it provides a clear approach to handling late breaking user requirements. One of the things that I like about good old waterfall, is that you invest enough time in planning to be able to crea

  • This book's been out since May, 2003, but it's well worth picking up. The concepts within are absolutely applicable now, and will continue to be for quite a few years.

    Is it just me, or are things changing too fast when a development process has a shelf life of less than two years?

    If you want to feel your head really spinning, pick up a copy of The Mythical-Man Month. Things don't actually change that much.

    • Re:The Winds of Change (Score:5, Insightful)

      by TrappedByMyself ( 861094 ) on Wednesday August 31, 2005 @03:14PM (#13448501)
      It's not so much that development processes are coming and going, it's just that people are tailoring the processes around what works.

      I've been seeing this agile stuff for almost 8 years, and that doesn't mean it wasn't around before that.

      So, gather around boys and girls, here is how you write software (does not apply to stuff like mission critical embedded software)

      1. Ask customer what they want
      2. Build something
      3. Show it to customer, and ask what they want changed

      If you make that cycle short, have good engineers, reasonable customers, and competent management, you will rule the universe.

      What happens is that projects often have stupid and/or lazy people involved, so there are tons of failed projects. So, awhile back, the academics get together and come up with this deal where you do this extravagent design/requirements process upfront. TEH SAVIOR!!! ...managers rejoice...projects continue to fail...however, the projects with good people continue to prosper. So, what is wrong? oh, we need agile, iterative, incremental, eXtreme, [insert buzzword here] processes. TEH SAVIOR!!!...managers rejoice...projects continue to fail...however, the projects with good people continue to prosper. Things are a little better though, because the processes are closer to how good people do things.
    • shouldn't be telling a dev team the time of day let alone what path to follow to build "Hello World". There's nothing fundamental in Lean, XP, or Scrum that Brooks didn't manage to say 30 years ago(yes. 30. 3-0. Thirty. Near 1/3 of a decade. check the copyright). It's not that things are changing too fast, it's a matter of ajusting your process and your understanding of building software. One great example of this is comparing the origional XP book to the 2nd edition. Kent corrected himself and altere
      • There's nothing fundamental in Lean, XP, or Scrum that Brooks didn't manage to say 30 years ago(yes. 30. 3-0. Thirty. Near 1/3 of a decade. check the copyright).

        I don't think that's entirely true. Test-driven development, for example, seems pretty new. Hardware cost had to be pretty low before each developer could compile and run all the project tests every few minutes of development. I also don't remember Brooks talking about weekly iterations.

        That's not to knock "The Mythical Man Month", by the way. I com
        • Hardware cost had to be pretty low before each developer could compile and run all the project tests every few minutes of development. I also don't remember Brooks talking about weekly iterations.

          Good points. In terms of practices you're quite right, and there's a lot about the how things get done today that couldn't be done 30 years ago. The values and the emphasis on people as a fundamental point of building software still remains. I'm of the opinion that Brook's "surgical team" can be realized in pa

      • I think you mean near 1/3 of century.

  • "This book isn't for closed-minded folks who think the waterfall method and a preponderance of documentation and process control are the bee's knees."

  • It's About Time (Score:3, Informative)

    by MikeyTheK ( 873329 ) on Wednesday August 31, 2005 @03:18PM (#13448533)
    One of the least considered, studied, and written about things is project methedology. It seems like all the books about the subject relate to automotive production, where the Japanese flooded the market with their philosophy. Afterward, automotive companies hoisted these philosophies on unsuspecting suppliers. The number of paradigm shifts that auto suppliers have endured as a result over the last 20 years is amazing.

    Yet I have never had a large client try to push a project development methedology for software on us. There has never been discussion of any of these, and it seemed that for the most part, we as a group were on our own when it came to evaluating various options.

    I've been waiting for someone to start talking about the various paradigms and structuring philosophies for a while. For projects as complicated as large software systems, it is frequently a lot of trial and error, followed by more of the same. Finding any comprehensive discussion has been impossible. Hopefully this will foster more books on the topic. Software is becomming such a critical part of corporations, government, and daily life, that not only are the tools that we use important, but so is the way that we use them.

    I would also be interested in seeing some sort of discussion as to how various team-structuring philosopies fit with various classes of development tools. For example, database development lends itself to a different approach than web design, simply because of the design process, hurdles that have to be dealt with, degree of expertise, and expense of the individuals that participate in the project.

    • Re:It's About Time (Score:2, Interesting)

      by mseabury ( 93903 )
      I work for a 3 year old software startup. We have just been audited 3 times by customers or portential
      customers for our product.

      Even though they haven't pushed their software design process onto us, they have all made it clear that there must be processes to trace the requirements through developement, testing and releasing of our software.

  • CMMI and its use(ful/less)ness (Score:5, Informative)

    by xenomouse ( 904937 ) on Wednesday August 31, 2005 @03:23PM (#13448568)
    The review mentioned CMMI, so i figured i could share my personal knowledge of it to give others at least a basic feel for it. A few years back i worked for a defense contractor at a military base. Don't get worked up: we were glorified librarians, only occasionally writing internal apps to make lights blink, pocket strings loosen, and other such things occur. Our group (being the smallest one on the base), got the crappiest contracts. One of them was to ensure that all software development done on the base was CMMI level 3 compliant. I was one of the "lucky" ones sent to the CMMI classes to be indoctrinated. CMMI has a number of levels, starting at level 1 (very little bureaucracy, minimal documentation, and barely organized) and going level 5 (an amount of bureaucracy that would put Brazil ["Mistakes? We don't make mistakes."] to shame). Working at level 3 is right in the middle of the spectrum, with just a bit too much bureaucracy for my tastes (when you need to generate a paper trail just to write a simple function, it's a tad too much). There was a rumor going around that there was one (maybe two) companies that qualified as CMMI level 5, and they were believed to be in india (where the cost of maintaining such a level would not be prohibitive to sustain). Of course, that may have changed [google.com] in the past few years.

    Now comes the question... why would anyone want such a level of bureaucracy? Well, in our case, we were responsible to the government, and from what i can tell, the government equates "paper trail" with "accountability and transparency." In other cases (commercial software), this would allow a company to switch contractors if the current contractor started acting nutsy or broke a contract in some way.

    Think of the group paying for the contract as "the boss" and two contract groups called "Bob" and "Tim." The boss wants to pay someone to develop the MegaApp for him. Bob and Tim both make promises about how fast they can develop the MegaApp and how much it will cost and how much quality the MegaApp will contain after they work their respective voodoos. Bob makes some egregious claims, and the boss (because he's a manager) believes Bob and passes over Tim's more realistic promises. Bob, of course, fails to deliver on his promises, but the boss saw that some of what Bob did met some of the requirements. Since the boss made sure that Bob and Tim implemented CMMI level 3 before they could even be considered for contract, he has the option (or believes he has the option) to take the deliverables (including CMMI documents) to Tim. Tim, who is accustomed to using CMMI level 3, should theoretically be able to pick up the project in a short period of time and run with it due to the high level of documentation.

    Just like communism, it can sound good in theory and look good on paper but will probably only work well in a perfect world.

    Note: Carnegie Mellon developed CMMI [cmu.edu].

    Disclaimers:
    • The CMMI classes i attended were by no means comprehensive.
    • CMMI has been updated since i took the classes.
    • There are several CMMI models, each with their own purpose.
    • I am naturally predisposed against CMMI.

    • Re:CMMI and its use(ful/less)ness (Score:2, Informative)

      by Anonymous Coward
      You're missing the whole point of the Capability Maturity Model when you state this:

      "Working at level 3 is right in the middle of the spectrum, with just a bit too much bureaucracy for my tastes (when you need to generate a paper trail just to write a simple function, it's a tad too much)."

      Even though you may understand your function as it is written now, when you look back at your code or someone else does in the future, having the documentation of what the function does along with when and why it was crea
      • FWIW, you are all confusing the CMM and the CMMI.

                  E
      • Even though you may understand your function as it is written now, when you look back at your code or someone else does in the future, having the documentation of what the function does along with when and why it was created is important.

        There are better ways to achieve that than documentation
        • If I want to know what a function does, I should be able to tell by its name and a quick look at the code. If not, some refactoring is in order. Failing that, the unit tests should tell me all I need to know.
        • If I want

    • space shuttle software is CMM Level 5 (Score:5, Informative)

      by MarkEst1973 ( 769601 ) on Wednesday August 31, 2005 @06:02PM (#13449801)
      They write the right stuff [fastcompany.com]

      The software in the space shuttle cannot fail. billions of dollars and people's lives are on the line, so it cannot fail.

      At CMM level 5, you don't fix the bug when you find it. You fix the process that let the bug happen in the first place.

      CMM Level 1 is no process. anything goes, really.

      CMM Level 2 is fixing the bug and documenting that you found it. That more or less boils down to using a bug tracking system, keeping good version control, and everyone following this process.

      CMM Level 3 is the software engineering level. that basically means that everyone in your organization builds their software similarly (software design and documented use of design patterns is good here).

      Levels 4 and 5 is all about keeping a database of your processes and fixing your processes. Process flaws cause bugs, not code errors. You don't fix your code, you fix your process.

      It's important to note the budget for the team writing the space shuttle code. Lots and lots of money and lots and lots of time go into that software. Ordinary application writers like us don't get that luxury.

    • I know these Indian CCM Level 5 organisations. They are affiliated with Philips. From a point of practicality, they are not level 5, but they do know how to cook the books.

    • There was a rumor going around that there was one (maybe two) companies that qualified as CMMI level 5.

      Or more.

      The thing about CMMI is that the certifications are based on sample projects (or at level 3 and higher) samples from a whole company. It also depends on the integrity of the company and the auditing group (usually an external contract firm, though not always).

      If your sample is crap, and you have documented it, you can get whatever level CMMI certification you want...while the rest of the bus

  • There's also a note for folks working in safety-related fields where regulations and immense processes dictate how to do work: Shortening cycles in such environments can better ensure people aren't killed by software failure.

    Agile development methodologies are iterative. This generally means that a partial solution gets implemented now with a more complete and more correct implementation in the next iteration(s). That a defect in something like the air traffic control system or a nuclear power plant's c

    • Agile development methodologies are iterative. This generally means that a partial solution gets implemented now with a more complete and more correct implementation in the next iteration(s).

      No, agile doesn't mean implement a partial solution with potential errors. The book certainly doesn't state or even imply anything remotely like what you've tossed out. (Nor did my review.)

      The book says "Generally, a process that encourages safety evaluations periodically throughout development will be superior to

    • Lean product development is about iteration, and it's how Toyota & Lexus designs its cars, noted as the most reliable in the world. Why can't these techniques also apply to software, which is arguably even easier to change iteratively than car part designs?

  • Saw a presentation of this is Redmond (Score:3, Interesting)

    by bADlOGIN ( 133391 ) on Wednesday August 31, 2005 @03:33PM (#13448660) Homepage
    At the borg HQ even. Lean basicly packages agile concepts into a business-tasty format. There's nothing in Lean that contradicts with XP or Scrum (in fact, it tends to amplify it). The fact that these practices come from proven manufacturing and distribution practices give the concepts more credit . If you're having trouble "selling" either XP or Scrum, take a look at this. It should sell itself.

  • Agile is not for commercial software development! (Score:2, Interesting)

    by Anonymous Coward
    We had Jim Highsmith, Mr. Agile Manifesto, talk to our engineering team. What a waste of money.

    If you believe Agile works, you probably also believe Google can be implemented with JEEE and Oracle.

    These Agile guys really don't know what it takes to release large commercial products with million lines code, with many dependencies, many languages, requiring marketing campaigns, press tours, support training, etc.

    More versions cost more money.

    Sure Agile might work for small internal IT projects where you have

    • Re:Agile is not for commercial software developmen (Score:5, Insightful)

      by dubl-u ( 51156 ) * <<ot.atop> <ta> <2107893252>> on Wednesday August 31, 2005 @04:41PM (#13449220)
      If you believe Agile works, you probably also believe Google can be implemented with JEEE and Oracle.

      That's boldly, if unintentionally, ironic. Not only is Google hiring all the Agile developers they can find, but many agilistas have a lot of contempt for the ultra-heavyweight EJB-style approach to things.

      These Agile guys really don't know what it takes to release large commercial products with million lines code, with many dependencies, many languages, requiring marketing campaigns, press tours, support training, etc.

      There's no question that complicated projects have to be done differently than simple projects. But even there, you can place approaches along an agile/non-agile spectrum. You also shouldn't mistake "I don't know how" for "it's impossible".

      Becoming agile also requires a fair bit of supporting infrastructure. For example, my Extreme-Programming-built code bases typically have a 1:1 production-to-test-code ratio. Bug rates for many XP projects are well under one per developer-month. Quality at that level enables fantastic agility in ways that seem impossible at typical quality levels. If you regularly have production relases with zero bugs found, weekly releases don't seem nearly as scary.
      • The Agile environment pays for itself many times over when you work in a world where each check-in kicks off compile, package, db create/destroy, 3k+ unit tests, appserver deploy and launch, and 2k+ functional/acceptance tests that culminate in auto deployment to stage on success. It pays again when at the end of each 1 week itteration you do a load test and deploy consistently to live. You feel great. "Of course we deployed to live. It's Wednesday."

        The strange part, is that when you've worked like this
    • But the 99.9 % of projects ARE'NT so big as google. Please, don't force us to work as any software project is a rocket-science endeavour.
    • And Toyota is slowly driving their competitors into the ground. I'd take another look. There's a lot more to Agile than the surface-level debates, especially if you look at it in the context of Lean product development techniques.

    • ... several large financial firms I can't mention, the department of defense, most of modern manufacturing, 3M, etc.

      More versions isn't what Agile/Lean means. It means more iterations. You make versions (or releases) when you're ready to go to market. That's a business decision. You will certainly have many iterations before your business feels you've built enough to go to market. The technical job is to make sure that, to the extent you've gotten to high-priority scope, the quality of the code is such
  • Imagine having time enough to read all these methodology books? But, if that were the case, I'd probably waste it snowboarding or something...
  • But will it enable customer driven, lean, agile XML based go-to market paradigms and rapid value driven innovation? That's the question.
  • I admit, I haven't read the book, but from my understanding of Agile methods and CMM, the two are not mutually exclusive. CMM is about improving and maturing the processes that you use. A company at CMM 1 has virtually no process, and can't repeat their results. But agile methods such as XP are processes, and often have even more effort put into improving them than more traditional methods such as the waterfall model. One common misconception about CMM is that it's about creating a whole lot of unnecess
  • ... is available on the iTunes store podcast section. Search for "Agile". Otherwise, you can get it here [libsyn.com].
  • Lean Thinking & The Toyota Product / Product Development system goes beyond software development; it's a major shift in the way people think about product development and operations. Agile methods are quite related to Lean, and this was one of the first books (along wtih David Anderson's "Agile Management" to articulate the relationship).

    I just hope more rigour and discipline can be instilled to get past the bullshit surface-level debates (how much documentation, XP = hacking?, pair programming is/isn
    • I saw the Lean Software development presentation given by Mary last week. The best part was when she referenced the interviews done for the book "The Polaris System Development" by Harvey M. Sapolsky (Harvard University press, 1972) citing that the PERT charts were found to be useless in actual project managment and were just hacked up to keep congress happy so that the teams could get things done.

      I shudder to think of the job I worked 5 years ago. They bought huge HP plotters to print out the MS Projec

    • This is also what I think about software development. There should not be software project leaders, it should be up to the architects and the engineers to coordinate efforts toward a common goal.

  • The book talks specifically about how Six Sigma, Capability Maturity Model (CMM), Capability Maturity Model Integration (CMMI), and Project Management Institute (PMI) certification can drag down development productivity and quality

    The moment a book claiming to be about software engineering trashes management processes like this, you know to call BS. It never ceases to amaze me how pretentious code-monkeys believe their immature approach to development is somehow hamstrung by proven management techniques

  • Don't put easter eggs like Hot Coffee in.
  • Had a great ime reading on how to worj with this program. Enjoyed the read thought it was very well written.

Slashdot Top Deals

No spitting on the Bus! Thank you, The Mgt.

Close