|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
I also hate to offend other people’s sensibilities—given that software methodology has always been akin to religion. With the caveat that there’s no reason anybody should care about the opinions of a computer scientist/mathematician like me regarding software development, let me just say that almost everything I’ve ever heard associated with the term "extreme programming" sounds like exactly the wrong way to go...with one exception. The exception is the idea of working in teams and reading each other’s code. That idea is crucial, and it might even mask out all the terrible aspects of extreme programming that alarm me. Donald Knuth So what's the real objection to Extreme Programming? Well, like any other 'extreme' activity it's simply an moron's way of making whatever he happens to be doing sound cool. |
|
|
When it comes to ‘extreme programming' (XP) methodology I tend to be extremely skeptical. It looks like a "Viva Viagra" movement (or worse "Vioxx" type of fad), more the symbol of complete corruption of a large part of academic community than anything else. Software engineering has an unfortunate tendency towards fanatical adherence to the latest fad that is always sold as a silver bullet. Often, this involves an implementation language backed by a marketing push (remember hey days of Java hype). Fashionable languages like woman clothing tend to change each decade of so. And not always to the better. With software methodologies the situation is even worse. This "progress" from XP to Agile to DevOps does not inspire any confidence. To say it mildly.
At a basic level of analysis, Extreme Programming is not a technical methodology, but a mix of a management style (how to form software development teams) and a technical cult. The latter promotes it's own primitive and somewhat destructive utopia. The number of zealots are significant and objective discussion is difficult to this very reason. Please be aware that there are a lot of books on Amazon that is graded 4 stars or higher on the topic that are complete and utter nonsense. Actually authors who participated in propagation of this methodology should be treated in a special way: participation of any of those authors in other books is a sure warning sign that the book is junk.
Amazon lists approximately 50 books in a search for the term. I actually do not see any of the authors I respect in the list of authors of "Extreme programming bookshelf".
|
|
At the same time any critical book are a sure sign of presence of some level of courage and deserves respect, especially if it was published during the years of "top hype". See, for example, Questioning Extreme Programming
XP was originated from the work of Kent Beck in Chrysler (Chrysler Comprehensive Compensation System payroll project) and the first book Extreme Programming Explained Embrace Change was published in October 1999. BTW Chrysler eventually canceled that project. BTW, even now, when the idea is by-and large discredited the second edition is rated 4.5 stars. Here is the first three one-star reviews from Amazon (one start reviews are around 12% of the total 112 reviews).
A customer on February 1, 2003
Glosses over the negativesThis book is simplistic. It glosses over the complete psychology involved in developing code with a team. I was very disappointed comparing what this book preaches and what it uses to substantiate its percepts. The analogical nature of the book doesn't allow one to anticipate problems and resolve them. As a programmer I don't think the book describes things as they are in team interactions. I'll keep my copy of the book. Some of the things written in it are so ludicrous as to be funny.
Jeffrey Kotula on May 8, 2000Chapter after chapter I kept thing that the author would get to something substantive. He never did. Not one example. Not one piece of concrete evidence. He had some good common sense ideas, but they are all presented in such general terms that they are self-evident. The author makes grand assumptions and goes on to explain (in generalizations) his theories which are based upon these assumptions. I often envisioned the author standing on a street corner proclaiming the end of the world or espousing the "scientific" basis of creationism while exposing his complete misunderstanding of science and his willingness to ignore facts that disprove his assertions. This entire book is written as if it were an introductory chapter. It reads like a psychology text - a lot of verbiage which hides the fact that the text has almost nothing to say.
XP considered harmfulRoger Log on May 5, 2002The XP approach to development is just another weak rationalization to explain why hacking is an OK approach. Design doesn't enter in until you've hacked yourself into a corner. While making bold claims, such as the claim that the cost-curve for early versus late changes to a product is actually flat (at least using XP), the key claims relied on in the book are never verified or quantified in any manner. Another annoyance of the book is that it seems to talk about *all* software development, but in actuality really only ever deals with issues of concern to IT organizations. Granted, that is a huge chunk of the industry, but the author never so much as acknowledges other application areas. There are some good things in the book, but only a very experienced engineer would be able to sort them out from the rest.
Absolutely Useless! So is CSCI477.This book is absolutely useless. The methodology taught is not "extreme", but rather ridiculous...His techniques will never be applied in actual software engineering, as they are completely impractical. For half of the ideas that are practical, they are simply common sense. Such as the 4 values: communication, simplicity, feedback, and courage. Every decent software engineer practices these values. In addition, the author fills up pages by telling stories of his childhood and other needless tales in an attempt to convince the reader that the techniques explained, truly work.
Don't waste your time or money. You'll only be aggravated once you open this book
The most noise was in 2000-2003. XP proponents quickly realized that just holding conferences, seminal and publishing books can be very profitable activity. In this sense XP is an early examples of "for profit" techno-cult. XP gradually faded and I did not noticed any books about it published in 2008. but then is re-emerged as a part of Agile software Development parts of which metamorphosed into DevOps -- a more modern (as of 2017 I would say "current") version of "for profit" techno-cult.
The term "Extreme programming" fades and now is replaced with "agile software development" and related terminology. Wikipedia even mentioned that extreme programming is a now considered to be a form of "agile development" (that's an interesting term, because opposite to agile development is probably "stagnant software development" :-). This proximity gives "agile development" term bad breath despite some sound ideas in the agile manifesto (which by-and-large looks like plagiarism of open source software development methodology).
One important sign of techno-cult is rejection of previous achievements and attempt to ignore them and pretend this this is novel approach. Both Extreme programming and Agile development fits the bill.
IBM was at one time very active in milking Agile cows via its Rational franchise:
In a keynote presentation and in correspondence afterward, IBM's Per Kroll, chief architect for IBM Rational Expertise Development & Innovation, cited the company's proliferation of agile practices among some of its approximately 35,000 developers.
"I think in general we have 1,000-plus people [using] agile in the IBM community," with an additional 2,000 persons trained in agile practices, Kroll said. He said, though, that he did not anticipate that all 35,000 developers would adopt agile.
On Monday at the conference, IBM's Scott Ambler, practice leader for agile development, spoke on the state of the agile space. Agile development focuses on developing software in iterations of usually two weeks. This allows for more flexibility than the traditional waterfall methodologies.
"Agile is taking many things that we’ve been using for a lot of years before agile was around [and] adding a lot of new things and putting a very good spin on it and making development more human," said Kroll. Concepts like iterative development and continuous integration are not new, but agile accounts for factors like human and collaborative aspects, he said. "We firmly believe, and our executives firmly believe, that the most successful organizations of tomorrow will be the ones [able] to adopt agile principles."
IBM has roughly 150 agile projects, he said. But each team needs to determine its own agile use based on their context. Agile means a lot of things to different teams, he said.
A key factor is that IBM helps customers and its own teams with applying agile complex environments, facing such issues as application complexity, scalability, and compliance issues, said Kroll.
That's sign that transformation of IBM into money milking and outsourcing behemoth, which exist to enrich shareholders and thin layer of top executives. Classic IBM which was the company which created IBM/360 series mainframes and personal PC was destroyed by infamous Lou "the last thing IBM needs right now is a vision" Gerstner . He was one of the first neoliberal honchos at the helm of large and respectable software/hardware company. Coming, as you can expect, from the financial company -- American Express -- which, if we allow to bypass political correctness, is somewhat close to a legitimized usury company; or at least strives to emulate this harpies by pushing debt on its customers (do you want $10K at zero percent for one year, 28% after ?) in a hope that they will not repay it in full and will be milked for months to come. He switched IBM from providing technical value to providing "shareholder value" (and first of all for himself; in 2002 when he left IBM he was worth $630 million). Of course "shareholder value" is a classic neoliberal mantra that hides the idea of redistribution of wealth up, but at this time it was very diffluent to fight, as his term (1993-2002) coincided with the triumphant march of neoliberalism all over the globe (the USSR collapsed in 1991). But I digress.
It seems like XP is some naive rehashing the idea of "surgical team" described in the mythical man-month. With some twist toward importance of reading each other code, but stupid way to achieve this goal. Propagandized by XP "pair programming" (which in case only one computer is available for two can be better called "cluster disaster") is some attempt to enforce collaboration but without typical in such cases hierarchy. there are some advantages of this approach -- "Pair programming" might a little bit help to stop programmers from spending to much time reading Slashdot or searching Goggle for things that has nothing to do with the project :-). It might be even cause decline of revenue at eBay. However, they seem to be able to compensate for this in a lot of other ways of decreasing programmers productivity :-)
While reading each other code is essential, collective ownership diminishes individual responsibility and deliberately creates communication overhead that diminishes each programmers productivity. may be exactly 50%. For more talented members of the team it entails a dramatic drop in productivity ("state farm effect") as explaining his ideas and way of reasoning to less gifted member of the team might be an interesting exercise once or two time. If it became routine is just creates hostility. As team in not hierarchical each member of the team has the right of veto. And that's a show stopper (which is not present in the idea of surgical teams).
Like with surgical team the most difficult part is not enforce such teams, but to get the right balance of personalities in the teams. If you pair a good programmer with a XP zealot, it is the zealot not a gifted programmer will be in a driving seat and the results will suffer. Greatly. Because the only thing that is worse the complete idiot is complete idiot with strong ideological bent. We all should periodically reread Brooks famous The Mythical Man-Month. You can also read Heart of a Dog by Mikhail Bulgakov ;-)
In this sense XP does not bring anything new to the table. In essence, this is a profanation of Brook's idea of surgical teams in a perverse way mixed with Microsoft idea "one programmer -- one tester". XP did not invent the "daily build" it was practiced by many organizations including Microsoft long before (I know NYC-based software firm Information Builders used in since at least 1992, may be easier), but made it popular.
In my opinion, extreme programming is extremely overrated. Some of the ideas, such as test-driven development (although this concept is not restricted to XP), work well. Others, such as pair programming just do not work in my opinion. Programmers like writers are solo beasts - putting two of these dragons behind one keyboard is asking for trouble.
As a methodology XP is pure fantasy. It has been well known for a long time that big bang or waterfall model does not work well. The 'spiral' model (iterating out from the core of a small well understood system) is a much better methodology popularized by Unix. It reemerged in a new better form in prototyping approach. Especially useful if target language in which system has to written is a compiled language line C++. In this case writing prototype in scripting language really helps.
Zealots defend XP "cluster disaster" claiming that this is a kind of "on the fly" code review. But one computer and the same cubicle idea is nonsense. Even two computers in the same cubicle as a mean to facilitate communication is questionable. It is unclear to me that communication improves, it people share the same cubicle. Actually it might create personal animosities. Meeting and discussing each other code on "neutral territory" is saver bet. In this sense the word "Extreme" in the name of this methodology is completely appropriate, because this is an example of extreme nonsense:
Sure, the name is some PR trick, but it makes sense because this technique is a reaction
to all those new trendy development process in which (when you push them to the extreme) you are
spending 90% of your time in meetings or drawing graphs and then the code is supposed to
magically write itself and work perfectly on the first build because this technique is so well
conceived.
It's called Extreme because they take some basically good ideas and push them to such extremes as to be completely useless in the real world.
Like any kind of engineering, software engineering needs face to face collaboration. but it is a strong medication and right doze is highly individual. To a point collaboration is important, but real SE requires careful planning by a talented architect and clear interface definitions that are enforced. some goes as far as to claim that "software lemmings" should be participate on the architectural level decisions as they tend to support mediocre solutions. That's why commercial software development with its string hierachy, if hieratchy is populated by right persons, can have an edge over open source development. On open source development "jump to the code" often occurred too fast and typically without any prototyping. And the courage to though away the first implementation is typically missing even if new better architecture was found during the implementation of the first version. Here the caliber of personality of architect is of primary importance. There is no replacement for displacement.
XP -- almost to the point of being pathological -- attempts to avoid planning as much as possible by substituting endless chatter and tremendous time wasting repeatedly re-implementing what could have been done right the first time. (And yes, I know some things always have to be re-implemented, but just because mistakes are inevitable doesn't mean they have to be encouraged; this way you can get rid of sound code just as easily as from bad one). When a single person works of small to medium project like writing a blog engine re-implementation might help because the first version combines coding with learning. But there is a danger that with the second version the author turn in "overachiever" and spoil the broth too. Generally good architectural talent, which include intuition about what to leave and what to rewrite is a rare thing. Like absolute pitch. Researchers estimate the occurrence of absolute pitch to be 1 in 10,000 people. The talent of software architect is probably even more rare.
All-in-all XP seems to be another programming fad built on unscrupulous books and conferences marketing (structured programming extremism and verification bonanza were the first). And like verification bonanza before, it has found an abundant number of zealots. May be due to its potential for snake oil salesmen promoting this mythology to earn a decent living at the expense of programmers suffering from it.
BTW "all or nothing" is not just an XP problem. Most SE methodologies are close to religions in a sense that they all try to convince you that their way is best, if you deviate you are a heretic; and if it all fails then it's your problem for not following the rules. The "prophets" that "invent" a methodology make their money from book publishing as well as teaching people how to do it. There are also a lot clueless followers, lemmings who believe everything that prophets preach (or hope to survive by faking loyalty to this methodology).
And the last thing prophets need is some kind of objective analysis or critique. Why would they kill their cash cow even if they themselves understand that they are wrong? In general, in SE methodology field, like in high demand cults the leaders cannot afford to correct themselves.
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
 |
 |
 |
Jul 03, 2021 | en.wikipedia.org
Mission creep is the gradual or incremental expansion of an intervention, project or mission, beyond its original scope, focus or goals , a ratchet effect spawned by initial success. [1] Mission creep is usually considered undesirable due to how each success breeds more ambitious interventions until a final failure happens, stopping the intervention entirely.
The term was originally applied exclusively to military operations , but has recently been applied to many different fields. The phrase first appeared in 1993, in articles published in the Washington Post and in the New York Times concerning the United Nations peacekeeping mission during the Somali Civil War .
...
- Feature creep is an analogous phenomenon in software engineering .
- Ratchet effect is the inability of a system to reduce its scope once it expands.
- Scope creep is an analogous phenomenon in project management .
|
|
|
Oct 26, 2017 | www.amazon.com
Mohammad B. Abdulfatah on February 10, 2003
Programming Malpractice Explained: Justifying Chaoswiredweird HALL OF FAME TOP 1000 REVIEWER on May 24, 2004To fairly review this book, one must distinguish between the methodology it presents and the actual presentation. As to the presentation, the author attempts to win the reader over with emotional persuasion and pep talk rather than with facts and hard evidence. Stories of childhood and comradeship don't classify as convincing facts to me.
A single case study-the C3 project-is often referred to, but with no specific information (do note that the project was cancelled by the client after staying in development for far too long).
As to the method itself, it basically boils down to four core practices:
- Always have a customer available on site.
- Unit test before you code.
- Program in pairs.
- Forfeit detailed design in favor of incremental, daily releases and refactoring.
If you do the above, and you have excellent staff on your hands, then the book promises that you'll reap the benefits of faster development, less overtime, and happier customers. Of course, the book fails to point out that if your staff is all highly qualified people, then the project is likely to succeed no matter what methodology you use. I'm sure that anyone who has worked in the software industry for sometime has noticed the sad state that most computer professionals are in nowadays.
However, assuming that you have all the topnotch developers that you desire, the outlined methodology is almost impossible to apply in real world scenarios. Having a customer always available on site would mean that the customer in question is probably a small, expendable fish in his organization and is unlikely to have any useful knowledge of its business practices.
Unit testing code before it is written means that one would have to have a mental picture of what one is going to write before writing it, which is difficult without upfront design. And maintaining such tests as the code changes would be a nightmare.
Programming in pairs all the time would assume that your topnotch developers are also sociable creatures, which is rarely the case, and even if they were, no one would be able to justify the practice in terms of productivity. I won't discuss why I think that abandoning upfront design is a bad practice; the whole idea is too ridiculous to debate.
Both book and methodology will attract fledgling developers with its promise of hacking as an acceptable software practice and a development universe revolving around the programmer. It's a cult, not a methodology, were the followers shall find salvation and 40-hour working weeks.
Experience is a great teacher, but only a fool would learn from it alone. Listen to what the opponents have to say before embracing change, and don't forget to take the proverbial grain of salt.
Two stars out of five for the presentation for being courageous and attempting to defy the standard practices of the industry. Two stars for the methodology itself, because it underlines several common sense practices that are very useful once practiced without the extremity.
eXtreme buzzwordingA customer on May 2, 2004Maybe it's an interesting idea, but it's just not ready for prime time.
Parts of Kent's recommended practice - including aggressive testing and short integration cycle - make a lot of sense. I've shared the same beliefs for years, but it was good to see them clarified and codified. I really have changed some of my practice after reading this and books like this.
I have two broad kinds of problem with this dogma, though. First is the near-abolition of documentation. I can't defend 2000 page specs for typical kinds of development. On the other hand, declaring that the test suite is the spec doesn't do it for me either. The test suite is code, written for machine interpretation. Much too often, it is not written for human interpretation. Based on the way I see most code written, it would be a nightmare to reverse engineer the human meaning out of any non-trivial test code. Some systematic way of ensuring human intelligibility in the code, traceable to specific "stories" (because "requirements" are part of the bad old way), would give me a lot more confidence in the approach.
The second is the dictatorial social engineering that eXtremity mandates. I've actually tried the pair programming - what a disaster. The less said the better, except that my experience did not actually destroy any professional relationships. I've also worked with people who felt that their slightest whim was adequate reason to interfere with my work. That's what Beck institutionalizes by saying that any request made of me by anyone on the team must be granted. It puts me completely at the mercy of anyone walking by. The requisite bullpen physical environment doesn't work for me either. I find that the visual and auditory distraction make intense concentration impossible.
I find revival tent spirit of the eXtremists very off-putting. If something works, it works for reasons, not as a matter of faith. I find much too much eXhortation to believe, to go ahead and leap in, so that I will eXperience the wonderfulness for myself. Isn't that what the evangelist on the subway platform keeps saying? Beck does acknowledge unbelievers like me, but requires their exile in order to maintain the group-think of the X-cult.
Beck's last chapters note a number of exceptions and special cases where eXtremism may not work - actually, most of the projects I've ever encountered.There certainly is good in the eXtreme practice. I look to future authors to tease that good out from the positively destructive threads that I see interwoven.
A work of fictionA customer on November 14, 2002The book presents extreme programming. It is divided into three parts:
(1) The problem
(2) The solution
(3) Implementing XP.The problem, as presented by the author, is that requirements change but current methodologies are not agile enough to cope with this. This results in customer being unhappy. The solution is to embrace change and to allow the requirements to be changed. This is done by choosing the simplest solution, releasing frequently, refactoring with the security of unit tests.
The basic assumption which underscores the approach is that the cost of change is not exponential but reaches a flat asymptote. If this is not the case, allowing change late in the project would be disastrous. The author does not provide data to back his point of view. On the other hand there is a lot of data against a constant cost of change (see for example discussion of cost in Code Complete). The lack of reasonable argumentation is an irremediable flaw in the book. Without some supportive data it is impossible to believe the basic assumption, nor the rest of the book. This is all the more important since the only project that the author refers to was cancelled before full completion.
Many other parts of the book are unconvincing. The author presents several XP practices. Some of them are very useful. For example unit tests are a good practice. They are however better treated elsewhere (e.g., Code Complete chapter on unit test). On the other hand some practices seem overkill. Pair programming is one of them. I have tried it and found it useful to generate ideas while prototyping. For writing production code, I find that a quiet environment is by far the best (see Peopleware for supportive data). Again the author does not provide any data to support his point.
This book suggests an approach aiming at changing software engineering practices. However the lack of supportive data makes it a work of fiction.
I would suggest reading Code Complete for code level advice or Rapid Development for management level advice.Not Software Engineering.Philip K. Ronzone on November 24, 2000Any Engineering discipline is based on solid reasoning and logic not on blind faith. Unfortunately, most of this book attempts to convince you that Extreme programming is better based on the author's experiences. A lot of the principles are counterintuitive and the author exhorts you just try it out and get enlightened. I'm sorry but these kind of things belong in infomercials not in s/w engineering.
The part about "code is the documentation" is the scariest part. It's true that keeping the documentation up to date is tough on any software project, but to do away with documentation is the most ridiculous thing I have heard.
It's like telling people to cut of their noses to avoid colds. Yes we are always in search of a better software process. Let me tell you that this book won't lead you there.
The "gossip magazine diet plans" style of programming.A customer on August 11, 2003This book reminds me of the "gossip magazine diet plans", you know, the vinegar and honey diet, or the fat-burner 2000 pill diet etc. Occasionally, people actually lose weight on those diets, but, only because they've managed to eat less or exercise more. The diet plans themselves are worthless. XP is the same - it may sometimes help people program better, but only because they are (unintentionally) doing something different. People look at things like XP because, like dieters, they see a need for change. Overall, the book is a decently written "fad diet", with ideas that are just as worthless.
Hackers! Salvation is nigh!!Ian K. VINE VOICE on February 27, 2015It's interesting to see the phenomenon of Extreme Programming happening in the dawn of the 21st century. I suppose historians can explain such a reaction as a truly conservative movement. Of course, serious software engineering practice is hard. Heck, documentation is a pain in the neck. And what programmer wouldn't love to have divine inspiration just before starting to write the latest web application and so enlightened by the Almighty, write the whole thing in one go, as if by magic? No design, no documentation, you and me as a pair, and the customer too. Sounds like a hacker's dream with "Imagine" as the soundtrack (sorry, John).
The Software Engineering struggle is over 50 years old and it's only logical to expect some resistance, from time to time. In the XP case, the resistance comes in one of its worst forms: evangelism. A fundamentalist cult, with very little substance, no proof of any kind, but then again if you don't have faith you won't be granted the gift of the mystic revelation. It's Gnosticism for Geeks.
Take it with a pinch of salt.. well, maybe a sack of salt. If you can see through the B.S. that sells millions of dollars in books, consultancy fees, lectures, etc, you will recognise some common-sense ideas that are better explained, explored and detailed elsewhere.Long have I hated this bookAnil Philip on March 24, 2005Kent is an excellent writer. He does an excellent job of presenting an approach to software development that is misguided for anything but user interface code. The argument that user interface code must be gotten into the hands of users to get feedback is used to suggest that complex system code should not be "designed up front". This is simply wrong. For example, if you are going to deploy an application in the Amazon Cloud that you want to scale, you better have some idea of how this is going to happen. Simply waiting until your application falls over and fails is not an acceptable approach.
One of the things I despise the most about the software development culture is the mindless adoption of fads. Extreme programming has been adopted by some organizations like a religious dogma.
Engineering large software systems is one of the most difficult things that humans do. There are no silver bullets and there are no dogmatic solutions that will make the difficult simple.
not found - the silver bulletMaybe I'm too cynical because I never got to work for the successful, whiz-kid companies; Maybe this book wasn't written for me!
This book reminds me of Jacobsen's "Use Cases" book of the 1990s. 'Use Cases' was all the rage but after several years, we slowly learned the truth: Uses Cases does not deal with the architecture - a necessary and good foundation for any piece of software.
Similarly, this book seems to be spotlighting Testing and taking it to extremes.
'the test plan is the design doc'
Not True. The design doc encapsulates wisdom and insight
a picture that accurately describes the interactions of the lower level software components is worth a thousand lines of code-reading.
Also present is an evangelistic fervor that reminds me of the rah-rah eighties' bestseller, "In Search Of Excellence" by Peters and Waterman. (Many people have since noted that most of the spotlighted companies of that book are bankrupt twenty five years later).
- - in a room full of people with a bully supervisor (as I experienced in my last job at a major telco) innovation or good work is largely absent.
- - deploy daily - are you kidding? to run through the hundreds of test cases in a large application takes several hours if not days. Not all testing can be automated.
- - I have found the principle of "baby steps", one of the principles in the book, most useful in my career - it is the basis for prototyping iteratively. However I heard it described in 1997 at a pep talk at MCI that the VP of our department gave to us. So I dont know who stole it from whom!
Lastly, I noted that the term 'XP' was used throughout the book, and the back cover has a blurb from an M$ architect. Was it simply coincidence that Windows shares the same name for its XP release? I wondered if M$ had sponsored part of the book as good advertising for Windows XP! :)
|
|
|
Jul 25, 2017 | www.paulgraham.com
CACM , December 1974
When Communications of the ACM began publication in 1959, the members of ACM'S Editorial Board made the following remark as they described the purposes of ACM'S periodicals [2]:
"If computer programming is to become an important part of computer research and development, a transition of programming from an art to a disciplined science must be effected."Such a goal has been a continually recurring theme during the ensuing years; for example, we read in 1970 of the "first steps toward transforming the art of programming into a science" [26]. Meanwhile we have actually succeeded in making our discipline a science, and in a remarkably simple way: merely by deciding to call it "computer science."Implicit in these remarks is the notion that there is something undesirable about an area of human activity that is classified as an "art"; it has to be a Science before it has any real stature. On the other hand, I have been working for more than 12 years on a series of books called "The Art of Computer Programming." People frequently ask me why I picked such a title; and in fact some people apparently don't believe that I really did so, since I've seen at least one bibliographic reference to some books called "The Act of Computer Programming."
In this talk I shall try to explain why I think "Art" is the appropriate word. I will discuss what it means for something to be an art, in contrast to being a science; I will try to examine whether arts are good things or bad things; and I will try to show that a proper viewpoint of the subject will help us all to improve the quality of what we are now doing.
One of the first times I was ever asked about the title of my books was in 1966, during the last previous ACM national meeting held in Southern California. This was before any of the books were published, and I recall having lunch with a friend at the convention hotel. He knew how conceited I was, already at that time, so he asked if I was going to call my books "An Introduction to Don Knuth." I replied that, on the contrary, I was naming the books after him . His name: Art Evans. (The Art of Computer Programming, in person.)
From this story we can conclude that the word "art" has more than one meaning. In fact, one of the nicest things about the word is that it is used in many different senses, each of which is quite appropriate in connection with computer programming. While preparing this talk, I went to the library to find out what people have written about the word "art" through the years; and after spending several fascinating days in the stacks, I came to the conclusion that "art" must be one of the most interesting words in the English language.
The Arts of Old
If we go back to Latin roots, we find ars, artis meaning "skill." It is perhaps significant that the corresponding Greek word was τεχνη , the root of both "technology" and "technique."
Nowadays when someone speaks of "art" you probably think first of "fine arts" such as painting and sculpture, but before the twentieth century the word was generally used in quite a different sense. Since this older meaning of "art" still survives in many idioms, especially when we are contrasting art with science, I would like to spend the next few minutes talking about art in its classical sense.
In medieval times, the first universities were established to teach the seven so-called "liberal arts," namely grammar, rhetoric, logic, arithmetic, geometry, music, and astronomy. Note that this is quite different from the curriculum of today's liberal arts colleges, and that at least three of the original seven liberal arts are important components of computer science. At that time, an "art" meant something devised by man's intellect, as opposed to activities derived from nature or instinct; "liberal" arts were liberated or free, in contrast to manual arts such as plowing (cf. [6]). During the middle ages the word "art" by itself usually meant logic [4], which usually meant the study of syllogisms.
Science vs. Art
The word "science" seems to have been used for many years in about the same sense as "art"; for example, people spoke also of the seven liberal sciences, which were the same as the seven liberal arts [1]. Duns Scotus in the thirteenth century called logic "the Science of Sciences, and the Art of Arts" (cf. [12, p. 34f]). As civilization and learning developed, the words took on more and more independent meanings, "science" being used to stand for knowledge, and "art" for the application of knowledge. Thus, the science of astronomy was the basis for the art of navigation. The situation was almost exactly like the way in which we now distinguish between "science" and "engineering."
Many authors wrote about the relationship between art and science in the nineteenth century, and I believe the best discussion was given by John Stuart Mill. He said the following things, among others, in 1843 [28]:
Several sciences are often necessary to form the groundwork of a single art. Such is the complication of human affairs, that to enable one thing to be done , it is often requisite to know the nature and properties of many things... Art in general consists of the truths of Science, arranged in the most convenient order for practice, instead of the order which is the most convenient for thought. Science groups and arranges its truths so as to enable us to take in at one view as much as possible of the general order of the universe. Art... brings together from parts of the field of science most remote from one another, the truths relating to the production of the different and heterogeneous conditions necessary to each effect which the exigencies of practical life require.As I was looking up these things about the meanings of "art," I found that authors have been calling for a transition from art to science for at least two centuries. For example, the preface to a textbook on mineralogy, written in 1784, said the following [17]: "Previous to the year 1780, mineralogy, though tolerably understood by many as an Art, could scarce be deemed a Science."According to most dictionaries "science" means knowledge that has been logically arranged and systematized in the form of general "laws." The advantage of science is that it saves us from the need to think things through in each individual case; we can turn our thoughts to higher-level concepts. As John Ruskin wrote in 1853 [32]: "The work of science is to substitute facts for appearances, and demonstrations for impressions."
It seems to me that if the authors I studied were writing today, they would agree with the following characterization: Science is knowledge which we understand so well that we can teach it to a computer; and if we don't fully understand something, it is an art to deal with it. Since the notion of an algorithm or a computer program provides us with an extremely useful test for the depth of our knowledge about any given subject, the process of going from an art to a science means that we learn how to automate something.
Artificial intelligence has been making significant progress, yet there is a huge gap between what computers can do in the foreseeable future and what ordinary people can do. The mysterious insights that people have when speaking, listening, creating, and even when they are programming, are still beyond the reach of science; nearly everything we do is still an art.
From this standpoint it is certainly desirable to make computer programming a science, and we have indeed come a long way in the 15 years since the publication of the remarks I quoted at the beginning of this talk. Fifteen years ago computer programming was so badly understood that hardly anyone even thought about proving programs correct; we just fiddled with a program until we "knew" it worked. At that time we didn't even know how to express the concept that a program was correct, in any rigorous way. It is only in recent years that we have been learning about the processes of abstraction by which programs are written and understood; and this new knowledge about programming is currently producing great payoffs in practice, even though few programs are actually proved correct with complete rigor, since we are beginning to understand the principles of program structure. The point is that when we write programs today, we know that we could in principle construct formal proofs of their correctness if we really wanted to, now that we understand how such proofs are formulated. This scientific basis is resulting in programs that are significantly more reliable than those we wrote in former days when intuition was the only basis of correctness.
The field of "automatic programming" is one of the major areas of artificial intelligence research today. Its proponents would love to be able to give a lecture entitled "Computer Programming as an Artifact" (meaning that programming has become merely a relic of bygone days), because their aim is to create machines that write programs better than we can, given only the problem specification. Personally I don't think such a goal will ever be completely attained, but I do think that their research is extremely important, because everything we learn about programming helps us to improve our own artistry. In this sense we should continually be striving to transform every art into a science: in the process, we advance the art.
Science and Art
Our discussion indicates that computer programming is by now both a science and an art, and that the two aspects nicely complement each other. Apparently most authors who examine such a question come to this same conclusion, that their subject is both a science and an art, whatever their subject is (cf. [25]). I found a book about elementary photography, written in 1893, which stated that "the development of the photographic image is both an art and a science" [13]. In fact, when I first picked up a dictionary in order to study the words "art" and "science," I happened to glance at the editor's preface, which began by saying, "The making of a dictionary is both a science and an art." The editor of Funk & Wagnall's dictionary [27] observed that the painstaking accumulation and classification of data about words has a scientific character, while a well-chosen phrasing of definitions demands the ability to write with economy and precision: "The science without the art is likely to be ineffective; the art without the science is certain to be inaccurate."
When preparing this talk I looked through the card catalog at Stanford library to see how other people have been using the words "art" and "science" in the titles of their books. This turned out to be quite interesting.
For example, I found two books entitled The Art of Playing the Piano [5, 15], and others called The Science of Pianoforte Technique [10], The Science of Pianoforte Practice [30]. There is also a book called The Art of Piano Playing: A Scientific Approach [22].
Then I found a nice little book entitled The Gentle Art of Mathematics [31], which made me somewhat sad that I can't honestly describe computer programming as a "gentle art." I had known for several years about a book called The Art of Computation , published in San Francisco, 1879, by a man named C. Frusher Howard [14]. This was a book on practical business arithmetic that had sold over 400,000 copies in various editions by 1890. I was amused to read the preface, since it shows that Howard's philosophy and the intent of his title were quite different from mine; he wrote: "A knowledge of the Science of Number is of minor importance; skill in the Art of Reckoning is absolutely indispensible."
Several books mention both science and art in their titles, notably The Science of Being and Art of Living by Maharishi Mahesh Yogi [24]. There is also a book called The Art of Scientific Discovery [11], which analyzes how some of the great discoveries of science were made.
So much for the word "art" in its classical meaning. Actually when I chose the title of my books, I wasn't thinking primarily of art in this sense, I was thinking more of its current connotations. Probably the most interesting book which turned up in my search was a fairly recent work by Robert E. Mueller called The Science of Art [29]. Of all the books I've mentioned, Mueller's comes closest to expressing what I want to make the central theme of my talk today, in terms of real artistry as we now understand the term. He observes: "It was once thought that the imaginative outlook of the artist was death for the scientist. And the logic of science seemed to spell doom to all possible artistic flights of fancy." He goes on to explore the advantages which actually do result from a synthesis of science and art.
A scientific approach is generally characterized by the words logical, systematic, impersonal, calm, rational, while an artistic approach is characterized by the words aesthetic, creative, humanitarian, anxious, irrational. It seems to me that both of these apparently contradictory approaches have great value with respect to computer programming.
Emma Lehmer wrote in 1956 that she had found coding to be "an exacting science as well as an intriguing art" [23]. H.S.M. Coxeter remarked in 1957 that he sometimes felt "more like an artist than a scientist" [7]. This was at the time C.P. Snow was beginning to voice his alarm at the growing polarization between "two cultures" of educated people [34, 35]. He pointed out that we need to combine scientific and artistic values if we are to make real progress.
Works of Art
When I'm sitting in an audience listening to a long lecture, my attention usually starts to wane at about this point in the hour. So I wonder, are you getting a little tired of my harangue about "science" and "art"? I really hope that you'll be able to listen carefully to the rest of this, anyway, because now comes the part about which I feel most deeply.
When I speak about computer programming as an art, I am thinking primarily of it as an art form , in an aesthetic sense. The chief goal of my work as educator and author is to help people learn how to write beautiful programs . It is for this reason I was especially pleased to learn recently [32] that my books actually appear in the Fine Arts Library at Cornell University. (However, the three volumes apparently sit there neatly on the shelf, without being used, so I'm afraid the librarians may have made a mistake by interpreting my title literally.)
My feeling is that when we prepare a program, it can be like composing poetry or music; as Andrei Ershov has said [9], programming can give us both intellectual and emotional satisfaction, because it is a real achievement to master complexity and to establish a system of consistent rules.
Furthermore when we read other people's programs, we can recognize some of them as genuine works of art. I can still remember the great thrill it was for me to read the listing of Stan Poley's SOAP II assembly program in 1958; you probably think I'm crazy, and styles have certainly changed greatly since then, but at the time it meant a great deal to me to see how elegant a system program could be, especially by comparison with the heavy-handed coding found in other listings I had been studying at the same time. The possibility of writing beautiful programs, even in assembly language, is what got me hooked on programming in the first place.
Some programs are elegant, some are exquisite, some are sparkling. My claim is that it is possible to write grand programs, noble programs, truly magnificent ones!
Taste and Style
The idea of style in programming is now coming to the forefront at last, and I hope that most of you have seen the excellent little book on Elements of Programming Style by Kernighan and Plauger [16]. In this connection it is most important for us all to remember that there is no one "best" style; everybody has his own preferences, and it is a mistake to try to force people into an unnatural mold. We often hear the saying, "I don't know anything about art, but I know what I like." The important thing is that you really like the style you are using; it should be the best way you prefer to express yourself.
Edsger Dijkstra stressed this point in the preface to his Short Introduction to the Art of Programming [8]:
It is my purpose to transmit the importance of good taste and style in programming, [but] the specific elements of style presented serve only to illustrate what benefits can be derived from "style" in general. In this respect I feel akin to the teacher of composition at a conservatory: He does not teach his pupils how to compose a particular symphony, he must help his pupils to find their own style and must explain to them what is implied by this. (It has been this analogy that made me talk about "The Art of Programming.")Now we must ask ourselves, What is good style, and what is bad style? We should not be too rigid about this in judging other people's work. The early nineteenth-century philosopher Jeremy Bentham put it this way [3, Bk. 3, Ch. 1]:Judges of elegance and taste consider themselves as benefactors to the human race, whilst they are really only the interrupters of their pleasure... There is no taste which deserves the epithet good , unless it be the taste for such employments which, to the pleasure actually produced by them, conjoin some contingent or future utility: there is no taste which deserves to be characterized as bad, unless it be a taste for some occupation which has a mischievous tendency.When we apply our own prejudices to "reform" someone else's taste, we may be unconsciously denying him some entirely legitimate pleasure. That's why I don't condemn a lot of things programmers do, even though I would never enjoy doing them myself. The important thing is that they are creating something they feel is beautiful.In the passage I just quoted, Bentham does give us some advice about certain principles of aesthetics which are better than others, namely the "utility" of the result. We have some freedom in setting up our personal standards of beauty, but it is especially nice when the things we regard as beautiful are also regarded by other people as useful. I must confess that I really enjoy writing computer programs; and I especially enjoy writing programs which do the greatest good, in some sense.
There are many senses in which a program can be "good," of course. In the first place, it's especially good to have a program that works correctly. Secondly it is often good to have a program that won't be hard to change, when the time for adaptation arises. Both of these goals are achieved when the program is easily readable and understandable to a person who knows the appropriate language.
Another important way for a production program to be good is for it to interact gracefully with its users, especially when recovering from human errors in the input data. It's a real art to compose meaningful error messages or to design flexible input formats which are not error-prone.
Another important aspect of program quality is the efficiency with which the computer's resources are actually being used. I am sorry to say that many people nowadays are condemning program efficiency, telling us that it is in bad taste. The reason for this is that we are now experiencing a reaction from the time when efficiency was the only reputable criterion of goodness, and programmers in the past have tended to be so preoccupied with efficiency that they have produced needlessly complicated code; the result of this unnecessary complexity has been that net efficiency has gone down, due to difficulties of debugging and maintenance.
The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.
We shouldn't be penny wise and pound foolish, nor should we always think of efficiency in terms of so many percent gained or lost in total running time or space. When we buy a car, many of us are almost oblivious to a difference of $50 or $100 in its price, while we might make a special trip to a particular store in order to buy a 50 cent item for only 25 cents. My point is that there is a time and place for efficiency; I have discussed its proper role in my paper on structured programming, which appears in the current issue of Computing Surveys [21].
Less Facilities: More Enjoyment
One rather curious thing I've noticed about aesthetic satisfaction is that our pleasure is significantly enhanced when we accomplish something with limited tools. For example, the program of which I personally am most pleased and proud is a compiler I once wrote for a primitive minicomputer which had only 4096 words of memory, 16 bits per word. It makes a person feel like a real virtuoso to achieve something under such severe restrictions.
A similar phenomenon occurs in many other contexts. For example, people often seem to fall in love with their Volkswagens but rarely with their Lincoln Continentals (which presumably run much better). When I learned programming, it was a popular pastime to do as much as possible with programs that fit on only a single punched card. I suppose it's this same phenomenon that makes APL enthusiasts relish their "one-liners." When we teach programming nowadays, it is a curious fact that we rarely capture the heart of a student for computer science until he has taken a course which allows "hands on" experience with a minicomputer. The use of our large-scale machines with their fancy operating systems and languages doesn't really seem to engender any love for programming, at least not at first.
It's not obvious how to apply this principle to increase programmers' enjoyment of their work. Surely programmers would groan if their manager suddenly announced that the new machine will have only half as much memory as the old. And I don't think anybody, even the most dedicated "programming artists," can be expected to welcome such a prospect, since nobody likes to lose facilities unnecessarily. Another example may help to clarify the situation: Film-makers strongly resisted the introduction of talking pictures in the 1920's because they were justly proud of the way they could convey words without sound. Similarly, a true programming artist might well resent the introduction of more powerful equipment; today's mass storage devices tend to spoil much of the beauty of our old tape sorting methods. But today's film makers don't want to go back to silent films, not because they're lazy but because they know it is quite possible to make beautiful movies using the improved technology. The form of their art has changed, but there is still plenty of room for artistry.
How did they develop their skill? The best film makers through the years usually seem to have learned their art in comparatively primitive circumstances, often in other countries with a limited movie industry. And in recent years the most important things we have been learning about programming seem to have originated with people who did not have access to very large computers. The moral of this story, it seems to me, is that we should make use of the idea of limited resources in our own education. We can all benefit by doing occasional "toy" programs, when artificial restrictions are set up, so that we are forced to push our abilities to the limit. We shouldn't live in the lap of luxury all the time, since that tends to make us lethargic. The art of tackling miniproblems with all our energy will sharpen our talents for the real problems, and the experience will help us to get more pleasure from our accomplishments on less restricted equipment.
In a similar vein, we shouldn't shy away from "art for art's sake"; we shouldn't feel guilty about programs that are just for fun. I once got a great kick out of writing a one-statement ALGOL program that invoked an innerproduct procedure in such an unusual way that it calculated the mth prime number, instead of an innerproduct [19]. Some years ago the students at Stanford were excited about finding the shortest FORTRAN program which prints itself out, in the sense that the program's output is identical to its own source text. The same problem was considered for many other languages. I don't think it was a waste of time for them to work on this; nor would Jeremy Bentham, whom I quoted earlier, deny the "utility" of such pastimes [3, Bk. 3, Ch. 1]. "On the contrary," he wrote, "there is nothing, the utility of which is more incontestable. To what shall the character of utility be ascribed, if not to that which is a source of pleasure?"
Providing Beautiful Tools
Another characteristic of modern art is its emphasis on creativity. It seems that many artists these days couldn't care less about creating beautiful things; only the novelty of an idea is important. I'm not recommending that computer programming should be like modern art in this sense, but it does lead me to an observation that I think is important. Sometimes we are assigned to a programming task which is almost hopelessly dull, giving us no outlet whatsoever for any creativity; and at such times a person might well come to me and say, "So programming is beautiful? It's all very well for you to declaim that I should take pleasure in creating elegant and charming programs, but how am I supposed to make this mess into a work of art?"
Well, it's true, not all programming tasks are going to be fun. Consider the "trapped housewife," who has to clean off the same table every day: there's not room for creativity or artistry in every situation. But even in such cases, there is a way to make a big improvement: it is still a pleasure to do routine jobs if we have beautiful things to work with. For example, a person will really enjoy wiping off the dining room table, day after day, if it is a beautifully designed table made from some fine quality hardwood.
Therefore I want to address my closing remarks to the system programmers and the machine designers who produce the systems that the rest of us must work with. Please, give us tools that are a pleasure to use, especially for our routine assignments, instead of providing something we have to fight with. Please, give us tools that encourage us to write better programs, by enhancing our pleasure when we do so.
It's very hard for me to convince college freshmen that programming is beautiful, when the first thing I have to tell them is how to punch "slash slash JoB equals so-and-so." Even job control languages can be designed so that they are a pleasure to use, instead of being strictly functional.
Computer hardware designers can make their machines much more pleasant to use, for example by providing floating-point arithmetic which satisfies simple mathematical laws. The facilities presently available on most machines make the job of rigorous error analysis hopelessly difficult, but properly designed operations would encourage numerical analysts to provide better subroutines which have certified accuracy (cf. [20, p. 204]).
Let's consider also what software designers can do. One of the best ways to keep up the spirits of a system user is to provide routines that he can interact with. We shouldn't make systems too automatic, so that the action always goes on behind the scenes; we ought to give the programmer-user a chance to direct his creativity into useful channels. One thing all programmers have in common is that they enjoy working with machines; so let's keep them in the loop. Some tasks are best done by machine, while others are best done by human insight; and a properly designed system will find the right balance. (I have been trying to avoid misdirected automation for many years, cf. [18].)
Program measurement tools make a good case in point. For years, programmers have been unaware of how the real costs of computing are distributed in their programs. Experience indicates that nearly everybody has the wrong idea about the real bottlenecks in his programs; it is no wonder that attempts at efficiency go awry so often, when a programmer is never given a breakdown of costs according to the lines of code he has written. His job is something like that of a newly married couple who try to plan a balanced budget without knowing how much the individual items like food, shelter, and clothing will cost. All that we have been giving programmers is an optimizing compiler, which mysteriously does something to the programs it translates but which never explains what it does. Fortunately we are now finally seeing the appearance of systems which give the user credit for some intelligence; they automatically provide instrumentation of programs and appropriate feedback about the real costs. These experimental systems have been a huge success, because they produce measurable improvements, and especially because they are fun to use, so I am confident that it is only a matter of time before the use of such systems is standard operating procedure. My paper in Computing Surveys [21] discusses this further, and presents some ideas for other ways in which an appropriate interactive routine can enhance the satisfaction of user programmers.
Language designers also have an obligation to provide languages that encourage good style, since we all know that style is strongly influenced by the language in which it is expressed. The present surge of interest in structured programming has revealed that none of our existing languages is really ideal for dealing with program and data structure, nor is it clear what an ideal language should be. Therefore I look forward to many careful experiments in language design during the next few years.
Summary
To summarize: We have seen that computer programming is an art, because it applies accumulated knowledge to the world, because it requires skill and ingenuity, and especially because it produces objects of beauty. A programmer who subconsciously views himself as an artist will enjoy what he does and will do it better. Therefore we can be glad that people who lecture at computer conferences speak about the state of the Art .
References
1. Bailey, Nathan. The Universal Etymological English Dictionary. T. Cox, London, 1727. See "Art," "Liberal," and "Science."
2. Bauer, Walter F., Juncosa, Mario L., and Perlis, Alan J. ACM publication policies and plans. J. ACM 6 (Apr. 1959), 121-122.
3. Bentham, Jeremy. The Rationale of Reward. Trans. from Theorie des peines et des recompenses, 1811, by Richard Smith, J. & H. L. Hunt, London, 1825.
4. The Century Dictionary and Cyclopedia 1. The Century Co., New York, 1889.
5. Clementi, Muzio. The Art of Playing the Piano. Trans. from L'art de jouer le pianoforte by Max Vogrich. Schirmer, New York, 1898.
6. Colvin, Sidney. "Art." Encyclopaedia Britannica, eds 9, 11, 12, 13, 1875-1926.
7. Coxeter, H. S. M. Convocation address, Proc. 4th Canadian Math. Congress, 1957, pp. 8-10.
8. Dijkstra, Edsger W. EWD316: A Short Introduction to the Art of Programming. T. H. Eindhoven, The Netherlands, Aug. 1971.
9. Ershov, A. P. Aesthetics and the human factor in programming. Comm. ACM 15 (July 1972), 501-505.
10. Fielden, Thomas. The Science of Pianoforte Technique. Macmillan, London, 927.
11. Gore, George. The Art of Scientific Discovery. Longmans, Green, London, 1878.
12. Hamilton, William. Lectures on Logic 1. Win. Blackwood, Edinburgh, 1874.
13. Hodges, John A. Elementary Photography: The "Amateur Photographer" Library 7. London, 1893. Sixth ed, revised and enlarged, 1907, p. 58.
14. Howard, C. Frusher. Howard's Art of Computation and golden rule for equation of payments for schools, business colleges and self-culture .... C.F. Howard, San Francisco, 1879.
15. Hummel, J.N. The Art of Playing the Piano Forte. Boosey, London, 1827.
16. Kernighan B.W., and Plauger, P.J. The Elements of Programming Style. McGraw-Hill, New York, 1974.
17. Kirwan, Richard. Elements of Mineralogy. Elmsly, London, 1784.
18. Knuth, Donald E. Minimizing drum latency time. J. ACM 8 (Apr. 1961), 119-150.
19. Knuth, Donald E., and Merner, J.N. ALGOL 60 confidential. Comm. ACM 4 (June 1961), 268-272.
20. Knuth, Donald E. Seminumerical Algorithms: The Art of Computer Programming 2. Addison-Wesley, Reading, Mass., 1969.
21. Knuth, Donald E. Structured programming with go to statements. Computing Surveys 6 (Dec. 1974), pages in makeup.
22. Kochevitsky, George. The Art of Piano Playing: A Scientific Approach. Summy-Birchard, Evanston, II1., 1967.
23. Lehmer, Emma. Number theory on the SWAC. Proc. Syrup. Applied Math. 6, Amer. Math. Soc. (1956), 103-108.
24. Mahesh Yogi, Maharishi. The Science of Being and Art of Living. Allen & Unwin, London, 1963.
25. Malevinsky, Moses L. The Science of Playwriting. Brentano's, New York, 1925.
26. Manna, Zohar, and Pnueli, Amir. Formalization of properties of functional programs. J. ACM 17 (July 1970), 555-569.
27. Marckwardt, Albert H, Preface to Funk and Wagnall's Standard College Dictionary. Harcourt, Brace & World, New York, 1963, vii.
28. Mill, John Stuart. A System Of Logic, Ratiocinative and Inductive. London, 1843. The quotations are from the introduction, S 2, and from Book 6, Chap. 11 (12 in later editions), S 5.
29. Mueller, Robert E. The Science of Art. John Day, New York, 1967.
30. Parsons, Albert Ross. The Science of Pianoforte Practice. Schirmer, New York, 1886.
31. Pedoe, Daniel. The Gentle Art of Mathematics. English U. Press, London, 1953.
32. Ruskin, John. The Stones of Venice 3. London, 1853.
33. Salton, G.A. Personal communication, June 21, 1974.
34. Snow, C.P. The two cultures. The New Statesman and Nation 52 (Oct. 6, 1956), 413-414.
35. Snow, C.P. The Two Cultures: and a Second Look. Cambridge University Press, 1964.
Copyright 1974, Association for Computing Machinery, Inc. General permission to republish, but not for profit, all or part of this material is granted provided that ACM's copyright notice is given and that reference is made to the publication, to its date of issue, and to the fact that reprinting privileges were granted by permission of the Association for Computing Machinery.
|
|
|
Apr 20, 2017 | www.youtube.com
Chad 2 years agoAgent76 1 year ago (edited)"People who believe in these rights very much are forced into compromising their integrity"
I suspect that it's hopelessly unlikely for honest people to complete the Police Academy; somewhere early on the good cops are weeded out and cannot complete training unless they compromise their integrity.
January 9, 2014500 Years of History Shows that Mass Spying Is Always Aimed at Crushing Dissent It's Never to Protect Us From Bad Guys No matter which government conducts mass surveillance, they also do it to crush dissent, and then give a false rationale for why they're doing it.
Homa Monfared 7 months ago
I am wondering how much damage your spying did to the Foreign Countries, I am wondering how you changed regimes around the world, how many refugees you helped to create around the world.
Don Kantner, 2 weeks ago
People are so worried about NSA don't be fooled that private companies are doing the same thing. Plus, the truth is if the NSA wasn't watching any fool with a computer could potentially cause an worldwide economic crisis.
Bettor in Vegas 1 year ago
In communism the people learned quick they were being watched. The reaction was not to go to protest.
Just not be productive and work the system and not listen to their crap. this is all that was required to bring them down. watching people, arresting does not do shit for their cause......
|
|
|
Dec 26, 2016 | it.slashdot.org
(threatpost.com) 148 Posted by EditorDavid on Saturday December 17, 2016 @07:34PM from the does-code-reuse-endanger-secure-software-development dept. msm1267 quotes ThreatPost: The amount of insecure software tied to reused third-party libraries and lingering in applications long after patches have been deployed is staggering. It's a habitual problem perpetuated by developers failing to vet third-party code for vulnerabilities, and some repositories taking a hands-off approach with the code they host. This scenario allows attackers to target one overlooked component flaw used in millions of applications instead of focusing on a single application security vulnerability.The real-world consequences have been demonstrated in the past few years with the Heartbleed vulnerability in OpenSSL , Shellshock in GNU Bash , and a deserialization vulnerability exploited in a recent high-profile attack against the San Francisco Municipal Transportation Agency . These are three instances where developers reuse libraries and frameworks that contain unpatched flaws in production applications... According to security experts, the problem is two-fold. On one hand, developers use reliable code that at a later date is found to have a vulnerability. Second, insecure code is used by a developer who doesn't exercise due diligence on the software libraries used in their project.
That seems like a one-sided take, so I'm curious what Slashdot readers think. Does code reuse endanger secure software development?
|
|
|
Dec 26, 2016 | ask.slashdot.org
(daftcode.pl) 332 Posted by EditorDavid on Sunday November 27, 2016 @11:30PM from the TDD-vs-HDD dept. marekkirejczyk , the VP of Engineering at development shop Daftcode, shares a warning about hype-driven development: Someone reads a blog post, it's trending on Twitter, and we just came back from a conference where there was a great talk about it. Soon after, the team starts using this new shiny technology (or software architecture design paradigm), but instead of going faster (as promised) and building a better product, they get into trouble . They slow down, get demotivated, have problems delivering the next working version to production.
Describing behind-schedule teams that "just need a few more days to sort it all out," he blames all the hype surrounding React.js, microservices, NoSQL, and that " Test-Driven Development Is Dead " blog post by Ruby on Rails creator David Heinemeier Hansson. ("The list goes on and on... The root of all evil seems to be social media.")Does all this sound familiar to any Slashdot readers? Has your team ever succumbed to hype-driven development?
|
|
|
I also hate to offend other people’s sensibilities—given that software methodology has always been akin to religion. With the caveat that there’s no reason anybody should care about the opinions of a computer scientist/mathematician like me regarding software development, let me just say that almost everything I’ve ever heard associated with the term "extreme programming" sounds like exactly the wrong way to go...with one exception. The exception is the idea of working in teams and reading each other’s code. That idea is crucial, and it might even mask out all the terrible aspects of extreme programming that alarm me.
|
|
|
Bad Agile in More Detail
I've outlined, at a very high level, one company's approach to software development that is neither an Agile Methodology, nor a Waterfall cycle, nor yet Cowboy Programming. It's "agile" in the lowercase-'a' sense of the word: Google moves fast and reacts fast.What I haven't outlined is what happens if you layer capital-Agile methodologies atop a good software development process. You might be tempted to think: "well, it can't hurt!" I even had a brief fling with it myself last year.
The short answer is: it hurts. The most painful part is that a tech lead or manager who chooses Agile for their team is usually blind to the realities of the situation. Bad Agile hurts teams in several ways.
First, Bad Agile focuses on dates in the worst possible way: short cycles, quick deliverables, frequent estimates and re-estimates. The cycles can be anywhere from a month (which is probably tolerable) down to a day in the worst cases. It's a nicely idealistic view of the world.
In the real world, every single participant on a project is, as it turns out, a human being. We have up days and down days. Some days you have so much energy you feel you could code for 18 hours straight. Some days you have a ton of energy, but you just don't feel like focusing on coding. Some days you're just exhausted. Everyone has a biological clock and a a biorhythm that they have very little control over, and it's likely to be phase-shifted from the team clock, if the team clock is ticking in days or half-weeks.
Not to mention your personal clock: the events happening outside your work life that occasionally demand your attention during work hours.
None of that matters in Bad Agile. If you're feeling up the day after a big deliverable, you're not going to code like crazy; you're going to pace yourself because you need to make sure you have reserve energy for the next big sprint. This impedance mismatch drives great engineers to mediocrity.
There's also your extracurricular clock: the set of things you want to accomplish in addition to your main project: often important cleanups or other things that will ultimately improve your whole team's productivity. Bad Agile is exceptionally bad at handling this, and usually winds up reserving large blocks of time after big milestones for everyone to catch up on their side-project time, whether they're feeling creative or not. Bad Agile folks keep their eye on the goal, which hurts innovation. Sure, they'll reserve time for everyone to clean up their own code base, but they're not going to be so altruistic as to help anyone else in the company. How can you, when you're effectively operating in a permanent day-for-day slip?
Bad Agile seems for some reason to be embraced by early risers. I think there's some mystical relationship between the personality traits of "wakes up before dawn", "likes static typing but not type inference", "is organized to the point of being anal", "likes team meetings", and "likes Bad Agile". I'm not quite sure what it is, but I see it a lot.
Most engineers are not early risers. I know a team that has to come in for an 8:00am meeting at least once (maybe several times) a week. Then they sit like zombies in front of their email until lunch. Then they go home and take a nap. Then they come in at night and work, but they're bleary-eyed and look perpetually exhausted. When I talk to them, they're usually cheery enough, but they usually don't finish their sentences.
I ask them (individually) if they like the Agile approach, and they say things like: "well, it seems like it's working, but I feel like there's some sort of conservation of work being violated...", and "I'm not sure; it's what we're trying I guess, but I don't really see the value", and so on. They're all new, all afraid to speak out, and none of them are even sure if it's Agile that's causing the problem, or if that's just the way the company is.
That, my friends, is not "agile"; it's a just load of hooey. And it's what you get whenever any manager anywhere decides to be a chump.
|
|
|
Re:Why is it called "Extreme"?
(Score:2) by Eivind Eklund (5161) on Tuesday September 19, @09:38AM (#16137298)
(Last Journal: Friday October 08, @05:53AM) The name comes from introducing some good practices and then doing them extremely ("Turning them up to 11", in the words of Kent Beck).
- "Don't let your programmers be tired" -> "Forbid programmers from working overtime".
- "Do code review" -> "Do code review in real time, by pair programming"
- "Test" -> "Test everything, immedately, by not writing code until you have a failing test"
- "Get customer feedback" -> "Release in very short cycles, and have a customer owner that decide how things should work"
- "Don't overcomplicate the code" -> "Delete all code and functionality we do not need today, and clean up all dirty code immediately"
Eivind.
by Anonymous Coward on Tuesday September 19, @10:17AM (#16137523)
You have some misspellings there... let me correct you:
- "Don't let your programmers be tired" -> "Forbid programmers from working overtime at your own peril as you should realize that a programmer is a real, live adult human being which happens to be a professional and therefore can take care of his own work hours due to the fact that he has been living with himself for quite a few years and knows perfectly well when he's tired and when he's not, and resents being treated like a child by a moronic idiot who just happens to have stepped on enough people to raise up the ladder enough to annoy said programmer".
- "Get customer feedback" -> "Release in very short cycles, and have a customer owner that decide how things should work in your dreams, because in the real world you should realize that your customer doesn't give a s***t about whether you need feedback or not, because he's already told you everything you need in all those prep meetings and impromptu emails, and just wants to sit back and click on the darned button and see things working, so he won't be looking or testing anything you send to him because "it's not done yet" until he thinks "it's done" and then he'll change all those lovely specs you spent some much time tuning the tests to fit into. And your manager will be so desperate to please him that he will say yes to anything he says, because after all, this is Extreme Programming, it's great, it's flexible, we can do anything as long as the tests come out alright, right?"
There, cleaned that up a bit for you.
JARCP
----
Just Another Random Cynic ProgrammerRe:buzzwords(Score:2)
by Ignignot (782335) on Tuesday September 19, @09:06AM (#16137132)
(Last Journal: Thursday October 07, @02:33PM)Seems like a lot of that is just rehashing the same old same old. What's wrong with the programming surgical team described in the mythical man month? Collective ownership seems to be deliberately creating more communication overhead for programmers. In other words, what does XP bring to the table that is useful instead of just different? by seti (74097) on Tuesday September 19, @07:34AM (#16136790)
In my opinion, extreme programming is extremely overrated. Some of the ideas, such as test-driven development (although this concept is not restricted to XP), work well. Others, such as pair programming just do not work in my opinion. Programmersare solo beasts - putting two of these dragons behind one keyboard is asking for trouble.
(Last Journal: Friday July 01, @09:48AM)
Pair programming can be seen as a kind of code review, but with the reviewer in equal position with the programmer. Traditional code reviews tend to be frustrating for the programmers, because the reviewers are in position of authority.Others, such as pair programming just do not work in my opinion. Programmersare solo beasts - putting two of these dragons behind one keyboard is asking for trouble.
But when you put two programmers with equal authority, you have one thinking about the bigger picture and the other reviewing his mind flow. At the same time the later is writing down the ideas in code, with the first one reviewing his code as he types.
Where have you been the last 20 years? The stereotypical programmer, hacking his piece of kernel over night is very endangered species, and rightly so. Like any kind of engineering, software engineering needs as much face to face collaboration as possible.Programmersare solo beasts
(Score:4, Insightful) by Angst Badger (8636) on Tuesday September 19, @08:20AM (#16136934) Pair programming can be seen as a kind of code review, but with the reviewer in equal position with the programmer. Traditional code reviews tend to be frustrating for the programmers, because the reviewers are in position of authority.
I've never seen one of those. Every code review I've participated in has been a collaborative effort between peers. If you treat a code review as a cooperative effort between programmers, it doesn't have to be frustrating.
Like any kind of engineering, software engineering needs as much face to face collaboration as possible.
To a point. But real engineering requires planning and clear interface definitions, and XP -- almost to the point of being pathological -- attempts to avoid planning as much as possible by subsitituting endless chatter and tremendous time wasting repeatedly reimplementing what could have been done right the first time. (And yes, I know some things always have to be reimplemented, but just because mistakes are inevitable doesn't mean they have to be encouraged.)
Software development has an unfortunate tendency towards fanatical adherence to the latest
silver bullet. Usually, this involves an implementation language backed by a marketing push; XP
seems to be the first programming fad built entirely on book publishing. But then, no
implementation language ever actively encouraged the kind of passive-aggressive personality that
thrives on XP.
by g2devi (898503) on Tuesday September 19, @09:01AM (#16137108)> Pair programming can be seen as a kind of code review, but with the reviewer in equal position with the programmer.
It depends on the personalities. It likely works well if you have a uniform team, but it you have a diverse team (which is a good thing since your weeknesses are compensated by someone else's strengths), it can be very suboptimal. For instance, if you put a reflexive analytical introvert with a shoot from the hip intuitive extrovert, the extrovert will more than likely steamroll over most of the input of the introvert and feel validated because the shoot from the hip extovert thinks that the code has the approval of the reflexive analytical programmer.
In the case of a code review, the reflexive analytical introvert gets to do things the way he/she wanted to do and gets input during the review from the extrovert if there are alternate ways of doing things. More than likely, it's also learning experience for the shoot from the hip programmer to program more safely. In the reverse case, the shoot from the hip intuitive extrovert gets to do things the way he/she wants and gets validation that that code is safe and handles all conditions. It's also likely a learning experience for the reflexive introvert to see that "crazy new techniques" can actually be better.
Re:buzzwords (Score:1)
by aadvancedGIR (959466) on Tuesday September 19, @08:09AM (#16136897) Agile software development is simply a way to say "code now, we'll get you the specs later"
|
|
|
Uh-oh (Score:2, Funny)
by jbellis (142590) * <jonathan&carnageblender,com> on Tuesday October 07, @12:32PM (#7154709)
(http://www.carnageblender.com/)That's almost as bad as reviewing a book titled "Linux isn't always the answer."
Absolutely Hopeless and Clueless (Score:3, Insightful)
by mihalis (28146) on Tuesday October 07, @12:35PM (#7154747)
(http://www.mihalis.net/)The Previous Extreme is pure fantasy. It has been well known for a long time that big bang or waterfall models don't work well. For example see the Ian Sommerville Software Engineering book - it's mentioned the 'spiral' model (iterating out from the core of a small well understood system) for at least ten years. I couldn't read any more of this "book review" after such a bunch of nonsense.
Re:Absolutely Hopeless and Clueless (Score:5, Insightful)
by AJWM (19027) on Tuesday October 07, @01:05PM (#7155027)
(http://www.ajwm.net/amayer/)Q: What do you get when you combine the waterfall model with the spiral approach?
A: The flush model.
On a more serious note, the waterfall model does work for certain problem domains, notably those where the requirements are well understood in advance and unlikely to change significantly over the course of development, and where reliability of the final product is critical. This assumes you have the resources (time and people) to do it properly -- and this is why the waterfall method has gotten a bad reputation -- it's been applied where there is insufficient time/resources or the requirements aren't well understood.
Most business applications, for example. The waterfull method is wonderfully suited to something like spacecraft control software, where the spiral approach (we called it "stepwise refinement" twenty-five years ago when I was in college -- there's nothing new) just wouldn't work. But businesses are both constantly changing and adaptable -- a business app that only implements half the requested features is probably still more useful than not, where as software to control complex hardware that's only half done is nearly useless (except that some testing can be done, perhaps).
As always, it's a matter of picking the right tool for the job, rather than picking up your hammer and treating everything as a nail.
XP wouldn't meet DO-178 requirements... (Score:1)
by Svartalf (2997) on Tuesday October 07, @03:08PM (#7156214)
(http://svartalf.freeshell.org/)Which is required for any piece of aviation (including spacecraft) flight control system that is not on an experimental plane.
It doesn't make for the stringent design specification requirements, let alone a few others.
I definitely do NOT want to be flying on a plane or having one fly over my head that doesn't meet the DO-178 certification.
Re:Absolutely Hopeless and Clueless (Score:2)
by hawkestein (41151) on Tuesday October 07, @07:03PM (#7158463)...the spiral approach (we called it "stepwise refinement" twenty-five years ago when I was in college -- there's nothing new)...
The spiral approach and stepwise refinement aren't exactly the same thing, although they are both iterative approaches. As I recall, stepwise refinement is a top-down design technique. You basically start by implementing the top-level of the system, and you put in stubs for the lower level. Then, you gradually work your down the abstraction ladder, implementing the lower level components, until you're all done.
On the other hand, the spiral approach is really all about risk management. At each iteration, you're supposed to identify and address the most significant risks in the project. This doesn't necessarily mean you're using a top-down approach, although it might.
Re:Absolutely Hopeless and Clueless (Score:2)
by AJWM (19027) on Wednesday October 08, @11:33AM (#7164143)
(http://www.ajwm.net/amayer/)Well, top-down programming is just called top-down programming. It's an idea that sounds good in theory, and helps in decomposing problems. However, if you're not careful, at the low levels you end up with a serious mismatch between your design details and the available APIs and libraries.
At each iteration, you're supposed to identify and address the most significant risks in the project.
Most significant risk, or that which gives you the most functionality for a given effort (bang for the buck)? Depends how you define "risk" and "functionality", I suppose.
Re:Absolutely Hopeless and Clueless (Score:1)
by Tablizer (95088) on Tuesday October 07, @08:57PM (#7159212)
(http://www.geocities.com/tablizer | Last Journal: http://slashdot.org/~Tablizer/journal/)On a more serious note, the waterfall model does work for certain problem domains, notably those where the requirements are well understood in advance and unlikely to change significantly over the course of development,
Those are the ones most likely to be outsourced overseas.
Re:Absolutely Hopeless and Clueless (Score:2)
by AJWM (19027) on Wednesday October 08, @11:38AM (#7164229)
(http://www.ajwm.net/amayer/)Those are the ones most likely to be outsourced overseas.
Heh. Good point, at least for commercial apps.
I'll get really nervous when that starts happening for military and aerospace stuff (the sort of thing that's all written in Ada).
A place for everything (Score:3, Interesting)
by DaveAtFraud (460127) on Tuesday October 07, @01:17PM (#7155142)The "waterfall" was great for determining exactly what the user wanted but then ended up delivering it five years later after the requirements had changed.
"Use-case" analysis was great for determining how the user would interact with the system but tended to automate the existing processes instead of figuring out how automation could make the process unnecessary.
OO was great for implementing the non-reusable objects determined to be needed by "use-case" analysis (see previous item).
Too many shops implement XP as an excuse for not understanding the user requirements but just bashing out a bunch of high quality code that solves *the wrong problem* in a short amount of time. This isn't a criticism of XP so much as a criticism of the way it is misused (as has every other innovative software development technique).
The basic problem is and always has been that inventing the future is difficult mainly because the future has a habit of changing while we're busy trying to invent it. No technique other than a time machine will ever solve this problem because it is inherent in the invention process.
Re:A place for everything (Score:1)
by israfil_kamana (262477) <[email protected]> on Wednesday October 08, @10:47AM (#7163524)So what you're saying is that the bottom line is:
(wait for it)
Solid judgement based on experience, and an evaluation of the circumstances of the project at hand?
Wow... coooooool. It only that weren't such a bloody revolutionary idea. Mindless applications of processes and methodologies is bad. Clue? Mindlessness. Creating a quality artifact requires judgement, experience, thoughtfullness, analysis, consultation, colaboration, and estimation. All of these are the products of experience.
I propose a new methodology, which I shall designate the SANE-M. It requires that you start learning, fail a lot, learn from your mistakes, find mentors, learn from them, go off and be extreme and youthful, fail some more, learn some hard practical lessons, then, after about five to ten years, start doing projects with a flexible mind, having exposed yourself to a wide variety of project types, styles, personalities, funding levels, timescales, etc. You are likely to evolve your own project-specific method in colaboration with other experienced participants, and such a project is likely to succeed (if it has all the required ingredients to succeed). A baker who has never made pumpernickle will probably screw it up even if he has a recipe.
Wait! Method re-name. The new name should be "Life" or maybe "Professionalism".
Re:A place for everything (Score:2)
by DaveAtFraud (460127) on Wednesday October 08, @02:09PM (#7165653)Solid judgement based on experience, and an evaluation of the circumstances of the project at hand.
It must be revolutionary otherwise more people would be doing it! Management keeps looking for a way to not have RFC 1925 apply to their particular pet project because, if it does, it will cost too much and take too long. The evangelists for each new methodology always sell it as a "silver bullet" that will circumvent RFC 1925. No one has come up with one yet and my bet is that there isn't one.
Re:Absolutely Hopeless and Clueless (Score:2)
by mihalis (28146) on Wednesday October 08, @01:51PM (#7165511)
(http://www.mihalis.net/)How many systems has written and/or designed Ian Sommerville?. Sure, he may have written books and articles, but, is he anything more than a theorist?. I think this doesn't matter - as I remember, this was backed up with a lot of supporting material in the references, so it wasn't just him and it wasn't just academic sources.
The practical development is very different than the theoretical. Linux kernel is developed in a special flavour of XP, and it works fine, is very modular, scalable,... though it has it flaws. The fact is XP works in a lot of cases.
I'm not saying anything against XP. I'm just saying that the review starts off by saying that the status quo before XP was big-bang/waterfall development model. My response is : no it wasn't!!
Sommerville is just a quotable, checkable source. If you want something from personal experience in industry, I worked on a submarine command system for the UK Royal Navy. This project started in the 80s some time, and was designed in phased releases of working systems with increasing capabilities and performance. Sure it's not XP, but it's not a big bang nor waterfall either.
Re:What the hell are you talking about? (Score:2)
by mihalis (28146) on Wednesday October 08, @02:11PM (#7165668)
(http://www.mihalis.net/)I'm talking about the book review as posted on slashdot. Here is the first bit of it (emphasis mine):
The Previous Extreme - What XP Set out to Fix
It had previously been accepted practice to spend months (years, even, on large-scale projects) gathering requirements, then another year or two on design, before a single line of production code had been written. The infamous "big bang delivery" occurred when this gigantic monolith of a software system was finally delivered to the customer, only for the customer to retort that this was nothing like what he wanted.
It was also accepted practice to divide the system into separate subsystems, and attempt to integrate them after several months. By this time, each subsystem would have taken on a life of its own, and integrating these disparate monoliths together gave a whole new meaning to "plug and pray."
How XP "Fixes" It
These statements about "accepted practice" are factually wrong since at least the mid-80s, probably earlier. XP follows on and improves upon from several, probably dozens of earlier fads all of which attempted to get away from the monolithic system design disasters.
Now, if the reviewer had said "a common mistake is" I wouldn't have had a problem!
Ask Slashdot: Have you used Extreme programming (Score:3, Interesting)
by kilroy_hau (187226) on Tuesday October 07, @12:37PM (#7154766)
(http://pub59.ezboard.com/belforosinnombre | Last Journal: http://slashdot.org/~kilroy_hau/journal/)Well, have you?
I'm about to start a project using pair programming (not exactly Extreme, but something like that) and I don't like it one bit
Pair programming is uncomfortable on our reduced space. And it's noisy.
Are the inconveniences worth it?
Re:Ask Slashdot: Have you used Extreme programming (Score:4, Insightful)
by bokelley (563370) * on Tuesday October 07, @12:46PM (#7154844)I would have to say that pair programming isn't really worth it. I personally can't stand the lack of productivity that is inherent to having two programmers sit around and watch each other type.
My version of pair programming is to have one developer write a test harness while the other one develops the actual code to be tested. This forces each of them to communicate with each other, generally via a very informal spec or direct communication with the client.
This ties two people closely together with the immediate need, but it doesn't require complete overlap. I'm not convinced that two brains are better than one - typing is an inherently blocking process, and whiteboarding happens either way.
Anway, what good hacker wants to watch someone else type? Or play a game? Or do anything? Coding isn't a spectator sport.
Re:Ask Slashdot: Have you used Extreme programming (Score:3, Interesting)
by pong (18266) on Tuesday October 07, @01:02PM (#7155000) (http://slashdot.org/)I think that is an incredibly simple and extremely powerful idea!! Sometimes when you have been programming for a while you just need the mental rest you get from working on your own. I think that the next time I feel like a break while pair programming, I will try to suggest to my pair-programming partner that we split up and one of us focus on the tests while the other is doing the production code.
I think it could be especially useful when you are working on a problem that you are not really sure how to solve. The one person can write a test suite, which is a really good way to work out the most flexible and useful interface, while the developer does some prototyping/sandboxing.
Re:Ask Slashdot: Have you used Extreme programming (Score:3, Insightful)
by bokelley (563370) * on Tuesday October 07, @01:10PM (#7155080)Right. Also, I forgot to mention how incredibly important it is to switch between being the tester and being the coder. If you don't do this then it's too easy for both parties to be lazy, and there's no way to check or enforce the quality of code.
At my current job, I've actually outsourced the implementation of the tests (because we're a very small shop) but I'm making the product manager the only interface with the test developers. This keeps me honest, and has the "nice" side effect of making me document all of my interfaces and APIs since the other developer isn't even in the office.
One benefit of doing this with two programmers on-staff, as I prefer, is that when somebody leaves a project, there shouldn't be a huge drop in knowledge. I left a project a few months ago that was done this way and the remaining programmer, who was quite junior, was able to keep on going without much trouble since she had been exposed to both the testing and development aspects of the project.
Re:Ask Slashdot: Have you used Extreme programming (Score:3, Interesting)
by nullard (541520) <nullprogram.voicesinmyhead@cc> on Tuesday October 07, @02:31PM (#7155832)
(Last Journal: http://slashdot.org/~nullard/journal/)At my current job, we have three developers. We work on projects as a group, on three seperate machines near each other.
The steps we follow:
- We are all involved in project design.
- One of us writes up the requirements.
- The others review it.
- Two of us write the code while the other designs tests.
- The tester tests the system then works with the coders to fix the problems.
- Repeat last step until the bugs are gone and the project is ready for beta
- Beta testers test.
- All three developers work on the final bug fixes
The client approves a demo app after step 3. The client approves the beta version before the testers see it. The client is involved in beta testing.This system seems to work well for us. The 3-way version of pair programming is beneficial to stringent testing. The fact that we use our own machines (but are free to walk over to any of the other developers) lets us parallelize the development project. Since adopting this system at the suggestion of our manager, our turnaround time has dropped dramatically. Aditionally, our code is better before we hit the beta stage. The last project we did had almost no bugs turn up in beta. The constant black box testing durring development followed by white box testing and fixing before the beta ensured that the code was really good before the testers saw it.
Ask Slashdot: Have you used Extreme programming (Score:5, Insightful)
by bunratty (545641) <[email protected]> on Tuesday October 07, @01:10PM (#7155075)The point of pair programming is not to force programmers to communicate with each other. Pair programming is "the knob turned to 10" on code reviews... if code reviews are good, then do them all the time, as a programmer is first writing the code.
If you don't do pair programming, you need to replace it with a less extreme version of code reviews, such as simply reviewing each patch before it is checked in. The type of pair programming you describe involves no code reviews, and therefore is no substitute for pair programming.
Re:Ask Slashdot: Have you used Extreme programming (Score:2, Interesting)
by bokelley (563370) * on Tuesday October 07, @01:14PM (#7155110)That is a good point. I forgot to mention the other important part of this, which is that people switch roles often on the same component. This is my version of turning the dial up to 10. If you think about it, the point of a code review is to make sure that code is clean and legible (and more or less efficient) so that maintenance is easier. What better way to do this than force people to modify each others' code on a regular basis?
Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by daecabhir (166667) on Wednesday October 08, @08:31AM (#7162093)There is another advantage to the process that you have described... it is easier to implement for teams that for a variety of reasons cannot work physically together. However, by rotating the responsibility for the test harness and the coding of the application, it would appear that you do get a fair amount of benefit. Thanks for the insight!
Two idiots don't make a genius (Score:2)
by Ars-Fartsica (166957) on Tuesday October 07, @01:51PM (#7155480)
(Last Journal: http://slashdot.org/~Ars-Fartsica/journal/)Pair programming attempts to take two mediocore programmers and create one decent programmer out of them. No senior developer is going to put up with some malodorous jerk sitting on his lap asking questions about every line.
Two idiots make a nice pair of twits (Score:1)
by Demodian (658895) on Tuesday October 07, @03:00PM (#7156125)Unfortunately, two mediocre programmers yield nothing but crap code. For pair programming to work well, the two would have to be very balanced with regards to each other's performance, or else there will be more work done by one or the other.
No "sane" senior developer is going to let a junior programmer coast along on the same coding task without doing his/her fair portion of the work. I find that it to be a waste of time to have someone standing there watching me code unless I am intentionally trying to demonstrate or teach. (Especially the boss!)
Besides, the parrot should sit on its own perch...
Re:Two idiots don't make a genius (Score:3, Insightful)
by royalblue_tom (557302) on Tuesday October 07, @03:16PM (#7156308)Nope, pair programming takes two hackers and attempts to turn them into one disciplined programmer.
Perhaps this way, the code will be commented, have tidy layout, and be readable. Meaningful (to more than one person) variable names might be used. Boundary checking done. Good test cases written, and used. Other programmers may be able to work on this code at a latter date. The code may do what was specified (for this particular task) as the one programmer keeps the other one focussed on the job in hand.
If the developer is *that* senior, he should be capable of explaining what he is doing to the lesser minds in the company. Treat it as a mentor slot. And of course, that's only for 50% - the other half of the time is watching the other guy, advising, perhaps teaching, and guiding.
The question the developer should ask himself, "Is he really a malodorous jerk, or am I so socially inept that I am unable to work with people who may not be as skilled as I am?".
Re:Two idiots don't make a genius (Score:2)
by tshak (173364) on Tuesday October 07, @04:25PM (#7157043)
(http://slashdot.org/~tshak/)Nope, pair programming takes two hackers and attempts to turn them into one disciplined programmer.
Perhaps this way, the code will be commented, have tidy layout, and be readable. Meaningful (to more than one person) variable names might be used...
It's called having people in charge of managing your code. A good software manager will dictate certain code rules, layout guidlines, etc. If I try to check in a bunch of hacked code with crazy variable names and crappy or no comments, it'll get rejected and it'll never make it to the main source tree. If I do this often enough I'm off the project, and eventually out of a job. There's no reason a $50K - $100K+ software developer should need someone watching over their shoulder to do a good job.
Re:Two idiots don't make a genius (Score:2)
by tigga (559880) on Tuesday October 07, @04:46PM (#7157299)Nope, pair programming takes two hackers and attempts to turn them into one disciplined programmer.
That's exactly the same as two mediocre programmers equal one decent
;)) Perhaps this way, the code will be commented blah blah blah
Perhaps you don't need to pay to second programmer to do this - you just need a secretary for each programmer..
Two Hackers doesn't make an omelet (Score:2)
by arth1 (260657) on Tuesday October 07, @08:59PM (#7159235)
(http://2130706433/)Nope, pair programming takes two hackers and attempts to turn them into one disciplined programmer.
That's as futile as trying to create a diciplined heavy metal band or porn star. It defeats the whole purpose of having a Hacker in the first place.The correct way to use two Hackers is to appeal to their ego. Have both code the same piece concurrently, and let the best code win. That way, you both ensure that the coders do their very best, and you also get alternative backup code BEFORE a problem is reported, which is invaluable in troubleshooting. Program crashes with both pieces of unrelated code? Chances are the problem is elsewhere, or with the specs.
Oh, and you can use this competitiveness to your advantage with QA too -- encourage the coders to find problems with each other's code. If possible, keep the programmers from even seeing each other (it's easier to slam the code of someone you've never met), and don't penalise the coder who creates bugs, but reward the finder instead.
THAT's extreme programming. EP, for people who can both code and spell.
Regards,
--
*ArtRe:Two Hackers doesn't make an omelet (Score:2)
by royalblue_tom (557302) on Thursday October 09, @01:27PM (#7174830)You weren't planning on working with one of these hackers again were you - as he'll hate you for not choosing his "brilliant" code over the other hackers. Why do I get the feeling that I will get two programs, neither readable by my other programmers, uncommented or documented (I had to get it done quicker than the other guy), and the bugs will be nasty and obscure.
I used "hacker" in my post to mean someone who churns out code, without worrying about the niceties of software engineering. Someone who is likely to think that having uncommented and undocumented code is a good thing, as it keeps him hired. For every dedicated "coding standard" programmer, you'll find a legion of these "hackers" who feel that their code is self commenting, self documenting, and its obvious what it does. They don't need to follow the company standard for indenting or variable/method naming because they use their own "better" method. But their code is just a full of bugs as everyone else's, and more difficult to maintain.
Pair them up. Let their egos shame each other into writing one "decent" piece of code, rather than two hacked pieces of indicipherable cack. The software industry is a team game these days. Programers need to learn to work together - both in the way they interact with others, and how they write code.
And hey, most heavy metal bands are very diciplined in their performance - and they match their performance to that of the other players in the band, working together to perform a single piece of music.
Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by rowanxmas (569908) on Tuesday October 07, @03:14PM (#7156292)Why isn't the knob turned to "11" ?
And no, its not your dial that's wrong.
Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by blakestah (91866) on Tuesday October 07, @03:19PM (#7156338)
(http://www.keck.ucsf.edu/~dblake)Programming is inherently a solo act. Pair programming is not only less efficient, it is 4 times less efficient. Every time you interrupt a programmer's train of thought you are losing time more certainly than when he picks up his Coke for a drink. XP pair programming is an incredibly stupid idea, which is why no one NOT ASSOCIATED with XP ever gives it a positive third party review. If you try it, well, sorry to hear that, but if you try it, you will NEVER want to pair program again.
Also, refactoring can be good, but it takes a lot of time and effort to make code cleanly work, and that effort is usually duplicated when you re-factor. The cost in time is HUGE, and it should not be taken lightly.
Re:Ask Slashdot: Have you used Extreme programming (Score:2, Insightful)
by iroberts (672505) on Tuesday October 07, @06:15PM (#7158115)Pair programming is not only less efficient, it is 4 times less efficient. Every time you interrupt a programmer's train of thought you are losing time more certainly than when he picks up his Coke for a drink.
I've done some pair programming, and I have to disagree here. It's true that the "passenger" will interupt the "driver", but it will not necessarily interrupt the train of thought. Indeed, frequently comments will be along the lines of "why not just do instead?". Moreover, the "passenger" can often help keep track of the big picture, allowing the "driver" to focus on details without getting lost.
This is not to say that pair programming is perfect. For certain drudge work, it's definitely not efficient. Even with two coders who respect each other and get along well, it can be very emotionally draining. But I've almost never felt that my pairing partner and I could have developed *and debugged* code more efficiently by working separately. Indeed, we tended to write remarkably bug-free code when we had a "second pair of eyes".
One thing that I think is necessary for pair programming to work well - both developers need to be as "egoless" as possible. Only when each person can truly listen to and fairly evaluate the others comments while in "the heat of battle" will pair programming work well.
Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by William Tanksley (1752) on Tuesday October 07, @06:47PM (#7158364)
(http://dolphin.openprojects.net/Omega)4 times? Cite your source, please. The rest of that paragraph seems equally unlikely (I've seen positive reviews of PP, including one positive study), but I'll let that float until I get a backup to that number.
Also, refactoring can be good, but it takes a lot of time and effort to make code cleanly work, and that effort is usually duplicated when you re-factor. The cost in time is HUGE, and it should not be taken lightly.
You're confusing refactoring with rewriting, aren't you?
-Billy
Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by blakestah (91866) on Tuesday October 07, @11:41PM (#7160300)
(http://www.keck.ucsf.edu/~dblake)4 times? Cite your source, please.
Just devel times at one site, depending on whether the programmers were paired or not. The pair takes twice as long as a single programmer, which is four times the man hours.
Maybe for debugging it is a smarter idea, but I doubt it.
You're confusing refactoring with rewriting, aren't you?
No, I've had to refactor before. But when only one of the pair thinks a refactor is necessary, a warning bell oughta ring.
Deafening (Score:1)
by CarlBenda (645559) on Tuesday October 07, @10:10PM (#7159775)Having "the knob turned to 10" gives you a sense of what pair programming is like. After a week or so at 10 you can't hear much and so it goes with code reviewing. Watching someone type is one of the most boring things to do after watching grass grow. After a while you lose focus and start to drift off. I've seen it plenty of times with multiple partners. In some cases simple coding gets so boring both the person doing the coding and the person checking fall off. Switching between typing and watching only helps a little. Switching partners help a little also. At the end of the day though you start hating programming. That's life at 10.
Re: Pair programming at 10 (Score:1)
by mfnickster (182520) on Tuesday October 07, @11:40PM (#7160292)
(http://profiles.yahoo.com/mfnickster)It comes down to doing it in the most reasonable manner for any pair of programmers. Sometimes you can work in tandem, other times you need long breaks from the other guy.
You don't necessarily have to have one programmer literally looking over the other's shoulder-- in my experience, it's more natural and makes more sense to discuss the problem with the other programmer, work separately for a while and then meet again to go over the results.
In one case, another programmer (senior to me) was describing how he was getting stock quote information over the wire and handling the fractions using floating-point calcs. He didn't like the implementation or the performance very much, and while he was telling me this, his phone rang.
While he was on the phone, I looked over his code and a few minutes later when he hung up, I handed him an integer version. By working on the problem alternately, we came up with a better solution (and the senior put in a good word for me with the boss, saying I had "a good eye for optimization)."
It all depends on what you're used to and what you're willing to try as a fresh approach.
Re: Pair programming at 10 (Score:1)
by CarlBenda (645559) on Tuesday October 07, @11:54PM (#7160353)Sounds great to me. This just happens to not be pair programming and XP. You don't work separately for a while because if you do that the other person isn't checking your code. If they aren't checking your code you need QA. If you need QA then why are you wasting another programmer's time. Etc, etc, etc. I find plenty of things in XP that I like and have used for years well before the word XP came out. The problem with XP is it decided to make these things ridged and cranked up to 10. Some thing that was good in moderation has been made into an ugly way to manage software development. Hopefully pair programming doesn't keep the bad connotation that XP is giving it.
Re: Pair programming at 10 (Score:1)
by mfnickster (182520) on Wednesday October 08, @12:11AM (#7160431)
(http://profiles.yahoo.com/mfnickster)I have to admit that I've never tried XP (I worked as a programmer before it came along), and I've only read a little about it. You're right, my example is not XP (I didn't mean to imply that it was), but it is pair programming of a different kind.
Two programmers, working on the same problem, in the same capacity-- the essential point being that the code passes both sets of eyes before it goes out. In our case, it didn't have to be checked every 5 seconds; every 5-15 minutes was sufficient.
The principle is the same, but tuned to accommodate our working style.
Re: Pair programming at 10 (Score:1)
by CarlBenda (645559) on Wednesday October 08, @07:06AM (#7161681)Don't get me wrong either. Pair programming has for me been some of the best times of my life. Working with someone I respect and getting near instant feedback after I've done something was great. It's just not what XP advocates. Doing it all the time with everyone leads to more problems than it solves.
I don't think the principle is the same with regards to XP pair programming and what you describe. You don't check after 5-15 minutes in XP. The person pairing with you is suppose to watch all the time looking for errors. There is one keyboard. One computer. There is pretty well nothing else to do for one person in the pair except to look over the other person's code. The principle in XP is constant vigilance. Looking the other way for 15 minutes allows your partner to run amok.
:-) I think you are developing an agile style. I like agile methods. You are not doing XP.
An analogy with XP would be drinking red wine. Red wine is good for you. XP would say dial that up to 10 and drink a few bottles a day. XP drops the context that some things work well in restricted situations and just says you should do it all the time with everyone.
Imagine working with someone in your group that you don't really like and whose code while "right" doesn't look too good to you. Go ahead and pair program with them. If you are lucky maybe you'll change your opinion about them. If you aren't tough luck under XP. Now do the same with someone you do like. With luck you'll still like them at the end of the day. Some times people aren't compatible but can work together. With XP you aren't really suppose to pick and chose. If you do you lose out on spreading the code knowledge.
Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by ebh (116526) * <mailto:[email protected]%20minus%20language> on Wednesday October 08, @08:34AM (#7162128)
(Last Journal: http://slashdot.org/~ebh/journal/)Pair programming is "the knob turned to 10" on code reviews.
As a sound technician, I know that turning the knob to 10 isn't necessarily what you want. Take an ugly sound and turn it to 10 and you now have an ugly, loud and distorted sound.
As a kernel programmer (being a good instance of a system where no one person can know everything), I know that the best code reviews are done by teams of engineers who look at the code from different points of view.
In addition to people who can easily find common coding errors, you also want people who can spot locking and semaphore problems, backwards-compatibility breakage, subtle interactions with other subsystems, use of deprecated interfaces, etc.
If I'm a file system programmer paired up with another file system programmer (because we're doing file system work), then we're liable to have a lot of the same blind spots, so there are whole classes of bugs that can leak through.
"Thank you for finding that off-by-one error. Now I know that the spinlock I'm holding forever is the correct one."
Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by chromatic (9471) on Tuesday October 07, @01:14PM (#7155103)
(http://wgz.org/chromatic/)I would have to say that pair programming isn't really worth it. I personally can't stand the lack of productivity that is inherent to having two programmers sit around and watch each other type.Non sequitur. Your first sentence talks about pair programming. Your second sentence talks about something that is almost entirely unlike pair programming.
Pair programming is "Hey, let's talk about this problem and write some code as we're going along!", not "Hey, sit behind me and shut up unless I make a typo!" If someone's made you do the latter and called it "pair programming", he was quite wrong.
Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by bokelley (563370) * on Tuesday October 07, @01:20PM (#7155184)There are definitely situations where that works, and I have had good experiences with that. However, I would separate out "pair designing" and "pair debugging" from "pair programming".
When I run into a problem, it's always nice to discuss it with someone. I like that. I don't need to be forced to "pair program" to have these conversations. Similarly I don't need to "pair program" to help other people solve their problems, often interactively. What I don't like about pair programming as a methodology is that it hides incompetent programmers, reduces the learning that comes from failing at a certain approach, and discourages leaps of faith.
Re:Ask Slashdot: Have you used Extreme programming (Score:2, Insightful)
by chromatic (9471) on Tuesday October 07, @01:30PM (#7155284)
(http://wgz.org/chromatic/)What I don't like about pair programming as a methodology is that it hides incompetent programmers, reduces the learning that comes from failing at a certain approach, and discourages leaps of faith.I'm not sure I follow your reasoning.
How does pair programming hide incompetent programmers? If you're switching pairs often, everyone will have the chance to work with everyone else.
Do you prefer a learning style that requires everyone to make the same mistakes? In my teams, I prefer not to make mistakes at all. In practice, I'll settle for making a mistake once then letting everyone know what it was and how to avoid it. Given experienced programmers, it's pretty handy to start down a path and have your pairing partner say, "Wait... we did something like this before. Here's how we solved it then."
I don't know what you mean by "discourages leaps of faith" at all. That sounds like a positive thing to me. I'd rather go by the empericism of the test suite than mystical intuition that can't be verified. XP's pretty firmly in the realm of "solving the customer's actual problems" than any Kierkegaardian philosophy.
Admittedly, I'm a fan of pair programming. I've used it on a couple of projects and plan to use it on several more in the future.
Re:Ask Slashdot: Have you used Extreme programming (Score:3, Insightful)
by Cederic (9623) <mailto:slashdot@UglyFatGu[%20]rg%20['y.o'%20in%20gap]> on Tuesday October 07, @03:35PM (#7156507)>> it hides incompetent programmers
Actually, it exposes them quicker, as their incompetence becomes immediately apparent to their partner.
Further, it gives the partner an opportunity to improve them and reduce their incompetence.
If that doesn't work, then they're hopelessly incompetent, and you're no worse off than had you not programmed (and indeed, much better than if you'd found out 8 months into development when you did your first code review)
>> reduces the learning that comes from failing at a certain approach
Actually, it increases the learning - that learning is spread around the whole team in short order. The team learn collectively from their failures, instead of each individual having to make them all in turn.
>> and discourages leaps of faith.
I'm not sure what you're getting at here. I have been sat with a partner while he's said "go with me on this one for ten minutes, I want to try something". I shut up, I watch, I learn, I see how he's intuitively solved a problem or implemented a mechanism and saved a ton of work.
Or I've been driving, and I've asked my partner, "I know we should methodically trace through this bug, but I reckon I can find it by guesswork - gimme a couple of minutes to have a go". Two minutes later, bug fixed, several hours of painful tracing averted.
It's about building good communication within the pair, in having faith in each others abilities. What you've been describing is not pair programming.
~Cederic
Re:Ask Slashdot: Have you used Extreme programming (Score:3, Funny)
by Nept (21497) on Tuesday October 07, @01:31PM (#7155287)
(Last Journal: http://slashdot.org/~Nept/journal/)except if one programmer doesn't like slashdot, it will make the other more productive...
Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by bmj (230572) on Tuesday October 07, @01:34PM (#7155328)
(http://anklebiter.net/)I would have to say that pair programming isn't really worth it.
It's certainly not worth it all the time, but there are times when it can boost productivity. Let me first say I've never worked in a pure XP environment, but on several projects we've cut & pasted from XP and used what works well for us.
Pair programming can work well when you're still developing the logic that will drive the application. Why? Because at that point, you're not coding for 8 hours straight. You're coding a bit, running some tests, then tweaking. If you work well with your partner, you've constantly got a sounding board for ideas, and chances are, you'll crack the egg sooner rather than later. Sure, you could both work on the same problem space separately and compare notes at the end of the day, but I think had you been working together, the problem would have been solved much sooner.
Although it's not a pure XP situation, pair programming works quite well when you've been handed someone's else code. While working on a particular project, my group was handed code from the client for a sub-project that they had completed, but were unhappy with (they were not a development shop by trade), so suddenly we were responsible for righting the wrongs. It was VB app (and we were doing web development for them, and we weren't VB specialists), and we gave them a fairly conservative time estimate. The manager wasn't particularly happy to see us working in pairs (didn't seem productive) but we got the sub-project completed well under budget.
My version of pair programming is to have one developer write a test harness while the other one develops the actual code to be tested. This forces each of them to communicate with each other, generally via a very informal spec or direct communication with the client.
I like that idea.
Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by stew1 (40578) on Tuesday October 07, @04:00PM (#7156789)
(http://www.alacpp.org/ | Last Journal: http://slashdot.org/~stew1/journal/)What you describe isn't [good] pair programming.
When you're *really* doing pair programming, you and your partner are talking constantly and shoving/grabbing the keyboard back and forth between each other. Most programmers are familiar with "flow" or "the zone" or "hack mode" -- alive in the code and dead to the world. When two people are in "pair-flow", the results are astonishing. It takes a lot of work and management to get two people to that level of intellectual comfort, but it's worth it. I'm not doing pair-programming currently, and I miss being able to plug my brain into my former colleagues'. Achieving pair flow makes up for any lost productivity inherent in halving the number of things a team is working on (and there are actual university studies which show that pair programming makes up for initial productivity hits in the long run, due to a lower bug rate).
One problem with pair programming is that it's intellectually and emotionally exhausting, especially for your average introverted programmer. One of the places where XP needs to be refactored is in giving coders a chance to rest and recuperate while still on the job. The Sustainable Pace practice counteracts this to a certain extent, but not fully, in my experience.
The other poster is wrong when s/he claims that pair programming isn't about increasing communication. In fact, that's one of the largest benefits. Fred Brooks showed that communication overhead is indeed the essential problem of team programming. Pair programming lets you skirt around Brooks' Law, in certain situations.
Jon
Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by JohnwheeleR (662355) on Tuesday October 07, @05:09PM (#7157560)XP was developed because consultant programmers found requirements change frequently regardless of the solidity of upfront design schematics. Why? Hell if I know. Maybe it's because programming is a new disipline. Maybe it's because clients can't forsee all they want without interacting with something. I don't know. I do know that working months on something, showing it to a client, and them hating it sucks (especially when it meets the requirements you worked out with them). It sucks to go for months after deployment adding new features and refining others. It is painful, leaves the codebase in a convoluted state, and makes programmers and clients resentful of one another.
XPs principles make it easier to cope with changes. It doesn't completely throw out the notion of an upfront design; however, it stresses we constantly improve the design while we code (design and implementation are concurrent activities). That's why pair programming makes sense to me. Group dynamics and synergy maximize the quality of a design.
Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by CrazyWingman (683127) on Tuesday October 07, @05:17PM (#7157640)
(Last Journal: http://slashdot.org/~CrazyWingman/journal/)Actually, yes, pair programming does have its place. I'm writing a compiler right now with a couple of teammates for a class, and there are just certain parts where it REALLY helps to have someone looking over your shoulder. I mean, when your writing regexp's for a scanner it's REALLY easy to mess something up, and can be rather difficult to find it.
I won't argue that it definitely takes some getting used to. I, like everyone else, am someone who would rather go off and code on my own and then review the code later. I don't like having someone say "hey, you forgot a semicolon there" right after I hit enter. Chances are I realized it too, and will be hitting backspace in the next half second to correct it anyway. But, this is something that a pair has to work out. There is work to be done getting used to both the typer and the watcher positions.Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by bokelley (563370) * on Tuesday October 07, @05:35PM (#7157782)
I can totally see that - makes a lot of sense. I guess my point is that if you're not doing intricate develoment, then it's a waste of time.
Re:Ask Slashdot: Have you used Extreme programming (Score:3, Insightful)
by sbrown123 (229895) on Tuesday October 07, @12:47PM (#7154856)
(http://slashdot.org/)Yes, its worth it. Take two programmers: one more skilled then the other. Give the less skilled one the keyboard. Force the skilled guy/girl to have to communicate all typing through the less skilled guy/girl. Less skilled guy/girl not only gets a good understanding of what went into the code (they typed it) but also learns new things from the smarty. Eventually you have two smarties. Repeat.
Who hates the idea of pair programming? Smarties ofcourse. They dont want to lose what they feel makes them special. They are bad for business anyways.
Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by Horny Smurf (590916) on Tuesday October 07, @12:54PM (#7154909)
(Last Journal: http://slashdot.org/~Horny%20Smurf/journal/)smarties aren't smarties because they write good code. They write good code because they're smarties.
I think Brookes (Mythical Man Month) claimed a 50 x difference between the best programmers and mediocre programmers. Do you really think having joe superprogrammer dictate code to joe retard is going to help joe retard's skills?
I think you should take a refresher course in economics. Focus on the "division of labor" part.Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by Theodrake (90052) on Tuesday October 07, @01:20PM (#7155188)The problem is we need to get rid of those mediocre programmers. But too many government projects depend on body count to get a profit. To many managers depend on having large staffs to get promoted. Until the U.S. government will let a company charge a 40 - 50% markup and use 1/5 the staff on a project it ain't gonna happen.
Re:Ask Slashdot: Have you used Extreme programming (Score:3, Insightful)
by Don Calamari (144891) <thedon AT doncalamari DOT com> on Tuesday October 07, @01:03PM (#7155006)
(http://doncalamari.com/)How true. Everybody knows the most profitable companies are run by drooling troglodytes. I'm just kidding, I'm sure you mean the prima donnas who nobody can stand...
Anyway, I've found you simply cannot get 2 good coders by shackling one good and one poor coder together. The bad one generally doesn't learn anything and the good one just gets frustrated and angry.
Pair programming might work if the poor coder had a desire to learn, but it's been my experience that this usually isn't true. Learning to be a good coder does not happen by proximity and osmosis.
It's all about *which* two coders you have... (Score:2)
by Anonymous Brave Guy (457657) on Wednesday October 08, @07:04AM (#7161675)Learning to be a good coder does not happen by proximity and osmosis.Perhaps not, but it does happen when you take someone with potential and a willingness to learn, and then apply proximity to skill and experience and let osmosis do its work.
Not every junior programmer wants to make that effort, but plenty do. A smart company will employ such people and train them properly: it's a much cheaper way of getting good results, it raises the standards across the industry by supporting the new starters who will be the senior programmers of tomorrow, and it gives both an incentive and a watch on the veterans to make sure they keep sharp. Basically, everybody wins.
Sure, if you hire monkeys this will never get them anywhere and will just be a drain on the senior guys. But that's true of any methodology you use. The moral of the story is to hire people with enthusiasm for their field and a desire to learn, and not the monkeys. If they cost a bit more, pay it; compared to the benefits to a development team, the modest rise in remuneration and occasional perks it will take to make your place stand out from the crowd are nothing.
(I should say here that I don't advocate "pure" pair programming. I do, however, believe in senior programmers being heavily involved in supporting the junior guys by various means, including variations on the pair programming theme.)
Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by geoffspear (692508) on Tuesday October 07, @01:10PM (#7155073)
(http://www.geoffreyspear.com/)Wouldn't it be better for a project to get rid of the bad programmers and let them go off and learn how to code for themselves, instead of having a good programmer dictate code to them?
Most people, I think, can type their own code a lot more efficiently then they can dictate code to someone else. Unless they learned to code using some sort of voice recognition system instead of a keyboard.
Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by Bigbaz (678814) on Tuesday October 07, @01:14PM (#7155107)We've been using a modified XP process at work for a little over 2 years now, and I've got to agree with you on the benefits of pair programming. It is difficult at first to give up control of the keyboard, and at first I felt a little strange telling someone else how they should do something. Generally, I'm a hands on kind of guy, I would rather just do something myself than have to explain to someone else why they should do it and how to do it.
That said, I have really come around, and now I love pair programming. The newer people in our group get to learn from us, and we get to make sure they learn our way of doing things. We also learn from them, when they bring new ideas and methodologies and such. Plus, when we do our designs, we've got two sets of eyes making sure everything is covered, and to make sure we adhere to our design. And we know the code is good, because we've got two developers looking at it all the time.
Not to say it's a perfect world, of course. We still have conflicts and disagreements and all that, and scheduling time to work with a partner is difficult when everyone is so busy, but we get it done, and I believe the product is superior to what we put out before.
No development process will be a perfect fit in every organization and situation, just like no stock $OPERATING_SYSTEM distribution will suffice for every application. You try it, you learn what needs to be changed, and you change it. Then you keep changing it as you go along.
Re:Ask Slashdot: Have you used Extreme programming (Score:5, Insightful)
by AJWM (19027) on Tuesday October 07, @01:18PM (#7155155)
(http://www.ajwm.net/amayer/)Who hates the idea of pair programming? Smarties of course. They don't want to lose what they feel makes them special.
More likely they're just driven insane by having to wait on the other person. Depends on how bad an impedence mismatch you have. Programmer productivity can vary by an order of magnitude or more between individuals (so called "superprogrammers", although the term is silly). If you have one of the latter, no amount of "skill transference" is going to bring the former up to the same speed, any more than teaming someone with an IQ of 150 with someone with an IQ of 110 is going to raise the latter's IQ to 130. (It might, through frustration, lower the former's though
;-) On the other hand, if you're just talking about a couple of average programmers, one of whom has a couple of years more experience, then yeah, it makes sense.
They are bad for business anyways.
Depends. Nobody needs prima donnas, of course (well, except ballet companies, I suppose
;-) but do you just want a stable of predictable but average programmers, or do you want to hold on to those "smarties" who, in a pinch, can deliver good code faster than any eight other programmers put together? (Of course, you may not have the choice. Superprogrammers aren't nearly as prevalent as the number of average programmers who think they're "super" would indicate
;-)
Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by WotanKhan (150429) on Tuesday October 07, @02:07PM (#7155631)
(http://www.offlinetshirts.com/)More likely they're just driven insane by having to wait on the other person
Exactly. If skill transfer is the goal, there are much more efficient ways of going about it. Personally, I am a blindingly fast typist, and I do my best developing in sort of a flow state where I am coding nonsequentially and moving around within the environment with the agility of a video game. I don't see achieving this in a pairs environment.
On the flip side, I learn best by starting with a well designed, fully realized and functional product, cloning it and modifying it to do something else. Some explanation and documentation from the developer is always great, but there is nothing like reading good code. Trying to communicate code via speech is just a recipe for frustration, not efficient learning.
Oh Yeah? (Score:2)
by blunte (183182) on Tuesday October 07, @04:11PM (#7156912)Nobody needs prima donnas, of course (well, except ballet companies, I suppose
;-) Not this prima donna [foxnews.com]
Sorry, OT, couldn't help myself
:) Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by CarlBenda (645559) on Tuesday October 07, @10:15PM (#7159810)I pair programmed with a kid who got a math degree from Caltech and spoke three languages. Definitely very smart. Context though is everything. Smart at what? This kid couldn't program worth shit. He smelled which made things worse to pair with him. After a while I got off on telling this "smart" guy we needed another test. He fell for it all the time and our productivity with it. I consider myself a good programmer. You don't have to be "smart" to realize a dumb move. The "smart" guys are the ones who will stick with a stupid move no matter what.
Give me five people who program well and have code reviews. You'll get tons of code out of a well working team because producing code that's good makes them feel special.
Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by AJWM (19027) on Wednesday October 08, @11:51AM (#7164486)
(http://www.ajwm.net/amayer/)Interesting anecdote, but your point was...?
You'll get tons of code out of a well working team
Sure, that's well documented in studies of software engineering economics. So is the fact that in a field like programming, there can be an order of magnitude difference in productivity between two individuals. If you have people like that, you're better off organizing the team like Mills' "Chief Programmer Teams" (what Brooks calls "Surgical Teams").
I don't think anyone has investigated whether that difference correlates with being a smelly polyglot mathematician in either a positive or negative sense. I rather suspect it doesn't correlate at all. My guess, though, is that high IQ helps, but is not the sole predictor. (I know plenty of high IQ people that can't program their way out of a paper bag, so to speak.)
Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by Paradise Pete (33184) <[email protected]> on Tuesday October 07, @01:20PM (#7155178)
(Last Journal: http://slashdot.org/~Paradise%20Pete/journal/)Eventually you have two smarties. Repeat.
They are bad for business anyways.So then your business process produces things that are bad for business?
Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by pgrdsl (713039) on Tuesday October 07, @01:45PM (#7155417)The best pair programming occurs when you have two equally skilled people whose skill sets overlap but aren't the same.
The worst is when one of the pair is a chimpanzee and the other is expert: you end up with a confused chimpanzee and a suicidal expert. Oh, and no code.
I find pairing works for short stretches, followed by periods where the members of the pair can wander off, do a bit of solo coding/thinking/design, and then join up again when appropriate.
Successful pairing is not a student-teacher relationship - it is best when it is a joining of equals. If you want "teaching", send them on a course.
Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by TrekCycling (468080) on Tuesday October 07, @03:20PM (#7156350)Nevermind the fact that you often have people (usally the smartie, in my experience) who think their way of typing, running the IDE, the keyboard, etc. is the ONLY way and that any lack of efficiency is terrible and you can develop a REALLY bad programming environment. I've been on the other end of that. A perfectly competent programmer with some amped-up developer behind me who can't stand the slight inefficiencies in the way I operate the computer (not talking about actual code, but I don't use keyboard shortcuts enough or multi-task quite well enough). That can be very stressful and... frankly... silly.
Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by doinky (633328) on Tuesday October 07, @03:45PM (#7156629)Fabulous. So now our profession is nothing more than short-order fry cook. No possibility of turning on the headphones and going into the zone. No chance of browsing the web for new and interesting por^H^H^Hstuff.
Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by dubl-u (51156) * <mailto:0301310758@p%20o%20t%20a%20.%20to> on Tuesday October 07, @04:49PM (#7157348)
(http://pota.to/)Give the less skilled one the keyboard. Force the skilled guy/girl to have to communicate all typing through the less skilled guy/girl.
This happens some in pair programming, but it's not the only way to do things. I'd say I spend maybe 5% of my pairing time dictating something. More common is when the person who knows whats going on seizes the keyboard and says, "Let me show you what I mean."
My general rule of thumb is that they keyboard should change hands every 10 minutes or so. Otherwise it's too easy for the driver to forget about the navigator, or for the navigator to zone out.
Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by adamruck (638131) on Tuesday October 07, @01:30PM (#7155282)You are wrong, sorry. Programming in pairs is fundamentally better then programming alone. My computer science teacher once showed our class a movie clip of a basketball team practicing, he told us to count the number of times they dribbled the ball. We all did our best to count. When the movie was done he asked us if we noticed anything odd. We all said no. He played back the tape, turned out a big fuzzy bear maskot walked through the court. None of us noticed becuase we were all so focused on the counting. The partner catches the bear becuase when you work with partners you dont work on the exact same block of code. If you have a good partner you can accomplish some amazing coding.
I dont know about that whole learn through pair programming thing though. Sounds sketchy to me.
Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by richieb (3277) <`rbielak' `at' `acm.org'> on Tuesday October 07, @02:31PM (#7155826)
(http://www.netlabs.net/~richieb | Last Journal: http://slashdot.org/~richieb/journal/)I'll tell you - people. no-one wants someone looking over their shoulder, you even want your guru to just sod off for a bit and let you try stuff out yourself.
Wait until you have to write some that has to be 100% solid when it's installed at your biggest customer site. Then you will want about 5 people looking over your shoulder checking what your write.
The other plus to pair programming is that there is another person that really knows the code, so you can take long lunches and vacations.
Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by doinky (633328) on Tuesday October 07, @03:48PM (#7156668)If pair programming becomes required; don't we both have to take our long lunches and vacations at the same time?
Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by richieb (3277) <`rbielak' `at' `acm.org'> on Tuesday October 07, @04:54PM (#7157404)
(http://www.netlabs.net/~richieb | Last Journal: http://slashdot.org/~richieb/journal/)I think XP programmers are promiscous, so they can pair with more than one partner. Hmm..... this gets worse and worse...
Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by tcopeland (32225) * <tom AT infoether DOT com> on Tuesday October 07, @12:52PM (#7154886)
(http://tomcopeland.home.mindspring.com/)> Pair programming is uncomfortable on our
> reduced space.Sounds like someone needs to provide your team with pair programming-friendly space. A wide desk is a start.
> And it's noisy.
What's noisy? The space you're in? The other people? The person you're pairing with?
> Are the inconveniences worth it?
Those inconveniences aren't intrinsic to pair programming. Don't give up yet...
Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by kilroy_hau (187226) on Tuesday October 07, @03:31PM (#7156468)
(http://pub59.ezboard.com/belforosinnombre | Last Journal: http://slashdot.org/~kilroy_hau/journal/)It's noisy beacuse you have to talk all the time to the other person.
Imagine several teams of pair programmers, all in a reduced space, all talking about their particular task at the same time
Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by tcopeland (32225) * <tom AT infoether DOT com> on Wednesday October 08, @06:58AM (#7161652)
(http://tomcopeland.home.mindspring.com/)> It's noisy beacuse you have to talk
> all the time to the other personHm. Yup, pair programming definitely implies a lot of interaction with another person.
> all in a reduced space
This seems to be the problem.
> all talking about their particular task
> at the same timeI think this ends up being a bit of a good thing - if you hear me talking about
the Frob and how it doesn't have a getFiddle(), it's easy for you to pop up and
say "I just added one!" or whatever. Improved communication... good stuff.Re:Ask Slashdot: Have you used Extreme programming (Score:5, Funny)
by pmz (462998) on Tuesday October 07, @12:52PM (#7154887)Pair programming is uncomfortable on our reduced space. And it's noisy.
Are the inconveniences worth it?
If your partner is really hot, then yes.
Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by Don Calamari (144891) <thedon AT doncalamari DOT com> on Tuesday October 07, @01:07PM (#7155054)
(http://doncalamari.com/)These are programmers. Remember? There are no hot ones, except me, yeah only me...
Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by Black Parrot (19622) on Tuesday October 07, @01:33PM (#7155306)> > Are the inconveniences worth it?
> If your partner is really hot, then yes.
The Thebans [wikipedia.org] figured that one out many centuries ago...
Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by GoofyBoy (44399) on Tuesday October 07, @02:00PM (#7155547)
(Last Journal: http://slashdot.org/~GoofyBoy/journal/)>The Thebans figured that one out many centuries ago...
If I ever do pair programming, it is NOT going to be in a small enclosed cubicals which promote "innocent misunderstandings".
Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by OldAndSlow (528779) on Tuesday October 07, @04:17PM (#7156970)If your partner is really hot, then yes
I'm really hot, would you pair with me?Really, really hot; sweating like a pig, and I need a shave. Come on, let's pair.
Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by slashdot_commentator (444053) on Tuesday October 07, @06:41PM (#7158320)
(Last Journal: http://slashdot.org/~slashdot_commentator/journal/)
Are the inconveniences worth it?
If your partner is really hot, then yes.And given that programmers are overwhelmingly male, I don't think much more than 10% of the population will agree with you.
Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by pmz (462998) on Wednesday October 08, @09:39AM (#7162680)And given that programmers are overwhelmingly male...
Then, they can share one chair. Four arms typing would be a boost of productivity, anyway.
Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by eatdave13 (528393) <[email protected]> on Tuesday October 07, @02:40PM (#7155927)
(http://www.lepertheory.net/)
Wolverine can do it, why can't you?
Re:Ask Slashdot: Have you used Extreme programming (Score:3, Insightful)
by e40 (448424) on Tuesday October 07, @12:53PM (#7154894)
(Last Journal: http://slashdot.org/~e40/journal/)You said "about to" but then say you don't "like it one bit". Hmmmm, sounds like you made up your mind *before* trying it. Tsk, tsk.
The truth about pair programming is that only the right mix of personalities and skills will work. I've done it with people where it worked great. With others, really badly.
Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by kilroy_hau (187226) on Tuesday October 07, @03:37PM (#7156531)
(http://pub59.ezboard.com/belforosinnombre | Last Journal: http://slashdot.org/~kilroy_hau/journal/)sounds like you made up your mind *before* trying it.
Err. Well. You got me there.
The fact is I haven't tried it. But I made my homework. I have STFW and found mixed reviews and opinions about pair programming. That's why I'm asking here, to get more mixed reviews
:-P But seriously, I really don't believe that pair programming is such a good idea, and I was told that it only works if you really believe it works (no kidding, those are the exact words of the project leader), and of course this made me doubt even more.
Re:Ask Slashdot: Have you used Extreme programming (Score:4, Insightful)
by javatips (66293) on Tuesday October 07, @01:02PM (#7154999)
(http://members.ebay.com/aboutme/epirsch/)The concept of pair programming already exist in a good team. No need to force people to work all their time in pair.
When you have a good and balanced team, pair programming will occur naturally. At some point someone is having stuck on some problem (design, bug,
...). In genral, the person will ask one of his fellow team member help to solve the problem. Natural Pair Programming! This is much more effective than having 2 persons work on the same problem (which is trivial 80% of the time).
I believe that Natural Pair Programming with mentoring and code review are a lot better than full-time pair programming. This will help junior developer get up to speed more quickly without having to have two brains waisting their time on trivial problems.
I also like the idea of the other poster saying that you can have one developer write the Unit Test while the other write the business code (you should inverse roles often though). This also benefit having two brain work on different thing while maintaining synergy and increasing the odd of catching bugs.
Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by default luser (529332) on Tuesday October 07, @03:44PM (#7156612)I have to second this concept. The software development group I work for understands that each programmer has different skills to leverage, so this "Natural Pair Programming" approach is the norm.
I may call others aside for input, or be called aside myself for as much as an hour or two a day, but that time is extremely productive, and raises the productivity of the rest of my day.
Coincidentally, I have also worked on a project where one writes the unit test and one writes the program code. There were some caveats though: if you're looking for efficiency, then keeping one on the unit test and one on the code full-time is best. If you're looking for team redundancy, then this is not a good approach unless you hand off between test and program coding so you get a feel for both. If your partner isn't going to be there in 3 months when you're %75 done, then you better know both the code and the test aspects.
I'll third that idea (more...) (Score:2)
by Anonymous Brave Guy (457657) on Wednesday October 08, @07:28AM (#7161766)
OK, I'll third this one.
:-) In a good team, people should feel able to ask their colleagues for advice, and should be willing to offer it themselves. It doesn't matter if you spend significant amounts of time helping others, or vice versa: overall, your team will be more productive. You'll also have much better morale in the group, because nothing saps energy and enthusiasm like staring at the same problem for hours without really seeing how to proceed with it -- particularly if, when you finally give up and ask someone else, they suggest a working solution in about five seconds.
:-) As long as everyone has a little courtesy -- don't interrupt someone who's obviously concentrating hard on something, or disturb someone during their lunch break -- this works really well. I've seen it in several places, all with the same sort of approach, and I'd prefer it to mandated 100% pair programming any day of the week.
BTW, the "one writes the real code, one writes the tests" approach is interesting, but I suspect misguided if that's all they're doing. If your test code takes as long to write as your main code, you should probably investigate better ways to test your code. Writing test code is both a drain on resources and a potential source of errors, and as with any other coding, you should do enough to do the job, but no more. It's worse than regular coding though, because it tends to be really monotonous, and it's very tiring for someone to do it properly for extended periods. If you can automate testing, or part of it, then that's probably a better answer.
If you're going down that road, you might also consider having a designated tools developer. Nothing makes development more efficient and less tedious like a good tool. I recommend having someone whose whole purpose (at least for this week) is to be available to other developers to put together all those helpful little build scripts, code templates, test data generators and so on, and to maintain or update those you already have. For a smaller team, where this isn't a full-time job, it can be done by someone also writing the test code (which is often a tedious job, so this helps to provide more interest) or by any other main coder on the team in exchange for reduced commitments in that area. Any way you look at it, one of the team is getting to know how everyone's stuff fits together and how everyone else works, as well as improving overall productivity and raising team morale.
Pairing works...sometimes (Score:3, Insightful)
by AFirmGraspOfReality (689182) on Tuesday October 07, @01:06PM (#7155037)I've been though a lot of XP. I feel pairing is one of the more crucial aspects of XP. In other words, if you don't pair, you're not doing XP. Make no mistake, pairing is not for everyone. Do you have a cranky,maverick,social misfit who writes brilliant code? Let 'em...don't try to force 'em to pair. Pairing works when a) the people want to pair, b) the people are socially compatible. Pairing forces you to code...no surfing or other dicking around. One coder grabs the keyboard/mouse and does some work, say throwdown a new class or method. Or, more likely, code the test class first. Keep going until you feel "empty" or tired, then pass the torch. The other coder watches and contemplates the code, and offers advise. They are an instantiation of YOUR coding conscience. Coding alone, you may say to yourself "fsck it..i'll clean it up later", but while pairing, the other coder's duty is to say "why are you doing it that way? How about this?" and so on. It has to be COLLABORITIVE, not COMBATIVE..although that happens. If you pair, make sure pairs are always rotating...don't let the same folks always pair. Keep the pairing times short...half day is plenty. Pairing helps to eliminate "hot spots" in the skill set...i.e. experts in one area. It will not eliminate it...people will naturally gravitate to the things they like. Pairing will tire you out, as you tend to "go hard" (==productive) for the day. I think some of the best code I've written was while pairing...if I factor in time spent/unit coded. I've written some brilliant stuff alone, but it took longer. REMEMBER: the other half of the pair who does not have the keyboard must stay involved...question the codier, try to find flaws. They are not just sitting there watching the other half. If you see a pair talking to each other and looking at the screen and pointing, and passing the keyboard back and forth, and just cranking...you've got a good pair. Pairing works, if the pairs work. read this too: http://www.objectmentor.com/resources/articles/xp
e pisode.htmRe:Pairing works...sometimes (Score:2)
by adamruck (638131) on Tuesday October 07, @01:33PM (#7155312)ive done alot of programming in pairs, and rotating sucks! When I find a good partner I wont switch.
Re:Pairing works...sometimes (Score:1)
by AFirmGraspOfReality (689182) on Tuesday October 07, @01:38PM (#7155364)Yeah, I feel your pain. But that's a short-term benefit, not long-term strategy. There will always be one or two "strong" people that are a blast to work with, with (seemingly) less capable people as well. I guess it depends on the size of the team...but you should switch to give the rest of the team the advantage of your talent and experience.
Re:Pairing works...sometimes (Score:2)
by adamruck (638131) on Tuesday October 07, @01:41PM (#7155382)well when I said a good partner I didn't mean a guru, I meant someone thats good to work with and that I communicate well with.
I just can't pair (Score:2)
by metamatic (202216) on Tuesday October 07, @10:23PM (#7159879)
(http://www.pobox.com/~meta/)Call it a psychological defect, call it a mental block, call it what you will... I just cannot write anything with someone watching me. Doesn't matter whether it's code, documentation, an essay, a letter, or a postcard. Try and force me to do pair programming and my productivity will drop to zero.
Code review, on the other hand, I'm fine with. Test harnesses, formal QA, documentation, extensive commenting, frequent releases, UML, it's all good. Just don't look over my shoulder while I'm trying to create something.
Questioning Extreme Programming
"write unit tests first."
"leave optimization 'till last."
"develop iteratively."
The importance of XP is exaggerated to an incredible extent. I've heard more than one person compare XP to OO! Consider the vast amount of thinking of research that went into the development of OO. XP is comparable in importance to a "Frequently Asked Questions" file for beginning programmers.
|
|
|
|
|
|
I mean, here I am, coming into a
compiler-and-assembler design team and I'm being
told that we have to
But to my surprise, it worked. We each had our own 'personal space' computer for e-mail and
everything else, and when we were working we went into our lab as a group. We'd look at the
board of current 'stories' (overall larger tasks) and pick a 'task card' from the story.
(Literally, taking an index card off the corkboard and clipping it into a little holder by our
computer.) And then you sat down at a computer with two monitors, two keyboards and two mice and
you pair programmed. If there were an odd number of people, you had to have someone else go over
your code with you before you checked it in. All code had to have tests written for it
And to my surprise, it worked. With two people looking at code, the little mistakes were
harder to make. Design problems were more easily tackled. Because we all shifted around and
changed partners a lot, we all learned all the areas of the code and had a better understanding
of the system as a whole. The way tasks and suchnot were partitioned out worked very well.
Meetings didn't interrupt the flow of things, because almost all meetings
BUT...this also became a story in how Extreme Programming can
So, I actually would probably agree with the book's assessment; XP is well-suited for certain situations (small team, active customer feedback and support, quick dev cycles), but will fail miserably (and I do mean miserably, as in ruining the morale of the team) if you do not have the full support infrastructure.
Admittedly, some of XP's practices -- tests written before code, meetings held standing up to keep them from dragging on indefinitely -- work pretty well even outside XP. But the system as a whole works well only within a specific target range.
|
|
|
OO isn't the only way to program. It isn't even the best way to program, in certain situations.
XP, Design Patterns, and fads like these are all nice in that they reflect certain practices which make for good software. But they are the CS equivalent of "How to Draw Comics the Marvel Way": great at what they do, good at expressing the concepts behind a particular style/method, not very useful when you want to cross over into other styles/methods.
|
|
|
Get a life, you 'extreme' losers.
|
|
|
(to paraphrase, since I don't have the original text handy):
A manager approached a programmer and asked how long it would take to build an important project. The programmer said, "Six months."
The manager said, "that's too long. What if I assigned two programmers to it?"
"Then the project will take a year."
"That's terrible. I'll give you four programmers!"
"Two years."
"Aigh! I'll give you a hundred!"
"Then the program will never be completed."
Dig?
|
|
|
But in all seriousness, and at the risk of sounding incredibly arrogant, I've not met someone who can keep up with me when writing code. And really, that's not the time for 2 heads, the time for having multiple people looking at a problem is in the design phase - not the implementation.
Code Reviews are great, but personally I hate XP.
by
crazyphilman (609923) on Wednesday November 13, @05:11PM (#4663186)
(Last Journal:
Sunday January 08, @07:08AM)
|
|
|
by
crazyphilman (609923) on Wednesday November 13, @04:49PM (#4662945)
(Last Journal:
Sunday January 08, @07:08AM)
As each module is completed, it is integrated with the greater whole by the team lead.
Debugging is done with driver programs and function stubs, and everything is separately unit
tested. Programmers are responsible for their chunk of the system, and its interface. They don't
have to put up with a lot of baloney like having to justify what they're doing to a partner
who's looking over their shoulder. The overall design is handled by the team lead, who keeps an
eye on how the individual modules are going together.
Modules can be built by internal staff, or by outside agencies. They can even be purchased and
just integrated in. The point is that everything is modular, and everyone is responsible for
his/her chunk, without interference.
Overall, this results in the least amount of argument, and the fastest overall forward progress
because everyone is working in parallel, simultaneously. Projects can be completed very quickly
at minimum expense if everyone pulls their weight.
I think that my point was that whenever programmers have to collaborate on a single stretch of
code, they will inevitably disagree on implementation details and algorithms, and that this will
lead to unproductive debate that will bog down a project. You missed the point entirely. For any
given piece of code, there should be one programmer who writes it as well as he can without
interference.
My joke about the Tao of programming was just a joke. But the basic idea is valid. Too many
cooks spoil the broth. So you have one cook doing broth, another doing steak, another doing
salad... And, the restaurant owner or head chef determines the menu.
Respond if you must. But I have said all I wish to say. You're too judgemental for my tastes.
|
|
|
by smileyy (11535)
<[email protected]> on Wednesday November
13, @05:04PM (#4663112)
(http://fitterhappier.nu/)
I think that my point was that whenever programmers have to collaborate on a single stretch of code, they will inevitably disagree on implementation details and algorithms, and that this will lead to unproductive debate that will bog down a project.
I guess I'm glad I don't work with people like this. To me, those people suck at life, or at least, suck at what I think is an essential part of their job.
Split-the-functionality-up-into-modules-with-defi
|
|
|
Talk of Extreme Programming is getting more and more common. Management is learning about it, and it is being used on many projects. Is it the best way to do software development? Is it right for all projects? A couple of developers are speaking out.Chiara started with a fit stating "I have only two words for pair programming though. Extreme hatred!".
Once again, I find myself in brutal agreement with her. I have been observing XP as a curious beast since pretty much its inception and I have always been uncomfortable with most of the concepts this methodology preaches. In short, it is just at complete odds with reality. Let's take pair programming, for example.
1) Financially.
You cannot convince anyone in the manager and above layer that it's worth spending the salaries of two programmers to achieve the job of one. In their eyes, quantity matters more than quality, and while I used to recoil in horror at this idea, I am now slowly beginning to realize that they are right. Except that quantity and quality are not necessarily at odds if you have a good QA department. This should certainly not be a license for developers to spurn code like mad without paying attention to quality and trying to write tests before implementing, but overall, the combination of developers + QA engineers can work wonder, and you will get twice as much done than XP will ever allow.
2) Socially.
Have you ever tried to sit near a fellow developer and work with her on a problem? If you haven't give it a try and come back when you are done. My experience is that it is one of the most frustrating endeavors a software developer can ever be submitted to. There is so much dissonance in this exercise that the mind reels.
Mental dissonance, first. Even if both developers have similar backgrounds and a similar amount of knowledge (already an impossibility in my opinion), there is still the problem that both of you will have different ways of solving the problem. Granted, you might eventually agree on a common solution if both are open-minded (another requirement) but it's going to take a lot of discussing before reaching that point.
Then, practical dissonance. Most likely, you are not working at the same pace as your XP partner. You are either slower or faster. If you are slower, the growing unrest and impatience of your partner will eventually get to you. If you are faster, you will be squirming on your seat and wishing you could take the keyboard away from the slowpoke so you can get things done, at last. What if you are using an IDE and the unfortunate soul is using a text editor? You are going to cringe, trust me ("where is that source file again? Ah yes, src/com/foo/... er... what was it again?") If you are using a text editor and your partner is using an IDE... well, you will want to punch her nose after ten minutes of work to put an end to her constant reminder on how you would work faster with an IDE.
I could go on and on and dissect Kent's book chapter by chapter. Note that I still recommend you read that book, because you will most likely learn things about yourself and software engineering in general, but I can't really see how XP programming will ever leave the realm of academia.
And I would be extremely wary of working for a company that has made it its True and Only methodology.
[Jul 13, 2001] Duct Tape and Design: Applying Extreme Programming to System Administration By Pat Eyler. Article is provided courtesy of New Riders.
Extreme programming is 80% idiotism and 20% of common sense... Just ignore it despite the fact that they include some rational recommendation in the mess they propose...
Lately I've been reading a lot about extreme programming, often abbreviated XP (see http://www.extreme programming for more details). I like what I've been reading and I'd like to start using the ideas, but I'm a sys admin, not a developer. Do the ideas work in my domain? I think they do. In this article I'll lay out the basic tenets of XP, look at how the practices might fit into system administration, and discuss some possible problems.
XP seems to affect people rather strongly. They either love it or hate it. If you hate XP, don't stop reading here. I'm not advocating system administration Wild West style; then again, XP doesn't advocate cowboy coders either. There seem to be many ideas in XP that would do quite well in improving the work of many sys admins.
If you do like XP, you shouldn't stop here either.
At the core of XP is the idea that there are some rules that lead to better, more efficient code. If these rules work better, why not do them all, all the time, all the way? XP isn't about hanging off a sheer rock wall—it's about doing things extremely well.
NOTE
The following terms come from the book Extreme Programming Explained: Embrace Change by Kent Beck (Addison-Wesley, 1999, ISBN 0-201-61641-6). See the "Resources" section for more places to look for information.
This central theme expresses itself in four core values:
- Communication. If the developers and their customers aren't talking, problems will come up quickly and often.
- Simplicity. "Do the simplest thing that could possibly work." The simpler your code, the less likely it is to break.
- Feedback. Use frequent feedback to steer your work.
- Courage. You need to have the courage to do what needs to be done. Inaction can be just as bad as the wrong action.
To keep the four values going, XP uses a set of twelve practices for the developer. Every programmer on the team should be using all of these practices throughout the life of the project. Keeping all of the knobs cranked is what XP is all about.
- The planning game. One of the biggest complaints about XP is that it throws design out the window. This isn't really true. XP relies on a rough sketch of the overall shape with frequent short-term planning sessions to keep everything moving in the right direction.
- Testing. Before any new code is written, a test should exist to ensure that the code works correctly. Before any project is declared complete, it has to meet all acceptance tests as well. The combination of constant (automated) unit testing and frequent acceptance testing helps to ensure a quality product.
- Pair programming. Pairs of programmers write all the production code. One developer is responsible for the tactical end of things (getting compilable, correct code written). The other is the strategist and makes sure that the long-term impact of the code is in sync with what the project needs.
- Refactoring. This is often termed "refactor mercilessly." Consistent cleaning and improvement of the code makes it easier to maintain and extend. Unit testing and pair programming help ensure that refactored code doesn't break existing functionality.
- Simple design. Don't write functionality into a program where it isn't needed. Because you're refactoring code regularly (and because you unit-test everything all the time), adding functionality later is easier. When you find out you need something, you'll know just what to add.
- Collective code ownership. Each member on the team should know enough about the system to make any needed changes, and should have the authority to do so.
- Continuous integration. After each new bit of functionality is added by a pair of programmers, it should be tested and integrated back into the main tree. If everything is tested before it's integrated, you rarely need to worry about the system breaking. If integration happens often, no one is surprised by changes.
- On-site customer. Having the customer right there allows minor course corrections to happen in near real-time. Without it, development is slowed while programmers wait for feedback.
- Small releases. Releases should be as small as possible while still doing something valid. Many projects shoot for a two-week release cycle.
- 40-hour week. If you work too many hours for too many days, you'll burn out. Stay away from "death marches."
- Coding standards. If everyone is using the same coding style, it's easier to refactor, the code is easier to understand, and it's easier to switch partners as you move along.
- Metaphor. Everyone working on a project needs to understand how it all fits together.
This is a very short description of XP. To really understand it, you probably need to take a look at some of the sites listed down in the "Resources" section of this article. Hopefully, you've got enough information to look at XP through a sys admin's glasses.
Extreme System Administration
Okay, so system administration is less like traditional development and more like duct taping things. Does this mean we shouldn't design things? Or that we should run from fire to fire putting out flames? I don't think so. If we spend our time making sure that our work is done right the first time, we'll all be better off.
I think this is where XP can come in. Some of the XP practices seem to fit right into system administration. Certainly, the ideas of maintainable code (and configurations), common ownership, and clean design are laudable goals for anyone dealing with computers. But how do the practices work for a sys admin?
Collective code ownership, simple design, 40-hour weeks, and coding standards all seem to fit without a great deal of fuss and bother. Recognize that configuration files are just another body of code, and the fit is even better.
The planning game is a bit more of a stretch. Every sys admin has a wide and varied set of customers, and not all of them agree on what needs to be done. It's important to work in light of the basic needs of customers, though. Talking with them about the end results of your work and developing plans in concert with them will help ensure that you're on track with what needs to happen.
Building a body of tests for your network and/or system(s) allows you to make changes in a controlled fashion. Testing gives you the reassurance that everything is as it should be.
Refactoring should be a part of every sys admin's toolkit. If you can consistently simplify and/or improve your systems, they become easier to maintain. You can refactor configuration files. You can refactor crontabs, scripts, and even your architecture. Just make sure that you can test everything to verify that you haven't broken anything.
Having an on-site customer allows you to check the impact of changes you want to make, verify solutions you've implemented, and better foresee needs that will come up. Some methods of bringing your customers on site include email lists, a users group, and just walking around to talk to people.
Small releases allow you to put a change into place incrementally. Making changes slowly lets you back out problems quickly. You can work with greater confidence because you're doing fewer things at any given time.
Metaphor (understanding the whole system) allows each member of the sys admin team to respond quickly to problems. It also allows you to describe proposed changes more readily, and understand the potential effects of user requests.
Caveat Admin
Some aspects of XP don't seem to fit completely into the world of system administration. The most difficult seems to be pair programming. While pair programming might not be a viable option for most sys admins, the ideas underlying it fit very well. Another pair of knowledgeable eyes to look over plans, configuration files, scripts, and other products of our craft can be a boon. (I've had more than a few brainos caught by coworkers.)
I think wholesale adoption of XP into system administration probably isn't the way to go. Reading up on the methodology and stealing the concepts that work seems a much better way to add XP to your daily regimen.
Anyone want to pair up to go clean up sendmail.cf?
Recommended Links
Google matched content
Softpanorama Recommended
Top articles
[Jul 03, 2021] Mission creep Published on Jul 03, 2021 | en.wikipedia.org
Sites
eXtreme Programming is not a silver bullet - O'Reilly ONLamp Blog
Stevey's Blog Rants Good Agile, Bad Agile
Amazon.com: Extreme Programming Refactored: The Case Against XP ...
Extreme Programming - Wikipedia, the free encyclopedia
The Old Joel on Software Forum: Part 3 (of 5) - Extreme ...
Slashdot Questioning Extreme Programming
Talk of Extreme Programming is getting more and more common. Management is learning about it, and it is being used on many projects. Is it the best way to do software development? Is it right for all projects? A couple of developers are speaking out. Chiara started with a fit stating "I have only two words for pair programming though. Extreme hatred!".
Agile software development - Wikipedia, the free encyclopedia
EiffelWorld Column by Dr. Bertrand Meyer
What will remain of Extreme Programming? (February 2006)It is difficult after reading "Extreme Programming Refactored: The Case against XP" by Matt Stephens and Doug Rosenberg (Apress, 2003) to suppress a smile the next time you hear extreme praise for XP. Placed under the patronage of Groucho Marx, the book takes delight in constrasting the hype of those it calls "the Extremos" with the more prosaic results they produce. More...
All the contributors to an XP project sit together, members of one team. This team must include a business representative -- the "Customer" -- who provides the requirements, sets the priorities, and steers the project. It's best if the Customer or one of her aides is a real end user who knows the domain and what is needed. The team will of course have programmers. The team may include testers, who help the Customer define the customer acceptance tests. Analysts may serve as helpers to the Customer, helping to define the requirements. There is commonly a coach, who helps the team keep on track, and facilitates the process. There may be a manager, providing resources, handling external communication, coordinating activities. None of these roles is necessarily the exclusive property of just one individual: Everyone on an XP team contributes in any way that they can. The best teams have no specialists, only general contributors with special skills.
Planning Game
XP planning addresses two key questions in software development: predicting what will be accomplished by the due date, and determining what to do next. The emphasis is on steering the project -- which is quite straightforward -- rather than on exact prediction of what will be needed and how long it will take -- which is quite difficult. There are two key planning steps in XP, addressing these two questions:
Release Planning is a practice where the Customer presents the desired features to the programmers, and the programmers estimate their difficulty. With the costs estimates in hand, and with knowledge of the importance of the features, the Customer lays out a plan for the project. Initial release plans are necessarily imprecise: neither the priorities nor the estimates are truly solid, and until the team begins to work, we won't know just how fast they will go. Even the first release plan is accurate enough for decision making, however, and XP teams revise the release plan regularly.
Iteration Planning is the practice whereby the team is given direction every couple of weeks. XP teams build software in two-week "iterations", delivering running useful software at the end of each iteration. During Iteration Planning, the Customer presents the features desired for the next two weeks. The programmers break them down into tasks, and estimate their cost (at a finer level of detail than in Release Planning). Based on the amount of work accomplished in the previous iteration, the team signs up for what will be undertaken in the current iteration.
These planning steps are very simple, yet they provide very good information and excellent steering control in the hands of the Customer. Every couple of weeks, the amount of progress is entirely visible. There is no "ninety percent done" in XP: a feature story was completed, or it was not. This focus on visibility results in a nice little paradox: on the one hand, with so much visibility, the Customer is in a position to cancel the project if progress is not sufficient. On the other hand, progress is so visible, and the ability to decide what will be done next is so complete, that XP projects tend to deliver more of what is needed, with less pressure and stress.
Customer Tests
As part of presenting each desired feature, the XP Customer defines one or more automated acceptance tests to show that the feature is working. The team builds these tests and uses them to prove to themselves, and to the customer, that the feature is implemented correctly. Automation is important because in the press of time, manual tests are skipped. That's like turning off your lights when the night gets darkest.
The best XP teams treat their customer tests the same way they do programmer tests: once the test runs, the team keeps it running correctly thereafter. This means that the system only improves, always notching forward, never backsliding.
Small Releases
XP teams practice small releases in two important ways:
First, the team releases running, tested software, delivering business value chosen by the Customer, every iteration. The Customer can use this software for any purpose, whether evaluation or even release to end users (highly recommended). The most important aspect is that the software is visible, and given to the customer, at the end of every iteration. This keeps everything open and tangible.
Second, XP teams release to their end users frequently as well. XP Web projects release as often as daily, in house projects monthly or more frequently. Even shrink-wrapped products are shipped as often as quarterly.
It may seem impossible to create good versions this often, but XP teams all over are doing it all the time. See Continuous Integration for more on this, and note that these frequent releases are kept reliable by XP's obsession with testing, as described here in Customer Tests and Test-Driven Development.
Simple Design
XP teams build software to a simple design. They start simple, and through programmer testing and design improvement, they keep it that way. An XP team keeps the design exactly suited for the current functionality of the system. There is no wasted motion, and the software is always ready for what's next.
Design in XP is not a one-time thing, or an up-front thing, it is an all-the-time thing. There are design steps in release planning and iteration planning, plus teams engage in quick design sessions and design revisions through refactoring, through the course of the entire project. In an incremental, iterative process like Extreme Programming, good design is essential. That's why there is so much focus on design throughout the course of the entire development.
Pair Programming
All production software in XP is built by two programmers, sitting side by side, at the same machine. This practice ensures that all production code is reviewed by at least one other programmer, and results in better design, better testing, and better code.
It may seem inefficient to have two programmers doing "one programmer's job", but the reverse is true. Research into pair programming shows that pairing produces better code in about the same time as programmers working singly. That's right: two heads really are better than one!
Some programmers object to pair programming without ever trying it. It does take some practice to do well, and you need to do it well for a few weeks to see the results. Ninety percent of programmers who learn pair programming prefer it, so we highly recommend it to all teams.
Pairing, in addition to providing better code and tests, also serves to communicate knowledge throughout the team. As pairs switch, everyone gets the benefits of everyone's specialized knowledge. Programmers learn, their skills improve, they become move valuable to the team and to the company. Pairing, even on its own outside of XP, is a big win for everyone.
Test-Driven Development
Extreme Programming is obsessed with feedback, and in software development, good feedback requires good testing. Top XP teams practice "test-driven development", working in very short cycles of adding a test, then making it work. Almost effortlessly, teams produce code with nearly 100 percent test coverage, which is a great step forward in most shops. (If your programmers are already doing even more sophisticated testing, more power to you. Keep it up, it can only help!)
It isn't enough to write tests: you have to run them. Here, too, Extreme Programming is extreme. These "programmer tests", or "unit tests" are all collected together, and every time any programmer releases any code to the repository (and pairs typically release twice a day or more), every single one of the programmer tests must run correctly. One hundred percent, all the time! This means that programmers get immediate feedback on how they're doing. Additionally, these tests provide invaluable support as the software design is improved.
Design Improvement
Extreme Programming focuses on delivering business value in every iteration. To accomplish this over the course of the whole project, the software must be well-designed. The alternative would be to slow down and ultimately get stuck. So XP uses a process of continuous design improvement called Refactoring, from the title of Martin Fowler's book, "Refactoring: Improving the Design of Existing Code".
The refactoring process focuses on removal of duplication (a sure sign of poor design), and on increasing the "cohesion" of the code, while lowering the "coupling". High cohesion and low coupling have been recognized as the hallmarks of well-designed code for at least thirty years. The result is that XP teams start with a good, simple design, and always have a good, simple design for the software. This lets them sustain their development speed, and in fact generally increase speed as the project goes forward.
Refactoring is, of course, strongly supported by comprehensive testing to be sure that as the design evolves, nothing is broken. Thus the customer tests and programmer tests are a critical enabling factor. The XP practices support each other: they are stronger together than separately.
Continuous Integration
Extreme Programming teams keep the system fully integrated at all times. We say that daily builds are for wimps: XP teams build multiple times per day. (One XP team of forty people builds at least eight or ten times per day!)
The benefit of this practice can be seen by thinking back on projects you may have heard about (or even been a part of) where the build process was weekly or less frequently, and usually led to "integration hell", where everything broke and no one knew why.
Infrequent integration leads to serious problems on a software project. First of all, although integration is critical to shipping good working code, the team is not practiced at it, and often it is delegated to people who are not familiar with the whole system. Second, infrequently integrated code is often -- I would say usually -- buggy code. Problems creep in at integration time that are not detected by any of the testing that takes place on an unintegrated system. Third, weak integration process leads to long code freezes. Code freezes mean that you have long time periods when the programmers could be working on important shippable features, but that those features must be held back. This weakens your position in the market, or with your end users.
Collective Code Ownership
On an Extreme Programming project, any pair of programmers can improve any code at any time. This means that all code gets the benefit of many people's attention, which increases code quality and reduces defects. There is another important benefit as well: when code is owned by individuals, required features are often put in the wrong place, as one programmer discovers that he needs a feature somewhere in code that he does not own. The owner is too busy to do it, so the programmer puts the feature in his own code, where it does not belong. This leads to ugly, hard-to-maintain code, full of duplication and with low (bad) cohesion.
Collective ownership could be a problem if people worked blindly on code they did not understand. XP avoids these problems through two key techniques: the programmer tests catch mistakes, and pair programming means that the best way to work on unfamiliar code is to pair with the expert. In addition to ensuring good modifications when needed, this practice spreads knowledge throughout the team.
Coding Standard
XP teams follow a common coding standard, so that all the code in the system looks as if it was written by a single -- very competent -- individual. The specifics of the standard are not important: what is important is that all the code looks familiar, in support of collective ownership.
Metaphor
Extreme Programming teams develop a common vision of how the program works, which we call the "metaphor". At its best, the metaphor is a simple evocative description of how the program works, such as "this program works like a hive of bees, going out for pollen and bringing it back to the hive" as a description for an agent-based information retrieval system.
Sometimes a sufficiently poetic metaphor does not arise. In any case, with or without vivid imagery, XP teams use a common system of names to be sure that everyone understands how the system works and where to look to find the functionality you're looking for, or to find the right place to put the functionality you're about to add.
Sustainable Pace
Extreme Programming teams are in it for the long term. They work hard, and at a pace that can be sustained indefinitely. This means that they work overtime when it is effective, and that they normally work in such a way as to maximize productivity week in and week out. It's pretty well understood these days that death march projects are neither productive nor produce quality software. XP teams are in it to win, not to die.
Conclusion
Extreme Programming is a discipline of software development based on values of simplicity, communication, feedback, and courage. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation.
A subsequent article will discuss the common questions and variations within XP. If you have concerns, please write and we'll try to include them in the followup article.
[And Ralph Johnson said that in XP the software life-cycle is: Analysis, Test, Code, Design.]
Ronald E. Jeffries, XProgramming.com
Don Wells, Extreme Programming: A gentle introduction
Many XP Discussions on WikiWikiWeb
Kent Beck, Extreme Programming Explained: Embrace Change
Kent Beck and Martin Fowler, Planning Extreme Programming
Ron Jeffries, Ann Anderson and Chet Hendrickson, Extreme Programming Installed
Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts, Refactoring: Improving the Design of Existing Code
man, you are not leet! My clan programs naked, in the snow, while snowboarding down the mountain with explosions going off behind us. Triple X style! This we do on a daily basis. And the worst part? To get our pants back, we have to lick a metal pole! But we roXor all!
Hey Homebake? Think youz can XP? Bah that's nuffin! Why yesterday I tweaked a 720degree Stalefish function overload with a kickflip.. And just the day before that I baked a varial McTwist class definition.
Tonight L337 1nd33d!
I'm not a big fan of the ESPN Extreme Programming. I much prefer things like ESPN Classic or SportsCenter.
Have you used Extreme programming (Score:2)
by kilroy_hau (187226)
on Tuesday October 07, @03:31PM (#7156468)
(http://pub59.ezboard.com/belforosinnombre
| Last Journal:
http://slashdot.org/~kilroy_hau/journal/)
It's noisy because you have to talk all the time to the other person.
Imagine several teams of pair programmers, all in a reduced space, all talking about their
particular task at the same time
I recommend
Extreme Programming Refactored [slashdot.org] if you are interested in taking the best parts
of extreme programming and mixing them with a traditional waterfall approach to make a nice form
of "moderate programming."
Your post reads like a summary of the book, "Extreme Programming Refactored: The Case Against XP," by Stephens and Rosenberg I recommend it for everyone, including people who are using XP successfully.
If nothing else, it's worth it just for the song lyrics:
(Score:2)Eight Builds a Week
(Sing to the tune of "Eight Days a Week" by The Beatles)
Livin' in a timebox
Guess you know it's rough
Gotta build every day, babe
Even half-baked stuffBuild it, ship it
Build it, ship itAin't got time for design, babe
Eight builds a weekBuild it every day, babe
Build it right on time
One thing I can say, babe
No time for designRefactor it, test it
Build it, ship it
Ain't got time for design, babe
Eight builds a week
Programmersare solo beastsWhere have you been the last 20 years? The stereotypical programmer, hacking his piece of kernel over night is very endangered species, and rightly so. Like any kind of engineering, software engineering needs as much face to face collaboration as possible.
Right, come on! Everyone knows that all programmers are extroverts! Programming should be a
social event! Besides, the dramatic spike in programmer suicides will only drive up the average
salary. If you don't think that the XP model works, just look back at the great collaberative
works by the master artists of the renaissance... like, um... well there IS this collaberative
mural in the subway, and it looks... well, WAY better than bare cinder block!
As explained in my forthcoming manifesto on "Double-Super-Extreme Programming", every time you hear or use a buzzword, a part of your brain dies forever.
Under my theory, you also release frequently to the client, except that you release "deliverables" instead of "stories". Aside from making sense, it looks a lot more justifiable on an invoice. As far as "pair programming", DSXP calls it "cluster coding", and outlaws it under penalty of death. Instead you just program the entire system in the same "programming language", and hire programmers who are all proficient in that language. The result is that, in theory, any programmer can sit down and work on any part of the system. To further that end, technical documentation is added.
But hey, if "XP" increases the value you deliver to the customer, more power to you!
I find this funny as the XP programming relate to none of these.Its principles of transparency, trust and accountability
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: March 03, 2020
