Slashdot Mirror
Organizational Patterns of Agile Software Development
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.
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
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 learning from our past and eschewing prejudices and gut-feeling management is a good start.
I'm with Coplien on this one.
/JE
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"
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 problem to solve, another resurce to manipulate. Until the "American Programmer" (whee!) figures that out, the "American Programmer" will continue down the path of extinction.
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 testable evaluation criteria. One of the main reasons that Pattern Languages are not theories is the lack of such testability and then of course evidence that could validate or falsify them.
If I want to design systems that I can trust I need design theories, their justifications and their boundaries. I can't build reliably if I don't know the justifications for these design theories and if I don't know when they can and cannot be applied to a given situation.
In a series of essays on my weblog, I've started to explore some of these ideas in more detail. I'd appreciate feedback.
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 =)
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?
"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.
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.
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 things, because it prevents you from shortchanging things that are important but not urgent. In Extreme Programming, there is no magic date when the project is "done", so there's no excuse for letting things get messy.
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 these days, the essential ingredient of any method for building software is tight feedback loops. If a method allows you four years between making guesses and finding out whether they're right, it's a method I'm content to let others try.
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.
evil is as evil does
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.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
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.
:)) 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.
.
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
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
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.
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 -- programming is so very different from almost all of those disciplines (not counting mathematicians, obviously, since nowadays an increasing number are also computer scientists by necessity). Programming ends up requiring a deeper committment because the possibilities are so much greater.
An architect may work his whole life, design thousands of structures, and finally write a book about some of the fundamental principles that the good designs share.
Likewise, a programmer may create a system every bit as complex, and frequently more complex, than the overall complexity of the CAD for a medium-sized office building. However, the good programmer immediately looks for the common elements, and is in effect able to -- because of the radically different nature of programming from most other disciplines -- from that point on, deal with those principles in the abstract. This is something that you can only do in a limited sense with non-programming jobs.
After all, repetition is a part of life, and life experience, but in programming you can solve a problem "once and for all". The only use for experience is, not in having solved a problem before, but in learning how better to understand a problem.
In effect, then, good programmers are never solving the same problems twice, and thus everything they are working on is new to them. If it's not a fundamentally new problem, the effort required is often trivial in a large subset of problems where the architectures exist for a high degree of abstraction (some of the problem areas being GUI programming; toolkits like Glade are still a ways away from providing the kind of abstraction we can enjoy in, say, the persistence layer).
All good programmers are constantly trying to understand problems better, trying to understand methods and techniques better, and most of all, trying to understand themselves better so that they, as humble programmers, can better understand how to use the limited capacity of their skull to accomplish potentially unlimited things.
What this means for managers: if your company hires good programmers, they have the capability to design a solution based on a problem. The more they understand the problem -- all facets of it, including what the user expects to see -- they better the result will be. There literally is a direct connection between how "good" a programmer is -- in terms of problem-solving, not hacking -- and how overall effective and useful he will be, and the quality of his results.
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.
I don't think that most programmers need to worry about yoga classes or philosophy classes. All they have to do is continue to elevate their level of understanding, and these improvements come with the territory.
This is what I, and others, mean when we say that we doubt that Design Patterns will catch on with management! Design patterns are there to take the mystery out of abstraction, to take the mystery out of efficiency, to take the mystery out of success! This is the kind of thing that is fairly unique, and doesn't tend to be well-received, let alone become a cornerstone of an industry.
Contrast this with management. As someone who's had to take a managing role in a lot of different contexts, I haven't heard the
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.
What's in a sig?