Please create an account to participate in the Slashdot moderation system

 


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

Organizational Patterns of Agile Software Development 128

Posted by timothy from the swooping-about dept.
Paul S. R. Chisholm writes "What makes a software development project succeed? It's not language or tools or process. It's not a simple as people; even great programmers sometimes find themselves associated with disasters. In some sense, a successful project is the same thing as a successful organization; but what makes those? We need an anti-Dilbert. In Organizational Patterns of Agile Software Development, James O. Coplien and Neil B. Harrison lay out the results of their research on the subject; what they found, helps." Chisholm also offers this disclaimer: "Full disclosure: I was a member of one of the organizations studied, and I contributed to one of the patterns in the book. I know both the authors; one is a long-time friend and mentor. This review reflects my opinion of the book, not of the authors. I paid for my copy of the book." Read on for the rest.
Organizational Patterns of Agile Software Development
author Coplien, Harrison
pages 419
publisher Prentice Hall
rating 9
reviewer Paul S. R. Chisholm
ISBN 0131467409
summary Practical and theoretical ends meet in this opinionated but open-minded approach to implementing agile software projects, including very large-scale ones.

Organizational Patterns of Agile Software Development starts by describing the foundations of the authors' research. There are definitions of a "pattern" (but "your intuition about the meaning of the term will take you far") and of a "pattern language" (read the book), the history of their research, and some information about how the book is laid out. The authors recommend you read this section, and so do I; but if it's too dry for you, by all means move on.

The meat of this book is four pattern languages: how to manage a project, how to grow it over time, what can make up an organization's "style" (I'd use the word "culture"), and how the people fulfill their roles and interact with each other. These are not prescriptions or algorithms; they're elements of how successful organizations have worked.

Each pattern describes one aspect of some effective software development organizations. Some patterns are found in more than one pattern language; "Community of Trust" is common to all. Others are less general; "Moderate Truck Number" applies only to the "piecemeal growth" pattern language.

How valuable are the patterns? Some (such as "Get On With It", proceeding with an effort before the planning is considered complete) are common sense. Others (for example, "Don't Interrupt an Interrupt") are things you probably know, but might need to be reminded of ... or might need to remind your boss of. More than a few (my favorite is "Architect Also Implements") might help you understand how something could or should work. Finally, there are some patterns here (such as the "Day Care" pattern for training new members) that might be new to you.

The rest of the book puts the patterns and pattern languages into perspective. There are chapters on organizational principals and (seriously) anthropological foundations of this work. Then there are two case studies of very successful projects. On one, "[about one] million lines of code were written over a period of 31 months by about eight people (that's about 1,000 lines of code per person per week) -- that doesn't include code in the [two] prototypes." It's easy to crank out code at that rate for small bursts, or on small projects. To stay at that pace constantly for over two and half years is nothing short of astounding. The resulting product was released to great reviews. (It then did poorly in the marketplace when it went head-to-head with a directly competing product from Microsoft. Sound dissatisfying? Consider how very long people waited impatiently for Mozilla and its successors such as Firefox. More directly, look at Robert Glass's assertion of the "disconnect between managers and their programmers" as to what projects are seen as successful; it's Fact 13 in Glass's book reviewed August 30th on Slashdot.)

What's imperfect about this book? A couple of things.

First, sometimes the language gets too academic for easy reading. Example: "We have also seen a lighter though almost equally destructive form of this phenomenon, which we describe as schismogenesis.... Symmetrical schismogenesis occurs when two factions each rise in power (or in fear or distrust of each other) and form cliques or splinter groups that tend to focus inward rather than resolve issues in the dialogue with each other." Clear enough if you work on it, but a little intimidating.

Second, the book is surprisingly partisan on some subjects. The book is not kind either to ISO 9000 or Extreme Programming; it could serve as a sort of litmus test, delighting critics and coming across to supporters as unfairly harsh.

What's good about this book? It's a collection of good information, well presented, with information on how to apply it, on a topic where not much knowledge has been accumulated. For some specific circumstances, this book sometimes points out different likely alternatives, with information on when each is applicable. Don't expect Organizational Patterns for the Complete Dummy; then again, don't expect anything useful to be superficial.

How could Coplien and Harrison's work apply to open source development? For starters, they point out the value of people working physically together, and of individual code ownership; these aren't easily applied to open source, but at least it points out forces that need to be resolved somehow. On the other hand, some patterns here are hugely relevant to open source: "Work Queue," "Informal Labor Plan," "Self-Selecting Team," and "Team Pride" come to mind.

Organizational Patterns of Agile Software Development is no panacea. If your organizational practices are the opposite of what's found to be effective, you may find this book frustrating. A book can't take your organization where it needs to go; but Coplien and Harrison have put up some road signs.

You can purchase Organizational Patterns of Agile Software Development 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.

Organizational Patterns of Agile Software Development More

Organizational Patterns of Agile Software Development

Comments Filter:
  • ...about patterns and architecture and such - On the Nature of 'The Nature of Order' [bell-labs.com].

    It's a fairly short paper and can give you an idea of his style - or at least his style as it was 7 years ago.
  • Simple. l33t haxorr sk311z.

  • Great idea for a book. (Score:5, Interesting)

    by mr_luc ( 413048 ) on Monday October 18, 2004 @04:15PM (#10559438)
    Those blessed to work in a programming environment with only one or two other coders always enjoy a productivity advantage over our friends in much larger teams.

    I honestly think that most of these patterns could be synthesized simply by looking at things that good small teams do. Each of the patterns described seems like a no-brainer that we've likely had some experience with -- but the same harsh criticisms have been levelled by less-than-Humble Programmers against the GoF's Design Patterns: they're window dressing, they're an attempt to claim intellectual real estate that everyone with a brain already uses . .

    The critic would be well-served to read The Humble Programmer again; I mean, it's ridiculous that it has taken the time it did for the notion of Design Patterns to come about when Djikstra specifially described the concept in '76.

    This book, and it's potential benefits, should be looked at from the same viewpoint that intellectually honest people looked at Design Patterns.

    Unfortunately, many bright (but not bright) programmers saw Design Patterns as an attempt to undercut their own intellectual conquests, an attempt to lend mass production to the concepts that they had discovered for themselves, inch by inch. It takes considerable humility and intellectual honesty to benefit from DP's -- programmers are probably one of the lines of work where those two qualities are so strongly stressed (Code Complete, etc).

    I would probably buy this book when and if I went independent (likely not within the next five years), but I don't hold out a lot of hope for it for the simple reason that it seems to also require intellectual honesty, and humility.

    In MANAGEMENT!
    • That's what I meant when I said "I don't hold out a lot of hope for it".

      Rigorous, unflinching, honest examination of one's thought processes and motivations and examination of one's ideas -- in the manner of a good programmer -- seems as though it would get in the way of most "effective management". ;)

    • Re:Great idea for a book. (Score:1, Insightful)

      by Anonymous Coward
      but I don't hold out a lot of hope for it for the simple reason that it seems to also require intellectual honesty, and humility.

      In MANAGEMENT!

      I've said it before, and I'll say it again. You folks sorely need a book, or better yet a core college course, telling IT pros how to work with the management. Not how to jump up and down and cry "PHB: you must work the way I want you to," but how to think "OK PHB: for every loop you throw me, I have a way to get around it." Think of the PHB as yet another proble
      • You are exactly right. All too often, we developers are guilty of failing to see the requirements of the customer (the guy who pays the bills) because we are so focused on the best way to code the project. Sure, some bosses and salesmen are clueless and make moronic requests, but if we can't see things from the business side, we're no better than they are. Good code will only get you so far; if you want to make money from it, there has to be a good business plan too.

      • Let's not be naïve, Mister Coward! (Score:5, Insightful)

        by mr_luc ( 413048 ) on Monday October 18, 2004 @06:17PM (#10560344)
        Let's not be naïve; obviously, successful programmers -- as is stressed in one of the books I quoted as a reference, Code Complete -- always need to know how to work with others and have a realistic, comprehensive understanding of how the needs of management, and the requirements of the project, work together.

        However, it's naive to think that the team of good coders -- and by now it should be obvious that I'm not using a narrow-minded 'creative hacker' definition; I mean good programmers, good architects, good with people, good communicators -- is really better off, in terms of potential, when they have a manager -- even one running interference -- than in an ideal situation where each programmer can know the point of view of the customer, can sit down with the customer and get inside their head and their business and bend their minds to the problem of delivering software that lets their customer take over the world on the one hand, and works within the budget of and accomplishes the goals of their company.

        Manifestly, an ideal situation is one where the programmers know the needs of their company -- because they know its state, possibly have some ownership. Where they know the needs of their customer -- really know them inside and out. There is a reason that some of the most successful stories when it comes to programming are those involving companies and teams of very small size. Viaweb (Paul Graham) is an example of an agile product; features were often rolled out within a day of introduction by a competitor.

        In the less-than-ideal world that many (but not all :)) of us live in, management is a necessary shield from inefficiencies of a beaurocracy, and more importantly, is possibly the only way that programmers can get their information about the requirements of the system. The burden is laid upon the manager of really communicating effectively, of communicating requirements, of clearly expressing the company's needs and position on a project, of ensuring that programmers have the correct context available with which to successfully approach a problem.

        That is a huge burden. And the fact is that most managers of IT professionals do not know how to manage the special case of programmers. The fact that the programmers often have to prod their management, gouge them for any sliver of information that could lead to an actual understanding of the real requirements and goals behind a project -- this fact is not a proof that coders need to know how to "work with" management.

        Programmers will often go above and beyond the call of duty to solve the problems of the organization in a very real way -- often, as we have seen in the cases of small, successful, programmer-driven companies, in a real enough way to rocket a company from obscurity. A Manager is not going to do that.

        He can, however, try to present a more ideal environment for his problem-solvers to solve problems effectively within. He can communicate ceaselessly, so that he's not excluding what could be data that is crucial to a complete or correct understanding of a problem. He can educate himself by reading the last few chapters of books like Code Complete and Rapid Development (these I picked just because they're on my desk right now; there are plenty others. The Pragmatic Programmer is solid, and there are a good dozen or so more that should be requird reading, including some of Joe Celko's later articles in Intelligent Enterprise, like "The Logic of Failure"). A Manager will likely be surprised -- if he has good coders, he will find that many of them have read all of those books already, and he will be amazed at the amount of practical knowledge they have about the realities of scheduling and organizing software projects. Rapid Development alone . . .

        Realistically, most programmers with that kind of an understanding of the issues involved -- and, of course, knowledge of the appropriate principles of abstraction -- will probably ha

    • Re:Great idea for a book. (Score:5, Insightful)

      by killjoe ( 766577 ) on Monday October 18, 2004 @05:52PM (#10560192)
      At the core being a better programmer has to begin by being a better human being. The same with being a better manager, CIO, architect or a plumber.

      The problem is that there are all kinds of Gurus and books out there which claim to make somebody a better "whatever" without ever once touching on what makes a better human being in the first place.

      What makes a better human being? Well the lessons are not new and have been written down thousands of years ago.

      Be less selfish, be more humble, help others, be kind, share more, take care of others etc. The golden rule more or less.

      Large companies instead of sending their staff to certification classes or management seminars should send their employees to become better human beings. This may mean yoga classes, budhist seminars, philosophy classes or something.

      • Mod that ^^^ up! (Score:3, Insightful)

        by mr_luc ( 413048 )
        I couldn't agree more.

        At its core, that is the problem.

        And actually, coders have been marginalized for a long time -- I don't think that many non-programmers realize that the amount of time that a programmer spends thinking about his work, and actively working on the problems related to it, is easily on par with that of other creative problem-solvers -- architects, mathematicians, engineers everywhere.

        However -- and this is something that almost NOBODY outside of programming/mathematics/compsci realizes

        • Re:Mod that ^^^ up! (Score:3, Insightful)

          by DrMaurer ( 64120 )

          So -- and stop and think about the implications of this -- programming may be one of the few job categories on the planet where regular, continual, honest self-evaluation and training and personal improvement are a job requirement.

          Which is true, if you're only willing to stay in the same place (in your non-coding job). Honest self-improvement, training, and personal improvement are a requirement EVERYWHERE if you want to go ANYWHERE in life/buisness/etc. If you don't care, well, that's your call. My

        • Most labouring jobs have a saftey rule, "daydream and you die"! From using design patterns to wheeling a barrow full of wet cement across a bouncing plank, EVERY job is an art. You might want to self-evaluate some of that arrogance before making bold statements (pun intended) like... "programming may be one of the few job categories on the planet, blah, blah,...". Oh, and the "once and for all" thing, I recommend you watch what happens to the new furniture in "Fight Club".

  • You know after taking software engineering.. (Score:5, Interesting)

    by js3 ( 319268 ) on Monday October 18, 2004 @04:18PM (#10559459)
    after taking software engineering, it seems everyone feels the need to write a book about the best way to develop software. What about all the other previous ways? They aren't valid anymore? were they ever valid in the first place? is this *new* way to develop software more valid than the rest?
    • Your answers:
      They were fine.
      No.
      Yes.
      No.
    • The phrase should be "after doing software development". Practitioners such as Coplien are helping to form the rather primitive industry we call Information technology.

      Twenty odd years of doing the right and wrong things, often repeating those wrong things, leads me to respect any kind of insight that can be brought to bear. I reckon that another twenty years should take us to where the automobile industry was in the 50s.

      Mal-organisation is a big headache in our IT group. There is no magic-bullet but lear

      • "I reckon that another twenty years should take us to where the automobile industry was in the 50s."

        Writing software is never going to be like designing and building cars no matter how long you wait. Perhaps what is really holding us back is failing to recognize the unique characteristics of software and falling back on inappropriate methods from other fields. It's not that our industry or methods are primitive, it's that our goals are much more difficult to achieve than rolling out the next gas-gusler.
    • Actually, this is a key question. One thing that is sorely lacking from most of the literature about this kind of stuff (both academic and general audience) is a real attempt to evaluate the methods or "patterns" against alternatives. Systems are developed with little or no reference to other systems and no basis for comparison.

      One of the hallmarks of the scientific method is the need to develop theories that are testable. These theories are then evaluated on the basis of how well their predictions meet

    • Re:You know after taking software engineering.. (Score:5, Insightful)

      by isj ( 453011 ) on Monday October 18, 2004 @04:53PM (#10559718) Homepage
      The previous ways are still valid - but the areas where they are appropriate disappear over time. One example is structured analysis/structured design with DFD, pseudocode, etc., where you go through analysis of current physical system, derive the current logical system, derive the new logical system and finally derive the new physical system. This is still valid in "green field" areas for document processing, but those fields are vanishing.
      Another example is JSP (Jackson Strutured Programming) which is pretty good for traversing non-recursive data structures and transforming them or generating reports. But today you usually have the data in a database and have a nifty GUI report builder; or you use some form of XSLT. So you rarely use JSP today because the areas where it is appropriate are almost gone.

      There also methods that can be used at multiple levels, eg. prototyping, which can be used as a strategy, method, or as a tool. XP has that philosophy at its core, although I fail to see how high-availability is magically implemented by interacting with users.

      The waterfall model is still valid for larger government projects where they in general insist on detailed specifications and signing that contract. Iterative development involving re-analysis a no-no because that requires re-signing the contract.

      One finally interesting area is maintenance. It probably accounts for more than 80% of the development resources, yet I have never seen any formal method/strategy/tool for handling maintenance/change requests/bugfixes. Is this because maintenance is unsexy?

      • Re:You know after taking software engineering.. (Score:4, Interesting)

        by Anonymous Coward on Monday October 18, 2004 @05:16PM (#10559913)
        Maintenance: the best thing is not to think of maintenance as a separate stage of development.

        It's also good not to think of software as ever being "finished". I can't think of any projects (even short perl scripts) that I haven't had to go back and work on, sometimes 2-3 years later.

        Just assume you are constantly going to have to do iterations and act appropriately. At a certain point, the iterations will slow down tremendously but be prepared to dive right back in at any time.

        I.e., first deliver something in 2-3 weeks. Get feedback from the customer. Deliver the next iteration in 2-3 weeks. Get feedback from the customer. Continue until they are happy. After a while they'll come back with a bug report or a feature request. Deliver something new in 2-3 weeks. Get feedback from the customer. .. see how it works? You just pause the project and then come back to it, there is no maintenance stage.

        As for specific tools, I personally use basecamp [basecamphq.com]. It's basically a blog. No "issue tracking" or "tickets" or anything like that. Just a place for your customer and you to discuss stuff. I just create a "bugs" category and tell them to post bug reports there. Then we discuss. Then I create a milestone in 2-3 weeks and deliver the next iteration. It's all about communication.

        This isn't appropriate for open source or "boxed" software, but for one-on-one with a development team and a customer.

        I think the best analogy is that of a garden. First you plant, you do a lot of work, but the work isn't done. You still have to cut weeds, plant new plants, rearrange things every now and then. Rarely do you just destroy the whole thing, and rarely do you ever just leave it alone, it needs care and feeding.

        Same with software projects.
      • One finally interesting area is maintenance. It probably accounts for more than 80% of the development resources, yet I have never seen any formal method/strategy/tool for handling maintenance/change requests/bugfixes. Is this because maintenance is unsexy?

        Extreme Programming qualifies. The way they look at it, after the first iteration is complete you're in maintenance mode. A steady stream of change requests come in, and every week you do the most important week's worth.

        This is a good way to look at th
        • No it does not qualify. In fact, its a horrible idea for maintenance. The goal of maintenance is to fix bugs to an existing codebase. You want to do this with the minimum need to retest, and usually at a minimal of human resources. This means you want to cause the minimal amount of change to the codebase possible. With EP (I refuse to spell extreme starting with an X) you're constantly refactoring and adding new things. With maintenance you don't EVER want to refactor- refactoring has a much higher l

          • Re:You know after taking software engineering.. (Score:4, Interesting)

            by dubl-u ( 51156 ) * <<ot.atop> <ta> <2107893252>> on Tuesday October 19, 2004 @02:40AM (#10562857)
            In fact, its a horrible idea for maintenance. The goal of maintenance is to fix bugs to an existing codebase. You want to do this with the minimum need to retest, and usually at a minimal of human resources.

            Clearly, you don't know much about Extreme Programming. An XP project ends up building two complete test suites. The unit tests are written from the perspective of the developers, and the acceptance tests are written from the traditional QA perspective.

            On my current XP project, the whole test suite gets run every time somebody checks in a code change; any failures and the computer yelps until we fix things. When we do releases we manually poke around a bit, but that's mainly superstition; if we were really afraid that something could be broken without us knowing, that would be a sign we hadn't written very good tests.

            This means you want to cause the minimal amount of change to the codebase possible. [...] With maintenance you don't EVER want to refactor- refactoring has a much higher likelyhood of introducing bugs, requiring more extensive and expensive regression testing. You want to design the change, apply it, and then never touch that part again if possible.

            This is only true if changing things is likely to introduce bugs. If regression testing is automated, it's cheap. And if you have full test suites and do pair programming, you are unlikely to introduce bugs. (At my current shop, we have bug rates well below one per developer/month.) That means that there's no reason not to refactor if the code needs it.

            And there's a big reason to refactor. Your approach of fearfully making localized changes to the code without refactoring means that the broad design gets more and more distorted. Over time, the system gets squirrely enough that nobody really understands it, which increases the cost of change and increases risk. Eventually, your approach leads to the abandonment of the code base and a big fresh start. That's very expensive.

            Extreme Programming, on the other hand, is designed to be sustainable over the long haul. Instead of assuming that the code base will eventually become moribund, XP tries to answer the question, "How can we keep this code good enough to work on forever, no matter how many changes are requested?"
            • "Over time, the system gets squirrely enough that nobody really understands it, which increases the cost of change and increases risk."

              One of the biggest arguments against EP.

              This can only happen when changes are undocumented and there was probably little or shoddy overall design doc in the first place.

              If you have an adequate communication device and keep it updated, you cannot reach a level where "nobody really understands it".
              • One of the biggest arguments against EP.

                Well, you can say it's impossible all you like, but since I've actually done it and had it work very well, I gather you're not trying to convince me. I'll assume that this is your somewhat rancorous way of asking questions.

                This can only happen when changes are undocumented and there was probably little or shoddy overall design doc in the first place.

                Documentation is not a solution to the problem of increased cost of change over time. Why? Three reasons.
                1. Document
            • if we were really afraid that something could be broken without us knowing, that would be a sign we hadn't written very good tests.
              There is the rub. Do you write tests for your tests?
              • There is the rub. Do you write tests for your tests?

                I write tests for test infrastructure, but not the tests themselves. I also sometimes use test coverage analyzers to make sure production code doesn't go untested. I could also write tests for the tests, but I don't for three reasons.

                One is that I do test-driven development, meaning that I see every test go red before I make it pass. Another is that the tests are usually pretty easy to inspect, so I don't need additional confidence to know that they're
          • are you talking from experience? you ignore the use of (automated) unit tests; you ignore the occurence and consequences of code rot. Do you have experience with either?

            • Yes, extensive. I find most bugs aren't found in unit tests. Unit tests are written because you think you might cause problem X, chances are decent you found it in bench testing or avoided it if you knew to be careful. Most bugs are found in ad hoc testing- something breaks under an odd system of options, or occurs 1 out of X times. Unit tests don't find these. Unit tests are the first and least useful step in regression testing, they are not all of it.

              As for code rot- I'll take code rot to the othe
      • It probably accounts for more than 80% of the development resources, yet I have never seen any formal method/strategy/tool for handling maintenance/change requests/bugfixes.

        I read somewhere (sorry, can't find the link) that the Navy budgets X $million to write the code for a missile-control system, and 2X $million to debug the code.

        -kgj
      • It probably accounts for more than 80% of the development resources, yet I have never seen any formal method/strategy/tool for handling maintenance/change requests/bugfixes. Is this because maintenance is unsexy?

        That's where XP comes in, or at least claims to.

        I think you can get most of the benefits of XP just by implementing the Unit Testing aspects of the philosophy; I'm not sure I buy the whole package but Unit Testing really holds up.

        • agile methods (Score:2, Interesting)

          by uberR0ck ( 545216 )
          Regardless of the buzzwords, early prototyping and change management integrated into the base release are the best way to ensure a manageable system/human process in the future. Business gets more value sooner and understands the cycle sooner.

          A lot of maintenance issues come in transition from the base release to later releases. If the typically more senior programmers that start a software product behave (clear code, documentation, training, whatever) so that they or more junior programmers can quickly

      • The previous ways are still valid - but the areas where they are appropriate disappear over time.

        I dissent.

        Those 'old ways' are not 'old methodologies'. Thechnicalities dissapear over time, but experience accumulates.

      • Re:You know after taking software engineering.. (Score:2, Interesting)

        by Anonymous Coward
        A friend of mine pointed out Scrum Teams [dotnetjunkies.com] to me, and it seems to apply well to maintenance. It's not exactly anything new or groundbreaking, and in fact, anyone with a project management background can mix and match PMI terminology with that listed in the description, but it still seems like an effective approach.

        This process uses small teams and a fixed work cycle (usuall 30 days). You have to have a couple "smart people' at the top to make it work well, the 'product manager,' who manages feature and b

    • Indeed, throughout my career I have noticed that projects usually have failed for reasons *other* than the methodology/approach being used.

      This includes such things as executive sponsors having relatively short attention spans, failure of team members to adequately address the needs of their customers, and losing sight of the big picture.

      In fact, the only book I've seen recently that appears to be of some value (particularly for those who work on productized software) is "Beyond Software Architecture" b

      • Indeed, throughout my career I have noticed that projects usually have failed for reasons *other* than the methodology/approach being used.

        This strikes me as a sign that the methodology in question is incomplete.

        That's not to say that a methodology should be completely idiot-proof. But it should be possible for humans to do. It shouldn't solve all their problems, but the methodology should make the problems obvious as soon as possible, and give a good framework for thinking about solving them.

        For me the
  • I know both the authors; one is a long-time friend and mentor.

    Mentor? Where can I get one of them?

    • Re:Mentor? (Score:5, Funny)

      by dilettante ( 91064 ) on Monday October 18, 2004 @04:25PM (#10559508)
      Mentors can be purchased at most grocery and pharmacy stores for around 50 cents. They come in rolls of about 20.

      Mentors, the Freshmaker!

      (I apologize for this, really, it's just been one of those days).

    • Anyone?

      Typically co-workers are the pool for mentors, but it is a pretty sad state of affairs that almost no one either has a mentor or does mentoring in IT. Some people [pragmaticprogramming.com] say we are craftsmen, but still pander to the nomadic programmer.

      A question is: where is the community about programming? Where is the Programming Community?

      Or are we really just a bunch of consumers: Come buy our books, come purchase our training and seminars, come be our employee and sign over all your righ

  • How to make a software project work...for real (Score:5, Funny)

    by Ooblek ( 544753 ) on Monday October 18, 2004 @04:22PM (#10559486)
    1. Pizza. Lots of it, on the company dime.
    2. All the soda you can drink before 5pm.
    3. All the beer you can drink after 5pm.
    4. A dev machine with the best graphics card, raided SATA drives, 3+GHz, and a raw, unrestricted net connection.

    Free food and drink, Half-Life parties after 5pm...what more could any geek want? They'll pump out more code than you're slowbie QA people can handle.

    • Re:How to make a software project work...for real (Score:3, Insightful)

      by Anonymous Coward

      1. Pizza. Lots of it, on the company dime.
      2. All the soda you can drink before 5pm.
      3. All the beer you can drink after 5pm.
      4. A dev machine with the best graphics card, raided SATA drives, 3+GHz, and a raw, unrestricted net connection.

      Sounds like the .com bubble. Something tells me that isn't too great a model to build on

    • Re:How to make a software project work...for real (Score:1, Funny)

      by Anonymous Coward
      You forgot the 12:30 nap and the 2:00 massage... Oh and, for every 10 minutes your mother is late picking you up after 6pm, the company charges $50.
    • why the hell would they do any work? they would have all their needs fullfilled... seriously.. give 'em good pay.. but the party hard _everyday_ just doesn't work too well (especially when you would have free booze every day.. but no way to get the same benefits in pure money, ie. you would be giving them a reason to get drunk).

      besides, a geek would work during night.. allowing some 'strange' behavior works for some.

    • Re:How to make a software project work...for real (Score:5, Insightful)

      by mcmonkey ( 96054 ) on Monday October 18, 2004 @04:49PM (#10559690) Homepage
      They'll pump out more code than [your] slowbie QA people can handle.

      A couple points in defense of QA. First, if the developers were pumping out better code, instead of more code, speed of the QA people would not be an issue. Second, your slowbie QA people aren't really slow.

      What happens is, Z amount of time is scheduled for a project; X development + Y QA. The developers always go over schedule and take X + a time. (I'm not saying it's our fault--PHB, feature-creep, whatever--but it happens.) This leaves QA with Y - a time to do their job.

      Inevitably, especially as a approaches Y, deadline Z is missed and all eyes go to QA since they are the last ones in the chain. As a developer married to a QA person, I get to hear about this stuff all the time. Lucky me =)

    • They'll pump out more code than you're slowbie QA people can handle.

      Hooray! That's what I want: people pumping out code.

      I think you should next take your theory to Boeing; they'll be excited to hear a cheap way to get their workers to rivet more metal onto planes. And I'm sure the customers will be excited when they hear that the cost per pound of their planes will go down a lot.
    • The simple fact is that small groups can accomplish more per given size then large groups because of a more focused involvement on the part of the program. When in large groups, the programmers (and people in general) tend to lose motivation because often they lose sight of how their portion is benefitting the end project. Also, it is easier to manage 3-10 people then it is to manage 100 people, because as the organization grows, it now requires a more complex management hiearchy. The downside: Small gro
      • I think the real productivity factor is that inefficiencies due to communication increase exponentially (loosely) when the number of programmers goes above 1, unless the project lends itself well to isolated modules that can be worked on without needing to understand other modules (and thus communicate with the owners of others modules, try to discern what the hell they are doing in their commentless code). Even computers are less efficient per cpu when multiple cpus are involved, and how much more difficul
    • 1. Happens about once a month. We have an "all hands" meeting, and management provides pizza (wide variety, too) for everyone.

      2. We have a soda machine at work, but the coin and bill acceptors have been disabled, intentionally, by the management. Anytime you want a cold soda, got hit the button and get one. Someone comes out and restocks the machine on a daily basis. I make a pretty heavy dent in the Dew supply. When I was interviewing a possible new hire last week, and pointed out the free soda machi
    • They'll pump out more code than you're(sic) slowbie QA people can handle.
      Good idea...build a cantilevered code base so that when QA finds the bug you made two weeks ago (and they will; you're not perfect), you've already built a bunch of code on top of the bug. Guess you'll have to put the Half Life down for a while as you look for a way to untangle it.
    • "Donuts and the possibility of more donuts to come"

  • NEW from Ahole Press!!! (Score:3, Funny)

    by Anonymous Coward on Monday October 18, 2004 @04:26PM (#10559511)
    It's ...

    The Teach Teach Yourself eXtreme Test-driven Agile Development Patterns in 21 Days By Example Bible.. JAVA EDITION!

    Seriously I believe strongly in Agile methods (even before they got the name "Agile") but please let's not dilute the name "Agile" to the point that I'm embarrased to use it, okay??

    Me: "I think we should stay agile and use this simpler algorithm until we have some real-world benchmarks."

    Coworker: "Okay. ... Hey, what do you mean, Agile? I saw a fluourescent green book on 'Agile Extreme Programming' at Borders, I thought you didn't follow all those stupid fads."

    Me: *grumble*

  • Leadership (Score:3, Interesting)

    by coldtone ( 98189 ) on Monday October 18, 2004 @04:30PM (#10559545)
    Successful software projects have great leaders. Leaders that understand what needs to be built and what doesn't, what can be done and what can't, and who works well on what. Good leaders are accountable, have the respect of there people, and know there shit.

    If you're leading a software project and reading books like these your project is already screwed.

    • Re:Leadership (Score:4, Insightful)

      by Anonymous Coward on Monday October 18, 2004 @04:39PM (#10559613)

      If you're leading a software project and reading books like these your project is already screwed.

      I dunno.

      Good leaders are constantly trying to learn new things.

      Good leaders don't dismiss an idea because it is/isn't associated with a fad, they evaluate the idea on its merit.

      Good leaders know the difference between "there" and "their"
    • Good leaders don't come from nowhere. Maybe one of the better ways to become one would be to read the book. I mean, heck, I'm right out of university - I'm not exactly ready to lead a team of programmers. If I did somehow end up having to do so, I'd be glad to have some help, even if it only got me up to mediocre. :-)

    • Re:Leadership (Score:3, Interesting)

      by _|()|\| ( 159991 )
      If you're leading a software project and reading books like these your project is already screwed.

      In Peopleware, DeMarco and Lister assert that "the average software developer ... doesn't own a single book on the subject of his or her work, and hasn't ever read one." I'd be pretty happy to learn that my manager is reading a computer book, especially one without "24 hours" or "dummies" in the title.

  • An anti-dilbert, yeah right (Score:4, Interesting)

    by ShatteredDream ( 636520 ) on Monday October 18, 2004 @04:44PM (#10559638) Homepage
    From what I've seen, the thing that makes or breaks a leader is whether they want to get the job done or whether they want to get recognition. Those that lead to get the job done, are the ones that tend to be very effective, and those that want to be constantly recognized tend to not be. It's really common sense. When you're secure enough about your own abilities, you don't need to have them constantly reinforced and recognized.

    What I think America needs more of us is a military-influenced leadership culture. Not too heavily influenced, but enough that people understand that when you work in a team, even as the leader, your success and the team's success are one-in-the-same.

    Of course schools often discredit this by having teachers who will grade down an entire team because of a slacker or two's stupidity, whereas in the real world the slackers would get fired for bad performance. I have had a class before in college where I got graded off because another team screwed up and made it impossible for my team to finish our work.

    It seems to me that the best anti-dilbert solution is to instill from an early age the value that if you screw up, you'll be accountable, and that when you succeed that you share your success with those that made it possible.
    • "It seems to me that the best anti-dilbert solution is to instill from an early age the value that if you screw up, you'll be accountable, and that when you succeed that you share your success with those that made it possible."

      This goes against the very core of corporatism. The purpose of forming a corporation is the shirk responsibility in the first place. Nobody who is busy climbing the corporate ladder will share success the idea is to take all the credit, point the finger of blame, and stab everyone in
      • Comment removed based on user account deletion
        • "The corporation limits *civil* liability, but a crime is still a crime,"

          Yes sure in theory. In reality unless you are ripping off 400 billion dollars and are doing it in a very visible way you still get to walk. Kill a few people with a defective product? no problem. Spill a few million gallons of oil and destroy fisheries, families and wildlife? No jail time, miminal fees!. posion a couple of rivers to save a buck or two? No problem the state will pay to clean it up.

          BTW there is nothing preventing anybd
    • Not too heavily influenced, but enough that people understand that when you work in a team, even as the leader, your success and the team's success are one-in-the-same.

      Like in DePalma's The Untouchables ... Al Capone gives his boys a little lecture, swinging a baseball bat as he speaks:

      Business is like a baseball team ... pitcher, batter, everybody's got a job to do for the team ... yadda yadda ... but when somebody fucks up ... WHACK!

      That's when Capone (Robert DeNiro) takes the baseball bat and sma

    • "Of course schools often discredit this by having teachers who will grade down an entire team because of a slacker or two's stupidity, whereas in the real world the slackers would get fired for bad performance. I have had a class before in college where I got graded off because another team screwed up and made it impossible for my team to finish our work."

      well if the team gets marked down because of a few slackers, then the team's at fault for not having sorted those slackers out themselves...

  • If I understand the review correctly: development methodology, platform, language are all far distant seconds to the politics of social group interaction. Or another way, any chance of success is easily spoiled by a few bad apples. This is a fundamental facet of development that language and methodology advocates usually fail to mention.

    I usually hear things like, if we all just did 'x' then our problems would be solved. Problem is given a large enough group, say about 3 or more, they'll almost never all d

  • A related short article (Score:5, Interesting)

    by 14erCleaner ( 745600 ) <FourteenerCleaner@yahoo.com> on Monday October 18, 2004 @04:54PM (#10559731) Homepage Journal
    This month's IEEE Computer magazine has an article titled "Do Agile Methods Marginalize Problem Solvers?" that is interesting and relevant to this discussion. I'd recommend hunting it down and reading it (it's not available for free online, unfortunately....)

    The gist of the article is that first-rate problem-solvers are not well suited for "agile" methods, because they tend to be more individualistic (and the agile methods tend to force programmers to interact continually).

    I especially thought it was interesting that programmers with good people skills do better in agile methodologies, and that there are many more programmers than there used to be who have good people skills. This could be the death of the Dilbert stereotype....

    • This month's IEEE Computer magazine has an article titled "Do Agile Methods Marginalize Problem Solvers?"

      That article uses the example of Isaac Newton as someone not well suited to Agile methods. I propose that a genius at the level of Isaac Newton is equally poorly suited to every existing software methodology out there. (The thought of Newton in a meeting, gathering buyoff for his requirements document is so depressing it makes me sick.)

  • And if, as a professional programmer, you have ingested too much Jolt Cola throughout the day to easily fall asleep at night, this is the book for you! In fact, I have a copy right here, and just browsing through the index makes me feel very drowszzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz.

  • What it means to develop in an agile environment (Score:5, Interesting)

    by Rheagar ( 556811 ) on Monday October 18, 2004 @05:34PM (#10560046) Homepage
    I just took a two day class on Agile programming. I thought I would share some high level points from the class to help describe an agile environment so that others may decide if this is something that they should investigate for themselves:

    Agile is meant for projects where change is a fact of life. If your project has explicit, written in stone, unchanging goals then you should consider another design methodology.

    Agile development focuses on rapid delivery of working (but not polished) software. It should be lightweight, but still accomplish the functional goal.

    Agile projects should provide value long before they are finished. Each increment of functionality should be useful for a customer.

    Agile is not meant for large teams. Agile does not work well with customers who can not provide frequent feedback. Agile is not optimal for projets which have stable needs that are known from the beginning. Agile is not a good choice for mission critical products.

    These are the basics as taught to me, they may not be the same as presented in this book.

    • in other words, Agile is for software projects that took place in 1997. Except for that working part
    • If your project has explicit, written in stone, unchanging goals...

      Then you've drunk the Kool-Aid. Go throw up and quit trusting the customer not to screw you over. Now!!!

      Agile is not a good choice for mission critical products.

      Riiiiight:) Mission critical (as in "this needs to happen or the company folds") products need to spend months doing BDUF (Big Design Up Front) in order to stay in line with the 70% failure rate that business has come to expect (and resent) from software development methods.
  • What about the OSS buisness model? Is this taken into account:

    1) Idea
    2) ??
    3) Profit

    just wondering ;)

  • It's ONLINE! (Score:3, Informative)

    by neves ( 324086 ) on Monday October 18, 2004 @05:59PM (#10560247) Homepage
    The book is On Line [easycomp.org]. Go, read it.

  • The best and worst experiences... (Score:4, Insightful)

    by mikael ( 484 ) on Monday October 18, 2004 @06:10PM (#10560301)
    The most successful projects I have worked on were always blue-sky projects, were where:

    o Any existing utility libraries had been heavily tried and tested

    o Everyone was enthusiastic about the particular area of work they were doing, as new code was being designed.

    o Everyone had separate areas of work, and there were well defined API layers between each module.

    o There were only two agenda's affecting everyone
    - Management wanting the work complete
    - The programmers/software engineers
    wanting the work experience

    The worst projects have been:

    o No well cleared API layers, and programmers belting code into each others routines without checking with each other.

    o Senior management (in head office) messing everything up by adding a third agenda and switching everyone around for the sake
    of having the brighest graduate working on XXXX instead of YYYY.

  • Agile? hmmm.. why not Fittness Programming?

    I can see the project leader: "OK, Move those bits boys! MOVE! MOVE!"

  • Linus did not need any patterns - just plain good code.

    Linus, if you read this junkie website please don't prove me wrong (I might have to call you a flip-flopper for hurting my feeling !)

  • Comment removed based on user account deletion

  • Pet peave (Score:5, Interesting)

    by mrjb ( 547783 ) on Tuesday October 19, 2004 @02:28AM (#10562817)
    Why do software projects fail? - Hanging on to long-evolved, poor design instead of refactoring when needed. Sometimes starting over is the only solution, but it is nearly impossible to convince a company to rebuild, from scratch, an entire system that they had custom developed in a timespan of over 10 years. - Attempting to build a super-system that 'does everything' instead of serveral smalls systems that just do their part. A small, modular system (even being part of a bigger whole) is easier to replace than a huge one. Results in the situation described above. - People entering and leaving projects. When people leave a project, so does the knowledge that they built up and invested in the project. Documentation is harder to find than the tooth fairy. - Managers pushing the wrong technical decisions, not being able to forsee their implications.
  • If I develop more efficiently, do I get paid more? Does it stave off the inevitable outsourcing to guys working for 10% of my salary? No, you say? Then why, dear heart, should I give a damn?
  • I'm working on a project that is 2 years late already. And in the 9 months I've been on the project the Go Live date has moved from October to June (8 months). Whats lacking in the project is good Project Management skills. Oh well.
    • I have been programming for pay since 1987. I have been on a few successful projects and plenty of flops. Success happens for many reasons but one important reason for success is that management needs to have a clue about how software is made and what the customer needs.

      The problem is that it all comes down to compromises. Making the right compromises is the difference between success and failure. Its making that decision between slipping on the schedule and dropping feature X.

      All too often, clueless

Slashdot Top Deals

If mathematically you end up with the wrong answer, try multiplying by the page number.

Close