Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Extreme programming opposes the nature of the programmer

By maleficent in Technology
Wed Apr 04, 2001 at 06:03:40 AM EST
Tags: Software (all tags)
Software

Extreme programming, which seems to have reached a critical mass of acceptance in recent days, is basically an approach to computer programming that tries to ensure constant peer review and more effective coding. Unfortunately, it seems to be a new paradigm that further takes away from the individuality of the programmer.


ADVERTISEMENT
Sponsor: rusty
This space intentionally left blank
...because it's waiting for your ad. So why are you still reading this? Come on, get going. Read the story, and then get an ad. Alright stop it. I'm not going to say anything else. Now you're just being silly. STOP LOOKING AT ME! I'm done!
comments (24)
active | buy ad
ADVERTISEMENT

The average software developer is introverted and uses sensing and logic to solve problems. In other words, programmers are individualists, for the most part. They're likely to prefer being alone and solving problems on their own.

It seems to me that extreme programming, as it is being called, is merely a collectivist approach to programming and defies the individualist approach that programming has taken to date and thus defies the nature of the average programmer. Let's examine the tenets of extreme programming, how they differ from typical programming practice, and analyze whether these changes truly reflect an individualist or a collectivist approach to programming.

The first tenet of this paradigm is the planning process, which reduces the programming of a specific program to a system of exchange. Many examples of this involve setting a dollar amount on particular parts of the program and then letting the figurative "customer" decide which parts are essential and which are not with these values in mind.

In previous practice, there would be a specification given to the programmers and they would program it for a relatively sensible fee (salary or negotiated wage).

This phase of programming results in an increase in time spent, but is perhaps the most individualist part of the entire scheme as well as the part I most strongly support. The project is being reduced into smaller individual pieces and each of these pieces are being created based on a specific "price." It's clear that a negotiating element is being introduced here where it did not exist before, but it also helps to set a much more realistic cap on the project itself, the time investment, and the fees paid. Clearly, this is an individualist change to the programming process.

The second tenet of extreme programming is small releases, in which the product is released on a very regular basis, with very short cycles between releases. A great example of this in practice is the mozilla project, which releases builds every night (latest nightly mozilla build). This approach has some advantages and disadvantages. One major advantage is that it keeps everyone on the ball, as it's easy to mark progress in the overall project. A disadvantage is the hassle of a repeated build cycle which makes it hard to focus on a particular piece uninterrupted for a period of time; one can't simply work on one piece for a week without having to worry about a regular build cycle. Note that my comments don't necessarily reflect on the mozilla project here, but instead to the tenet of extreme programming mentioned.

The old method of less regular but more important releases (somewhat reflected by the mozilla milestones) allows more individuality, in that it allows one person to work alone in getting a larger piece of the puzzle working without dealing with a continuous build cycle.

The next tenet of extreme programming, metaphors, requires a specific set of terms and definitions for easy communication. This involves the development of a set of metaphors for the team to use and a team willing to use them. The team must collectively use these terms or else they waste time; however, a well-implemented metaphor set can increase communication.

This is a more collectivist approach than the alternative approach, which allows programmers to explain their own code as they wish without having to conform to a specific metaphor set.

A fourth tenet of extreme programming is simple design, which basically requires that the simplest program that fulfills the requirements is the one delivered. This is very difficult to analyze on a collectivist/individualist level, as it reflects an overall choice in program design. However, I feel that it is definitely a short term improvement but a long term loss over the alternative, which is designing for the future with extra code written in to provide hooks for future code adaptations.

I liken this again to the mozilla project, in that the main development branch is focused on writing with hooks for future code improvement, but occasionally the code branches and the branch is (theoretically) smoothed for release.

It's clear that for a long-term project with changing requirements that simple design as extreme programming demands is not feasible; it guarantees that the full code base will have to be rewritten much sooner than an expandable code base would have to be.

A fifth tenet of extreme programming, testing, basically encourages the writing of code to pass tests and leaves it to the customer to provide tests that properly reflect their needs from the software. Again, this is a tenet that is difficult to judge on a collectivist vs. individualist perspective. It's clear, again, that it's a fallacy for a long term approach, as regularly-used software will soon begin to take on needs that testing can't accurately portray.

The sixth tenet is refactoring, which is a clearly collectivist approach. It requires a clean code base with no duplication and demands a high level of communication about the code base. The group must work together to protect and clean the code base, regardless of how individuals feel about the approach.

The seventh tenet is even more collective; pair programming requires programmers to work in pairs and directly create code together. One person sits at the terminal and types while the other observes and comments. This is clearly collectivist, as an individualist approach (the classical approach) involves a programmer sitting at a terminal hacking out a solution using only his own individual skills augmented with a few queries for assistance.

The eighth tenet, though, is the real collectivist doozy: collective ownership means no one controls any part of the code. Everyone controls everything and anyone can change anything without delay. This entirely disregards expertise in specific areas and makes the entire scheme as weak as the weakest programmer. It is thoroughly collective and denies the individual the ability to code his own work or the pride inherent in his or her own work.

Continuous integration, the ninth tenet, demands multiple daily builds where all of the pieces are collected and assembled in order to keep everyone active. This ties in heavily with the idea of small releases and has similar advantages and disadvantages.

The tenth tenet, a 40 hour week, again denies individuality for a collectivist approach. I often enjoy coding and effectively code over a 16 hour day. Other days, I am content to pursue other interests. Tying an individual to a schedule because others find it to be a good schedule is a strong collectivist approach; most programmers code at their own pace and don't stick to a strict 40 hour week (if you're a programmer, do you stick to a strict schedule with a 40 hour week?)

The eleventh tenet, on site customers, is finally a tenet that is less clear. Having an on-site customer ensures less paperwork and long-distance communication, but it can also result in more meeting time and more time spent away from the desk. On one hand, it allows the individual to focus on required parts that are actually needed, but on the other hand it requires a collective approach in paying strong attention to a customer on site.

The final tenet, a coding standard, requires that all code be written the same way, eliminating individual style for a collective approach. This again disregards individuality and individual coding methods in exchange for a collective approach.

In comparison to regular programming practice, this approach has one individualist change with the rest being either neutral or a swing toward collectivism, many strongly collectivist. As stated at the beginning, this opposes the basic personality of the average programmer and thus, in my eyes, is doomed to fail in the long run.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Are you in favor of extreme programming?
o Yes 30%
o No 8%
o Some parts of it 44%
o They'll die before they take away my code! 16%

Votes: 72
Results | Other Polls

Related Links
o Extreme programming
o programmer s are individualists
o mozilla project
o latest nightly mozilla build
o mozilla milestones
o Also by maleficent


Display: Sort:
Extreme programming opposes the nature of the programmer | 113 comments (84 topical, 29 editorial, 0 hidden)
Individualism (4.16 / 6) (#3)
by ucblockhead on Tue Apr 03, 2001 at 06:44:41 PM EST

If you're working on someone else's dime, then any "individualism" you feel is at best self-delusion.

You also need to understand the difference between forcing people to work together and individuals agreeing to work together for the common good. The latter is not called "collectivism". It is called "civilization".
-----------------------
This is k5. We're all tools - duxup

The workplace isn't civilization... (none / 0) (#7)
by maleficent on Tue Apr 03, 2001 at 06:49:29 PM EST

I just hope that an employer reads multiple approaches to this before enforcing the system at the workplace. The workplace isn't civilization, it's enlightened despotism; if the "enlightened" despots choose to try this, then they're setting themselves up for an environment where many of their best employees feel alienated.



[ Parent ]
May feel (5.00 / 1) (#34)
by Miniluv on Tue Apr 03, 2001 at 09:39:29 PM EST

I think the problem I had with the entire article is best summed up in your comment. You are attempting to dictate how programmers are going to feel based on your rather unscientific, highly unsubstantied claims of the personality of programmers.

Do not attempt to tell coders how they're going to feel. Many programmers seem to like the XP paradigm. Many seem to hate it. Quite a few have yet to decide, or just don't care. Sounds pretty much like the way a segment of the human population approachs every single concept, in that people tend to be split on just about everything.

"Its like someone opened my mouth and stuck a fistful of herbs in it." - Tamio Kageyama, Iron Chef 'Battle Eggplant'
[ Parent ]

My claim is backed up, follow the link (none / 0) (#36)
by maleficent on Tue Apr 03, 2001 at 09:47:42 PM EST

I put in a link to an article on the personalities of programmers; I agree that it would be invalid to make these claims without some data. So, I provided a link to the data.

My other option would have been to plagarize the linked data, because I did paraphrase it. It's your fault for not investigating when the link is on the screen.



[ Parent ]
Actually (5.00 / 2) (#39)
by Miniluv on Tue Apr 03, 2001 at 10:11:25 PM EST

I read the link. Zero citations within the article. Sure, there's some great rambling about the wonderful Meyers-Briggs personality typing. Did you read his percentages? As high as two thirds of programmers? Wow...that really coincides with your ranting.

"Its like someone opened my mouth and stuck a fistful of herbs in it." - Tamio Kageyama, Iron Chef 'Battle Eggplant'
[ Parent ]
Meyers-Briggs is a gradient... (3.00 / 1) (#46)
by maleficent on Tue Apr 03, 2001 at 11:01:46 PM EST

You have to have a great deal of antisocial tendencies to even approach registering as introvert on the MB test. That's why a random sampling of the population generates approximately 23% introverts with 77% extroverts. Commenting that two-thirds of programmers actually classify as Meyers-Briggs introverts says a lot about the psychological makeup of the average programmer.



[ Parent ]
No, no, no. (4.66 / 3) (#51)
by ucblockhead on Tue Apr 03, 2001 at 11:25:44 PM EST

If you think that "introvert" == "antisocial", then you sure as hell don't understand the Meyers-Briggs test!

(Speaking as an INTP, "promethean" temperment.)

And the I vs. E score doesn't have a damn thing to do with being "individualistic" rather than "collectivist" either.

It is also important to note that the "I" vs. "E" metric is one of the less important of the four factors.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Bravo. (none / 0) (#64)
by pb on Wed Apr 04, 2001 at 05:11:17 AM EST

BTW, I'm (basically) an ENTP, and I'd like to see some decent studies on this stuff sometime. I read the referenced article about the MBTI and programming, and I don't believe it. It also pisses me off that marketing firms and whatnot control these tests, and makes the real tests harder to find for interested parties.

But mainly, I just can't bring myself to believe that the average programmer is an ISTJ. The average teacher, maybe even the average CS Professor. But not the average programmer. Or at least, not the average hacker.

Would you like to take a survey? :)
---
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]

Weeeell... (4.33 / 3) (#5)
by itsbruce on Tue Apr 03, 2001 at 06:46:34 PM EST

All the buzzwords on the home page make me flinch. You could really score highly in buzzword bingo: "customer", "empower" etc. But I'll sit on my prejudices and take a more rational look...

In fact, their method does seek to address some of the worst excesses of the hacker/coder: all those anti-social, caffeine-fuelled drives that keep so many muttering in their cubicles and churning out impenetrable code. The "no excessive overtime" principle is spot on - only you'd have to dose me with lithium to get me to stick to it. The fact that so many of these principles make me want to lock myself into my office with a year's supply of coffee and whisky and a sign on the door saying "All my code is belong to me" is probably a plus point for the scheme.

My only objection to such schemes is that, like parenting manuals, they are often proclaimed as universal panaceas. In truth, each team is as unique as any individual.


--

It is impolite to tell a man who is carrying you on his shoulders that his head smells.
Caffiene fueled binges (4.33 / 3) (#11)
by ucblockhead on Tue Apr 03, 2001 at 06:56:40 PM EST

However much people may want to go on 24-hour coding binges, and however macho they feel doing so, the truth is that the brain, like any other part of the human body, has its limits. Work beyond ten hour days too often, or pull too many all-nighters, and your productivity goes in the shitter.

Many people work eighty hour weeks for months on end, congradulating themselves on their stamina, when in truth, their brain is tired, and they are only working at fifty percent (or less). They'd get as much done if they just took a week off and went to forty hour weeks.

This is especially important because if you are burned out and working long hours, you've got no slack when you really do need to hit the grindstone. The guy heads home at five every day is going to be rest enough to go balls-out when crunch time goes.


-----------------------
This is k5. We're all tools - duxup
[ Parent ]

I plead associative recall (none / 0) (#23)
by itsbruce on Tue Apr 03, 2001 at 07:40:46 PM EST

You are more likely to recall facts or ideas if your environment or mental state is similar to that which pertained when you originally learned them. This is why so many students who cram facts late into the night, over coffee and cigarettes, fail in the exams: they aren't tired and they don't have the caffeine/nicotine stimulus.

Well, that describes the environment/state in which I learned almost everything I know about computing. I've given up smoking so I just can't afford to ditch the caffeine or the late nights.


--

It is impolite to tell a man who is carrying you on his shoulders that his head smells.
[ Parent ]
defys [sic] the individual? (3.50 / 2) (#8)
by dr k on Tue Apr 03, 2001 at 06:50:59 PM EST

While there _may_ be great "individualist" programmers out there who are able to weave golden code overnight, I have yet to meet/work with one. Usually it is just programmer ego on top of mediocre programming skills. My current rule is that if someone doesn't want to show me their code, it is probably crap. At the same time, eXtreme Programming does seem to be a bit of a consulting scam.
Destroy all trusted users!
I hate those guys (4.00 / 1) (#99)
by FuzzyOne on Wed Apr 04, 2001 at 11:14:20 PM EST

My current rule is that if someone doesn't want to show me their code, it is probably crap.

Amen, doctor!

We had the displeasure of working with the most insecure, psychologically troubled developer who refused to show his code to the rest of the world. At one point, he took a vacation day so that he could stay home with his laptop (which contained the only copy of his part of the code) and work on his masterpiece. His dumbass manager failed to fire him, so he was pretty much shunned by the rest of the team as they coded around him like road damage.

The sad thing was, no one documented the whole incident, and now several years later he's still around, getting crap projects, feeling slighted and wondering why he isn't head of engineering yet.

I disagree with your analysis of XP as a consulting scam. If we had established a healthy development culture (be it XP or anything else) that had collective code ownership, he would have been terminated immediately (or else never would have felt so insecure about protecting his crappy code.)

[ Parent ]

The major fallacy of Extreme Programming (4.33 / 6) (#10)
by Carnage4Life on Tue Apr 03, 2001 at 06:54:56 PM EST

After being made to use Extreme Programming in a software engineering class, I now despise most of it passionately. What I dislike about XP is that it seams based on the myth that all programmers are equal which we all know isn't true.

Having a methodology that requires a good coder to sit beside a mediocre programmer and have to carry he/her along is wrong. Stating that everyone have free reign of all aspects of the code in a project also only works if everyone is competent, it only takes one bad apple to spoil the bunch.

This article is rather biased and absolutist, it could have done with a little toning down to get your point across. It is obvious to anyone that not all of XP is bad (refactoring is a great idea) and not all of it is good(collective ownership is a recipe for disaster on a lot of levels).

"Collective Ownership" (4.66 / 3) (#13)
by ucblockhead on Tue Apr 03, 2001 at 06:59:38 PM EST

While it is good to have different parts of a project "owned" by different people, you have to be damn careful that the ownership felt is not too powerful. The ideal situation is one in which any programmer can work on any part of the program. One may be the "expert" at a piece, but anyone can pick it up.

This is important both because of the "what do we do if fred gets hit by a bus?" question, and also because it helps avoid scheduling bottlenecks that would otherwise occur if only one person understood two different critical pieces.


-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Software engineering is not a good test case (4.83 / 6) (#21)
by Sunir on Tue Apr 03, 2001 at 07:39:22 PM EST

Actually, what probably made the project fail was your class. All software engineering classes make their students hate methodology and whatever methodology used there. For instance, I will never, ever use RUP.

The inexperience of the team plus the unrealism of the course load (I'm guessing), plus I bet the greenhorn attitude of most of the team members killed the project.

It's not really fair to evaluate a methodology until you have a fair setting to evaluate it in.

Besides, you're wrong. XP is based on the assumption that individual weaknesses can be overcome by collective reinforcement of virtue. So instead of isolating the weaker programmer so their work is guaranteed to fail, XP makes all programmers interact so stronger programmers can fix mistakes and coach junior members. XP isn't designed for hot shots, but for the average programmer. That's why it moves slower than cowboys, but that's also why it succeeds.

Of course, if everyone on the team had the same character flaw (individualism being the most common), then project will naturally fail. In fact, I think the flaw would actually reinforce itself.

"Look! You're free! Go, and be free!" and everyone hated it for that. --r
[ Parent ]

Strong views... (5.00 / 4) (#22)
by cezarg on Tue Apr 03, 2001 at 07:40:28 PM EST

Hmmm. I can't really say I agree with you.

Point number one: XP does not assume that all programmers are equal. It does assume that they are in the same ballpark. The skillsets might be quite different though. For example, I worked in an environment similar to that prescribed by XP with a girl (hi Eli!) who's a mathematician. We were developing an algorithm for a geological software tool. Her maths knowledge with my programming experience gave an excellent result. She was able to fill my gaps on the maths side of things while I could tell her a thing or two about C++. If one of us was to code the same stuff alone we'd need to go through a steep learning curve. Note how we werent "equal": her maths was clearly superior while I was the one with more general programming expertise behind my belt. Not to say that I don't know any math or that she doesn't know C++. Both of us could just complete the task on our own. The point is that by working in a pair the task was accomplished in days instead of months as initially predicted.

I presume your bad experiences with XP stem from the fact that you tried it at the uni. The problem is that when you're in education you're often lumped together with people who have no desire whatsoever to become programmers once they graduate. A lot of them will try to fit into the "soft skills" categories such as project management, technical sales etc.

Pair programming works as long as a certain level of competence is maintained across the team. And believe me, coding primadonnas are often quite difficult to deal with. I had to put up with one (hi Robert!) for a while and while he was clearly competent at what he did, the rest of the team (who were just as capable) suffered tremendously. Very often you'll see that in the working environment those "gurus" are so valued because the were the first on the project and not because of their (often claimed) sheer brilliance.

I like XP's ideas about testing. Their prescription is simple: don't write your code until you've got the code that tests it. How else do you know how to write your program correctly if you don't know how to test it i.e. you haven't defined the correct behaviour yet!

Don't hate XP until you've tried it with a team of competent programmers. A lot of the stuff they mention really works. I once worked for a games company and they deployed many techniques prescribed by XP in their development efforts. The environment was quite relaxed so all the pair programming and frequent builds/tests stuff came quite naturally. And I firmly believe that games companies are amongst the most productive software businesses. Why? Because they don't need people telling them about XP - they've been doing it for years already!

[ Parent ]

Individualistic programming (4.50 / 8) (#12)
by scorbett on Tue Apr 03, 2001 at 06:56:44 PM EST

So you're arguing that individualistic programming and individual code ownership are good things? Let's think about that.

Software development is a team effort. If you take a group of programmers, assign them to a common project, and then let them all go off to their own offices and work without talking to each other, you're going to have problems. Collectivism is necessary to a greater or lesser degree (depending on the size and scope of the project). I'm not saying that pair programming is always the way to go, but it can be useful (this was just discussed on the other site, here's the comment I made).

Code ownership can lead to trouble down the road if your star programmer suddenly decides to leave the company, or gets hit by a bus or killed in a freak shaving accident or something. Collective ownership ensures that you have at least a bit of redundancy in your skills distribution. You argue that collective ownership prevents an individual from taking pride in his work - I strongly disagree. That's like saying that a football player can't be proud of winning a game because he wasn't solely responsible for it - of course he can feel proud, because he was part of the team that won the game. Pride in your work is not automatically an individualistic phenomenon, there is such a thing as team pride. You also argue that collective ownership reduces the effectiveness of the team down to the effectiveness of the weakest programmer - again, I disagree. This is what mentoring is all about, the weaker programmers learn from the stronger ones - this is where team programming really shines.

You do make some valid points, and it should be a good discussion, so I voted you +1 even though I disagree with the thrust of your argument.


Utilizing respective strengths (3.66 / 3) (#14)
by maleficent on Tue Apr 03, 2001 at 07:00:40 PM EST

Every programmer is equal in this scheme. Every programmer has equal right to edit code, and thus the worst programmer in a team appears externally to be the same as the best. This has nothing to do with self-promotion, ego, or bluster - it has to do with how "extreme" programming works.

Software development is a team effort. But software development should be about utilizing respective strengths. Extreme programming is not.



[ Parent ]
Capability vs ability (4.66 / 3) (#24)
by Sunir on Tue Apr 03, 2001 at 07:46:54 PM EST

Everyone has the same capabilities, but that doesn't mean everyone has the same abilities. Everyone has different strengths and weaknesses. This is what makes teams so strong. No individual can master everything, not even the best, so where she falls down, another will pick her up. But only if he is allowed to.

You know, I think the worst programmers are the most individualistic. If you're willing to contribute without any personal ego stroking, even if you are not nearly as skilled as the team hot shot, you are still valuable. You serve as a foil to her wild thinking, you're willing to learn from her, and you're capable of providing those "so obvious why didn't I think of it" insights that are only capable from the innocently naive.

But it's those programmers that protect their code, that don't listen, that try to prove their worth more than others that create bad programmers. They can't admit mistakes, so they let more mistakes through. They're the weakness on the team, not their code.

XP is severely allergic to the latter type of person, and severely conducive to the former. In fact, I'll bet XP makes people more willing to be humble because it's so much more fun that way.

"Look! You're free! Go, and be free!" and everyone hated it for that. --r
[ Parent ]

I don't want ego stroking... (3.50 / 2) (#26)
by maleficent on Tue Apr 03, 2001 at 07:57:39 PM EST

I just don't like other people. Leave me alone and let me code. Most programmers are introverts; extroverted programmers are the egomaniacs most people remember because they are extroverts.

XP violates everything I enjoy about software development. I don't mind working in a team as long as I am able to write the code alone, using only my mind as a tool. If I need help, I will ask; I'm quite glad to let others read my code if they want to.

XP is forcing me into a paradigm that I don't want to be in and it takes away what I like about programming.



[ Parent ]
Living through introversion (4.66 / 3) (#41)
by Sunir on Tue Apr 03, 2001 at 10:34:37 PM EST

I understand what you're saying, but bear in mind that XP doesn't force you because XP won't hire you. Bad culture fit. But if you are in an XP environment for reasons beyond your control, there are things you can do to adapt.

For one, just go with the flow. Sure you may feel exasperated with all that social interaction, as introverted people are, but if you just accept your fate, do the motions as faithfully as you can, it's not too bad. After all, it's only 40 hours a week. There's no overtime with XP.

You can also not sign up to work with anything at the beginning of the iterations, and instead volunteer to work with people on your same wavelength. Do this until you feel up to working with someone who doesn't see things the same way you do. Just don't keep pairing with the same person because that creates a pair clique and breaks the team apart. A good coach will prevent you from working with the same person from one iteration to the next.

You can also try working on yourself. Learn how to communicate more effectively, how to listen, and how to pick up cues from your audience when speaking so you can adjust your speech to match their reactions. This will make explaining yourself a lot less frustrating.

But I think it's not a hellish situation, and I think it's very workable. Consider than Kent Beck, the main XP honcho, is very outgoing whereas Ward Cunningham is much more quiet. Yet Ward and Kent make a great pair, and they are the ones who came up with XP.

What I'm saying is that I think you can do it if you tried. I also think that this can go a long way to improving the reality of the introverted geek in the corner.

"Look! You're free! Go, and be free!" and everyone hated it for that. --r
[ Parent ]

football analogy (2.00 / 1) (#31)
by dr k on Tue Apr 03, 2001 at 08:27:33 PM EST

thinking about football teams (American or not, it doesn't matter for this discussion) makes me think about a typical programmer stereotype, the kind of guy who would never participate in team sports in high school because he had more intellectual/individual pursuits.

so now you have a bunch of programmers who lack appreciation for any kind of "team accomplishment" - they want specific credit. what they really need is a stern lecture from the coach, the old "not everyone can be a hero" talk.

ironically, the team sports are the ones that put the most emphasis on the Star Athlete, on being #1. but then a lot of Star Athlete's end up selling used cars for a living.
Destroy all trusted users!
[ Parent ]

Works and Doesn't (4.50 / 2) (#20)
by compmajor on Tue Apr 03, 2001 at 07:37:43 PM EST

I can understand how XP can lower the amount of bugs that get typed into a program because a programmer forgot to add a value, or a case, whatever. I've had some experience with XP from 2 people in a group to 5. While it does have its strengths (lowers bugs, more cases covered, etc) it does have its disadvantages regarding the concept that all programmers are equal.

All programmers are not equal. While many claim XP speeds up the software creation process, this is not necessarily so. Many times I've had to slow down writing my code so I could explain to the other programmer(s) what a certain piece of code did, or that this pointer should be null, etc. I guess that all has to do with hiring competent programmers... but we know that doesn't always happen.

It is about learning .. (none / 0) (#106)
by Highlander on Thu Apr 05, 2001 at 11:43:55 AM EST

If you have to explain things to the other programmer, he will learn from you, and will know how your code works. Then, if you leave the company or move to another project, the company will have one person left who knows what is going on.

Moderation in moderation is a good thing.
[ Parent ]
That is (none / 0) (#108)
by compmajor on Thu Apr 05, 2001 at 02:45:33 PM EST

That is, assuming they will learn from it. Ever had to carry another programmer, maybe not cause they didn't get it, but because they just didn't care about learning it? The less responsible sometimes view XP as an easy way to get a free ride. XP in an ideal world isn't bad... but when you factor in human nature, laziness, and indifference, its not the ideal thing that many people are making it to be.

[ Parent ]
i am the machine (2.66 / 3) (#29)
by axxeman on Tue Apr 03, 2001 at 08:11:49 PM EST

This basically is an attempt to turn programming into something done on a production line.

I'm not sure if programming can actually work this way, or rather if it can work OUT any better than traditional methods (90% projects not on time/budget, many never completed).

We can say with some confidence that management/customers don't *understand* the way programming works/doesnt work now. Will THIS help?

Yes and no, as everything in life. Yes, it will work for things like accounting packages, where the environment is fairly static and well known (and there's a million other programs already doing the same thing). No, it won't work for Quake 4. For many things in between it will have partial success. I'm fairly sure it won't work for anything actually innovative.

However, if this becomes standard industry practice (The Way Things Are Done), it would open up the field to many people that couldn't be considered programmers in the current sense of the word. Would this be good or bad? That depends - for us or for them?

Being or not being married isn't going to stop bestiality or incest. --- FlightTest

A group approach is good, but not perfect (3.66 / 3) (#30)
by nurglich on Tue Apr 03, 2001 at 08:16:41 PM EST

Coders are a bit individualistic, and I don't agree with everything on the list. However, people outside the programming world (like me) care much more about the functionality and stability of software, along with the ability to control cost, than an individual's style. I don't much care how the software is written as long as it is basically efficient, bug-free, and able to accomplish its purpose. Until individuals begin consistantly putting out this kind of quality, a group approach is the best way to ensure that it gets done right.

Now, I'm not advocating a totally communist development program; a flexible schedule and the assurance that your code won't be ruined by an inept coworker are important. I just think that it is imortant to have a well-designed plan and many ways to ensure quality output throughout the development process. And if you can actually put out something great without much outside help, then feel free to ignore me.

------------------------------------------
"There are no bad guys or innocent guys. There's just a bunch of guys!" --Ben Stiller, Zero Effect

Some of this sounds good... (4.00 / 3) (#44)
by Mr. Piccolo on Tue Apr 03, 2001 at 10:45:32 PM EST

but others seem utterly ridiculous.

Disclaimer: I am not yet a software professional.

The parts that sound good are:

Metaphors -- communication is essential in a properly functioning programming team. If the team can agree on a common vocabulary, then communication becomes much easier. It may take a while before I understand what Joe calls a "gadget" is what I think of as a "widget". Better to agree on "gadget" or "widget" beforehand.

Simple Design -- simpler design means less places things can go wrong. Also, I disagree that you should design hooks into your code for future expansion. It seems to me that would rather limit your ability to actually expand the product to the ways in which you've designed it to be expanded, and you'd be better off doing a simple modular design in the first place. With a proper modular design, all you need to do is add new modules that interface in well-defined ways with the old ones. A simple design doesn't mean it's not expandable.

Testing -- Testing is good, both of the individual components and the assembled product. Having the customer supply tests could be good as well to make sure it satisfies their requirements, but probably is not always necessary.

Refactoring -- If your code contains duplicate functionality, it can be very difficult to figure out which implementation is broken, as well as which is best in the overall design. Better to have the team communicate over who is responsible for which parts of the product.

On site customers -- In spirit it's a good idea, because it promotes cooperation between the customer and developers to better reach the final goal, which is producing a product that fits the customer's needs. However, this brings up the question "Your place or mine?" In other words, it may be better to send the developers out to the customer, especially early in the development process.

Coding standards -- It might make things easier to read if everyone follows consistent indentation practices, symbol naming conventions, etc. Plus your manager will thank you ;-)

Now for the parts that I dislike:

Planning Process -- Putting dollar values on code seems like a Bad Idea to me, especially because how are you supposed to predict such a thing before you do it? Project planning (i.e. schedule, break-down of responsibilities, etc) is important, but this seems just insane.

Small Releases -- I hope by "release" you don't mean "product delivered to the end user", because who wants 200 versions of the product delivered to them, all different in some small, sometimes almost invisible ways, and some of which are guaranteed not to work? Perhaps this should be renamed to "Incremental Builds", as I have a problem calling them "releases" because that implies distribution to an end-user.

Pair Programming -- I'm sorry, but if you can't trust your programmers to work on their own without another programmer looking over their shoulder, you've got problems. This may be good for new employees, but that's it. In addition, this means half the programmers in the company are doing far less productive work of their own than they could be doing if they weren't supervising another. Probably the biggest problem I have with Extreme Programming, although it might raise code quality a bit.

Collective Ownership -- I think there are obvious problems here where the less-skilled programmers start relying on the better programmers to fix all their errors and do what they can't do, instead of learning how to do it themselves. As a result, the best programmers end up getting most of the work and the worse programmers become freeloaders. Although it's better for the code, it may cause more problems within the team itself.

Continuous Integration -- I think it would be better to make sure each piece works properly by itself, then put everything together once all the pieces are working. Perhaps that doesn't actually work, though...

40 Hour Work Week -- Programmers should be allowed to go over 40 hours if necessary if it will help the code or if the project is running behind. The 40 hour work week shouldn't be a hard limit but a general rule. But from a planning perspective, it might be a good idea.

In conclusion:
Extreme Programming really means Extreme Emphasis on Team Programming. I think that programmers should be working as a team to accomplish their goals, but Extreme Programming takes things too far, especially with the buddy-system programming approach. If you can't code without someone else looking over your shoulder, you shouldn't be programming at all.

The BBC would like to apologise for the following comment.


Some counterpoint. (3.00 / 1) (#69)
by mindstrm on Wed Apr 04, 2001 at 09:12:13 AM EST

40 Hour Work Week - remember, we're talking about real software engineering here, not coming up with 'brilliant new coding techniques to solve the problem'. Even huge projects are relatively easy to code once you've defined what it is you want to do. We aren't talking about learning as we go... we're talking about serious software engineering. Making sure that it's *just* a job, and making sure everyone keeps a nice schedule is very important. Or as my guru once said.. you aren't doing your job right if you can't do it from 9 to 5. It's especially important to keep proper hours when you work as a team, or in pairs.

Continuous Integration - This is a must. If you rely blindly on the fact that everything will fit together in the end, no matter how exact yours standards, and how careful you are, you are asking for trouble. What happens when something doesn't fit? Better to have pieces farmed out to integration people as they are produced so those people can give feedback. Also realize that Test & Integration people are usually just as skilled as those writing the code; they just have different duties.

Collective Ownership - Again, we aren't talking about the latest new media player or napster clone here, we aren't talking about making a coder famous for 'inventing' something, we're talking about serious software engineering for serious systems. The whole programming team must have solidarity. Nobody should be singled out as 'the man' who's responsible.

Pair Programming - This, again, just as above, isn't for writing your latest little internet gadget, and it's not for getting famous. It's for exacting programming. It's for standards. Also, in pairs, you will learn. This is not a place for the big ego.

Small Releases - it's just terminology. This probably means incremental builds... every firm has it's own terms for something. I woudl surmise that a 'release' would be somthing sent to the T&I crew for feedback...

Planning Process & Dolar Value. You are paying people for their work... so isn't what they are producing worth money? If you have a methodology that can consistantly produce good code working towards a goal, then you have to have a way of judging the cost of problems that get thrown in, so you can assess things like insurance, spare coders, etc.



[ Parent ]
This is why XP is a good thing. (4.80 / 5) (#47)
by fink on Tue Apr 03, 2001 at 11:03:41 PM EST

(aside: this is probably tainted with my own thoughts and feelings. YMMV). I'm going to concentrate on my own area - mission and/or safety critical software.

The average software developer is introverted and uses sensing and logic to solve problems.
The key word in this sentence is sensing. One of the tenets of software engineering is that it is based on the principles of engineering as a discipline. "Sensing" the "correct" answer is not the way to provably demonstrate that code is correct.

This phase of programming (planning) results in an increase in time spent ...
I've been put through the torture that is the PSP - Personal Software Process. One of the things you find, through this, is that while planning and design seem to be a "waste" of time, an average programmer finds that the overall project time is reduced. Provided, of course, that planning and design were done intelligently...
but is perhaps the most individualist part of the entire scheme as well as the part I most strongly support.
Good point, but this is not the aim of planning (individualism). Matter of fact, one of the qualifying factors about a good plan is that it is repeatable - meaning that it is rarely individualistic.

This is a more collectivist approach than the alternative approach, which allows programmers to explain their own code as they wish without having to conform to a specific metaphor set.
One very common problem with team software development - and just about every large piece of software has to be a team effort - is the language used. It is essential that the team use a common language set, and where possible eliminate all ad hoc explanations, because it is these explanations that cause problems. What if your explanation is open to interpretation, and two different interpretations yield completely different results? It happens, I've seen such a thing.
Of course, this is a difficult thing to enforce, and to enforce it perfectly is impossible.

However, I feel that it is definitely a short term improvement but a long term loss over the alternative, which is designing for the future with extra code written in to provide hooks for future code adaptations.
I assume that you are not talking about safety or mission critical systems here.
Software is complex - it is one of the most complex endeavours undertaken by man. Unnecessary complexity breeds failure. In safety or mission critical software, simplicity is more important than extensibility - simplicity makes it easier to design robust code, extensibility does not necessarily allow robust code.

...as regularly-used software will soon begin to take on needs that testing can't accurately portray.
Never design code to do what it is not required to do. If you have a good set of requirements (very difficult to get, I know...), you design/code - and test - for this. This fits in with my above point - simplicity, and doing exactly the task required, is important. Doing extra, unplanned for tasks, is not. Being able to recover in a predictable manner, from all unplanned tasks, is important.

...denies the individual the ability to code his own work or the pride inherent in his or her own work.
Let's face it. In large (say 1MLOC) safety critical systems, no one individual should be responsible for one section on their own. You find it hardest to find your own defects - and a simple logic error could kill. Having peer reviews, and multiple people reworking the same piece of code, is the best way to solve this issue.

... requires that all code be written the same way, eliminating individual style for a collective approach.
Coding standards are intended to do just that.
In safety critical software, it is very important that the code is easy to examine, and that it is examined rigorously before it is ever used.

Okay. Sure, XP is not suited to every domain. But no paradigm, method or process - or any one language - is perfectly suited to every domain.

I would rather board an aircraft which had a flight director that been coded by a group of software engineers, who code in a collective manner, than board the same aircraft, which had a flight director that had been coded by a group of "hackers" who regard individualism over collectivism.

Experience shows, that for safety critical software, the right planning, design and coding choices reduce the number of defects. Any defect in a safety critical piece of software can lead to fatalities.

Sure, for the average non-safety-critical program, it's not as important - a failure would be at best an annoyance. Sure, XP may not suit programmers as individuals - but in the right circumstances it can lead to better code.

Just because I'm arguing "for" XP doesn't mean I agree with it 100%. However there are parts of it which I believe all of us, as software developers, can and should use. Bah, now I have to go work...


----

Has anyone here actually *done* XP? (3.00 / 3) (#48)
by Sunir on Tue Apr 03, 2001 at 11:07:21 PM EST

From the comments in this article, and the article itself, I gather not many people here have actually done XP, yet many are commenting on it. This is why I voted -1 Dump it originally, because one cannot introduce the topic of software methodology without inciting a religious war unless you make a carefully reasoned, detailed, yet humble review. I don't think the above remotely succeeds in that because it's just brushing XP aside without even bothering to understand it.

Of course those who know me will recognize that this is half the reason I get fed so up with XP advocacy. Most of XP isn't detailed (aiming rather for simplicitly of explanation), and lately it hasn't been humble. It is well-reasoned though, so that's why it's so easy to like.

*grumble*

At least business methodology is equally messed in the head, so we software dweebs aren't alone. ;)

"Look! You're free! Go, and be free!" and everyone hated it for that. --r

Fad or fusion? (3.00 / 1) (#50)
by mjs on Tue Apr 03, 2001 at 11:19:06 PM EST

Beats the crap out of me. I've been coding for 20 years and have seen - and participated in - a lot of fads and even more techniques that became, for at least a while, standard industry practice. I don't know how XP will turn out but I'm voting this up because I want to see the comments the article inspires.

For me, I've never tried pair programming and frankly, I'm not sure how I'd take it. When I'm in the zone and the code is flowing, the first well-intentioned remark is likely to be unheard; if repeated it might just get someone killed. Ten years ago I could listen to music and code; now if a radio is playing I don't even hear it. I'd like to try it sometime, but not on a production project :)

I am reasonably sure of one thing: everything up to now has been crap. Software is invariably late, over budget, and buggier than an Indiana August evening. Software is not now nor do I see signs that it will soon become an engineering discipline; there's still 'way too much 'art' in programming. Good people but I doubt our processes. We're making headway but we've got a long way to go. XP may be a step along that road, or it may just lead to a dumpster; like I said above, time will tell.

Sigh... (1.20 / 5) (#52)
by Zeram on Tue Apr 03, 2001 at 11:29:22 PM EST

XP is why things like VI get made.
(Let the unintentional flame war begin)


<----^---->
Like Anime? In the Philly metro area? Welcome to the machine...
It's a discipline, that's all (4.71 / 7) (#53)
by jabber on Tue Apr 03, 2001 at 11:30:22 PM EST

I vote +1 for a well written topic on a subject worthy of good discussion.

XP is just a development process. That's all. It isn't any different than RUP, CMM, FDD or any other process. Some processes work better for some people on some projects. That's all.

Anyone who thinks that a process is the Holy Grail of survival, better be talking about photosynthesis. Anyone who thinks that a company can put out a good product on strict adherence to XP or any other process, is in for a very rude awakening.

A good process won't make mediocre people into a properly jelled team. At best, a process will keep bad coders from hurting each other.

I find the given reasons against XP to be naive and short-sighted. The first 'real' programming job anyone should ever be given is the maintenence of someone elses code. It's as much a test of character as it is of ability. If a coder does not make a point of writing 'sharable', readable, maintainer-friendly code after going through the experience, (s)he ought to be let go with a friendly pat on the head.

The term eXtreme programming conjures up imaged of hackers on snowboards, cranking out l337 Perl scripts with one hand and grabbing for a Mountain Dew with the other. Bull!

XP is the 'greedy' approach to program development. It works fantastically well for hit and run projects where resources are few and ownership for code can not be assigned or claimed. XP delivers results briliantly, in the short term, but making it the standard process for development in anything but a one-man operation which produces write-only code, is insanity.

XP is a hack of a process, intended to fend off creepy features, fickle managers and unrealistic schedules. It is a step towards chaos, and a rasp for cutting the corners to make the square peg fit the hole better. Take it for what it's worth, a set of tactics, stratigically applied.

A bunch of individual musicians can not play a Symphony. A group of independent contractors can not build a skyscraper. A bunch of arrogant, egotistical, near-sighted coders can not write an appreciably large system with any hope of quality. Q&A and V&V are an after-the-fact means of mitigating individuality - and I do mean that. XP puts the QAV stuff right into the development cycle, that's all.

A sharp whack to the Pineal Gland with a tightly rolled up copy of The Mythical Man Month for you! :)

[TINK5C] |"Is K5 my kapusta intellectual teddy bear?"| "Yes"

Extra eyes (4.33 / 3) (#54)
by www.sorehands.com on Tue Apr 03, 2001 at 11:49:19 PM EST

Working with someone helps. Not, constantly looking over your shoulder.

Having someone to bounce ideas off of; or to look at code that you are stuck on helps alot. Sometimes, even explaining code to someone else makes you realize what the problem is.



------------------------------------------------------------------------------
http://www.barbieslapp.com
Mattel, SLAPP terrorists intent on destroying free speech.
-----------------------------------------------------------

individuality (4.75 / 4) (#55)
by Puchitao on Wed Apr 04, 2001 at 12:38:02 AM EST

In each point, you note that XP goes against individuality; I can agree with you on that wholeheartedly. But, as comfortable as individuality may be to you, by virtue of what is it better?

Yes, a majority of coders are introverts (although it doesn't seem to be an overwhelming majority -- your source claimed somewhere between 50% and 66%). Social interaction may make them feel uncomfortable at times. But the question at hand is whether the resulting software is better or not. Whether or not the average programmer enjoys teamwork or not is a secondary issue.

I've never done XP, and I have a lurking suspicion -- as someone did earlier -- that it's a big consulting scam. (I think it's the name that bugs me. "eXtreme"? Really now.) But neither do I have any great fondness for the "software cowboy" mythos, the lone genius (?) programmer working alone until 6 A.M. on a cryptic and esoteric code segment.

Why? I imagine many of us here have had to maintain (or debug) code written by such a programmer. It ain't fun. After awhile, you get into the previous coder's head, and understand their arcane (but sometimes quite clever) logic. But an awful amount of time is wasted getting to that point. Had the last company I worked for had, say, code review, coding standards, commenting standards, pair programming, collective ownership, anything, really, they probably could have avoided many of the problems that their very high turnover rate caused. (Well, the company had very high standards for the safety-critical portions of the code, but not for our piddly stuff.) But as it was, the coders all worked independently, and as soon as they left all their knowledge and work evaporated, often started anew by another individualist programmer who didn't like how the previous one programmed.

I'm no genius programmer. I get by with a little help from my friends. And I don't believe anyone is so good a programmer that their code can't be improved by a little friendly peer review. Computer science is too large a field for one person to be an expert on everything.

If the resulting code is better -- note that I say "if"; I dunno much about XP's results -- then the social anxieties of your programming team should come second. The inmates of a psychiatric ward would almost universally prefer to sulk in their rooms, and resent the stupid little "activities" the nurses force upon them. But there are more therapeutic benefits to group activity than to sulking alone. Likewise, if the code is more reliable and delivered on time, I say we dispose of the "software cowboy" mythos, discard our insecurities, and suck it up and try some old-fashioned teamwork.

Perhaps we can do *snappy fun* with you everytime! -- Orz

Indeed (4.00 / 1) (#82)
by SnowDogAPB on Wed Apr 04, 2001 at 12:26:00 PM EST

Going back to the original story:

"This entirely disregards expertise in specific areas and makes the entire scheme as weak as the weakest programmer."

I don't know how much real world software engineering experience you have, but in my line of work, the project is already as weak as the weakest programmer.

Your best programmer could get hit by a truck tomorrow. Your best programmer could get snatched up by the competition. Basically, the more arcane knowledge stored in your best programmer's head, the more at risk your entire project is.

A prerequisite for everyone being able to modify any code is that everyone has to understand all the code! No more mysteries. No more comments like "Don't change this," or "I don't know how this works but it does."

I don't know anything about XP. It sounds like a collection of decent practices (and some suspect ones) packaged up in a nice way to generate some hype and sell some books and services.

But claiming it's bad because it gets rid of individualism in code... yikes! Anyone who has worked in a large software organization for more than a couple of years has hid his/her fill of fixing other people's "individualized" code.

Give me standards. Give me collective ownership. Release me from the "oh, that's Bill's code, I don't dare touch it."

Please.




[ Parent ]
Coincidentally, I don't like XP either... (3.00 / 2) (#58)
by pb on Wed Apr 04, 2001 at 02:46:49 AM EST

I've been programming for a long time, and I'm a pretty extroverted person. However, I generally code everything by myself. I'm not really used to having someone else on a project with me, and generally I end up rewriting stuff just so I can deal with it.

However, recently I've been working in a team for Software Engineering, and we're developing a program collaboratively. Our approach involves explicitly assigning roles and duties; our group members help each other out based on their strengths. Because I'm not the strongest Java programmer, I've been doing more design and directing of coding than actual coding. This has worked pretty well. I'd hate to have to share equally a bunch of tasks that I wasn't really suited for.

XP, when taken to the extreme, does not seem to encourage this approach, as you have pointed out. Therefore, it should not be taken that seriously. I have found that pair programming is very helpful for spotting bugs before they occur, and thinking through a solution while coding it. However, that's probably the only useful thing I've learned from XP.

And I'm not convinced that it's more productive than setting up an API first, and having two programmers work on a project separately. I guess it depends on what's important; because it doesn't scale linearly, XP will require either more programmers or more time for the same project to be completed, period. The quality may be better, but that's about it. And a good spec and some actual testing and code review could probably fix that too.
---
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall

Why does it have to be longer? (none / 0) (#66)
by dodson on Wed Apr 04, 2001 at 08:49:02 AM EST

Your assumption that it has to take longer to code this way puzzles me. Are you talking about time from spec handed to programmer to end of project. Or are you talking overall project time.

I disagree either way. I am working on a project now that has adopted several of the aspects of XP in varying degrees. The project is progressing very nicely. We are working in a ObjectScript in a Intersystems/Cache database, with a Java/XML/XSL front end. Pair programming is very helpful spreading an understanding of how the system interfaces.

I find it interesting that the article is written suggesting you have to do all of XP. You can pick and choose and still see improving results.

[ Parent ]
Why longer... (none / 0) (#70)
by pb on Wed Apr 04, 2001 at 09:19:29 AM EST

Simply put, if you have one person coding and one person dictating, instead of two people coding, then it'll take longer. Of course, if you haven't figured out what you're doing yet, then you shouldn't be coding that part yet; you should be brainstorming and firming up APIs. However, that's the nice thing about having a Spec.

In the statistics I saw on pair programming, overall quality was increased, as was productivity. But once you took into account that there were two people working on a project instead of one, well, it all fell apart. There was definitely a benefit of having two programmers instead of one, but not enough to warrant the loss of an extra programmer who could be doing another task.

So, programmers don't scale linearly. It was more like a sqrt(2) kind of thing. And I'd wager that as you summed them, it'd continue to be like that. (3 programmers => sqrt(3) productivity) Consider that to be my ad-hoc law of throwing programmers at a problem...
---
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]
This assumes full time pairs (none / 0) (#104)
by dodson on Thu Apr 05, 2001 at 10:39:39 AM EST

This assumes full time pair programming. If you look at the tenets on XP it explicitly says that your adoption rates of the individual aspects can vary.

We do limited pair programming. So far, an afternoon or morning session one or two times a week, with smaller sessions when we are working closely in the same areas.

We are developing a rythm of when it makes sense to pair up and actually solve a problem faster, as well as a more rote half day session that dispurses big picture knowledge quite effectively.

I find I am waiting on others work less when I have a fairly up to date idea of what they are implementing.

[ Parent ]
Pair programming: example session. (4.50 / 4) (#59)
by i on Wed Apr 04, 2001 at 02:52:57 AM EST

Example session

The abstract sez:

f you have heard anything about the Extreme Programming paradigm, you have probably heard of one of its most novel practices - pair programming. In pair programming, two programmers sit down side-by-side to write code together. One person drives the keyboard and the other one offers a kind of instantaneous code review. Sound weird? It doesn't have to be; in fact, it can be fun. This article shows what it might be like to participate in a pair programming session. It also demonstrates, in a roundabout way, that two heads really can be better than one.



and we have a contradicton according to our assumptions and the factor theorem

Collective code ownership & interchangable coders (3.00 / 1) (#60)
by Pseudonym on Wed Apr 04, 2001 at 04:15:33 AM EST

Collective code ownership is a very misunderstood part of XP. People read it and think that the idea is to turn programmers into drones. This is not the point. The whole idea is that if programmers are interchangable, they can pick up the jobs that they personally want to do. Really, that's it. If you're not tied to one subproject, you don't have to keep doing it once it's gotten boring.


sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
The nature of the programmer (4.00 / 3) (#62)
by Pseudonym on Wed Apr 04, 2001 at 04:23:02 AM EST

A quick question to malifecent: Have you ever read Weinberg's The Psychology of Computer Programming? If not, I suggest you do. It'll give you some insights on the nature of programmers that will get you some steps beyond what you read in Gamasutra. :-)



sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Thanks for book idea! (2.00 / 1) (#67)
by maleficent on Wed Apr 04, 2001 at 08:49:58 AM EST

I'll be sure to read it. It's on my queue of "to be read" which is actually surprisingly short right now.



[ Parent ]
Fear of communism? (2.50 / 2) (#63)
by thunderbee on Wed Apr 04, 2001 at 04:27:05 AM EST

Do I sense a rampant fear of Communism? The word collectivism is used with a very negative weight. While there is no question that Communism as implemented failed miserably, I should point out that Free Software is definitely a form of Socialism (in that you come to share resources without monetary reward).

<RANT>
This is sooo US of A! The article is well written, on a subject that is very worthy of attention and debate, but the author focuses on the fear that since the method involves working in group(s) it certainly is a loss of freedom.
</RANT>

I'm not a Communist, I do code, and have been doing both solo work and team work.

Team work is efficient if done intelligently. There is no point in having people work some way if they don't want to. But it seems clear to me that two (or more) people working together (and meaning it) achieve more than the same two working on their own.
In fact, we sort of achieved the very work methods described in XP, because they mostly make sense. There is no need to force a working method on people. They naturally come to work in the most efficient manner by themselves, changing what needs to be changed, keeping the rest.

I'm talking about mature, intelligent people here. Not meaning to start a flame war, but I often come upon really immature comments aroud here; far less than on /. though ;-)

I firmly believe (and actually live this everyday) that a team of real good geeks (the real ones, not sociopath l33t script kiddies, or script grown-ups for that matter) will by themselves rearrange until some kind of efficiency is reached. This will definitely vary depending on individuals, as each will give and take from the group.

In this I'll disagree with XP: I do not believe in forcing a work method on people. Maybee simply suggesting guidelines to the youg ones, and watching the group adapt and learn. But the individualist approach is a doomed one. What large (and successfull) project was ever carried out by a single person?

Anyway, I'll +1 the post because however biased the view I believe it is worth talking (I didn't say 'sharing ;-) about.

Or just fear of collectivism? (none / 0) (#96)
by sigwinch on Wed Apr 04, 2001 at 08:04:25 PM EST

Do I sense a rampant fear of Communism? The word collectivism is used with a very negative weight.
I don't know if that's the real issue. Some people like being given a task that *they* are to accomplish. They go off, do the work, and come back for another assignment. E.g., if you tell such a person to "build a wall", they will happily mortar together the bricks into a wall. If you say "You and Bob build a wall", it'll just bug them. How Bob twists the brick to set it in the mortar will seem wrong to them, every time they see it. They'll move around like seems reasonable to them and always be stepping on Bob's feet.

I think it boils down to "People are different" more than a fear of Soviet programming practices.

--
I don't want the world, I just want your half.
[ Parent ]

Good for FP, but have you read the literature? (3.50 / 2) (#65)
by slaytanic killer on Wed Apr 04, 2001 at 05:20:17 AM EST

The three XP books state clearly when these methods should not be applied; they are just a self-reinforcing set of "best practices," like unit testing. They never struck me as dogmatic.

You should read again what unit testing is all about; it is very much in the spirit of invariants and assert()'s. Every manufacturing company uses them for real-world parts. The great importance of these tests come mainly when you're trying to scale upward.

My thoughts on XP (3.00 / 2) (#68)
by retinaburn on Wed Apr 04, 2001 at 09:08:25 AM EST

I have issues with the 6th and 8th tenant. In today's market programmers are in and out of a company on regular basis. This means that there is serious holes in knowledge of the codebase, both where it has been (including what has been tried) and where it is going.

Allowing someone free range to fiddle with any piece of the code they wish sounds good but may not work in practice. You could have one piece continuously going back and forth as two programmers try to fix it, each undoing the others work. Communication about a codebase is hard enough, relying on it heavily is a dangerous move to make.


I think that we are a young species that often fucks with things we don't know how to unfuck. -- Tycho


Definately more productive, but... (4.00 / 2) (#71)
by muggy on Wed Apr 04, 2001 at 09:50:59 AM EST

That doesn't mean that I like it.
I first encountered XP at my current job. At first, having some other coder (sometimes one that you don't particularly like) sit on your shoulder was really strange. I'm reasonably extroverted, but I'm one of those you'll-see-it-when-I'm-finished kind of coders and writers. But I have to admit that the code we produced was damn good and the project was finished ahead of schedule. I'm not sure I really liked working that way, but the benefits to an employer are pretty obvious. Funily enough, we've totally dropped XP in favour of a Waterfall method (bleugh) because of totally new management. Just as XP is gaining critical mass, we move away from it.

Individualism is overrated (4.33 / 3) (#72)
by henrik on Wed Apr 04, 2001 at 10:30:06 AM EST

You come from a culture that greatly values individuality (myth of the self made man, the lone hero walking off into the sunset, etc. The whole culture is absolutly filled with the myth of the absolute power of the individual). In a wider perspective, this is a fairly rare trait among cultures - most favor cooperation and consensus. Strong value on "individuality" is mostly found in developing cultures (new fronteers to explore) while "collectivism" is more common in extablished cultures where most resources are already allocated.

So what has this to do with programming? It wouldnt suprise me if the profession of programming were to follow the same pattern: As it gets older less value is placed on individual mavericks going off and doing what they want and more on cooperation. Most programming methologies (XP is fairly loosley controlled as far as they go) are rules for individuals to follow to work together for the greater good of all (hmm.. where have i heard that phrase before? :).

US Culture greatly overestimates the value of individual effort and has a rabid fear of anything that could be remotely connected to communism (as another poster pointed out). Sorry, but life isnt that simple. Cooperating isnt evil. Neither is it a magic bullet to fix everything. But throughout human history "collectivism" has created a lot more than "individualism" (which is mostly found in a transition phase from one stable society to the next). Just think of any building - how stable would it be of the engineers refused to talk to the architect or if the welders would have nothing to do with the concrete guys?

I find you claim that a large majority of programmers are introverted weak. Briggs-Meyers is more of a toy than anything else, but even if we assume it's correct - i dont see how being introverted would interfere with XP methology. Remember, XP is mostly for small (2-10 people) groups. It's as absurd to claim that being introverted would stop one from talking in XP sessions as saying that most programmers are afraid to spreak with their friends.

First of all: I dont see any base for the assumption that a "individualist" approach is any better than a "collectivist". I seriously doubt a bunch of non-communicating individuals will do better than a dynamic cooperative group of the same size. Programming is hard, and as systems get larger and larger the need for a controlled approach is greater. There's a lot of cultural prejudice in this article.

The fact is that the current programming methology (which you seem to advocate) is a stunning failure! Most projects never ship and those who do are bugridden and unstable aswell as overbudget and late. There are very few successful software projects. Clearly we aren't doing many things right. I find XP a refreshing approach to a very hard problem.

-henrik

Akademiska Intresseklubben antecknar!

And yet here we are, at the top of the world.... (none / 0) (#75)
by korc on Wed Apr 04, 2001 at 11:24:54 AM EST

We aren't the largest nation in the world, we aren't the richest (per capita) nation in the world, but here we are in the economic and political lead...why?

Because we have more individuals out there willing to give eveything they have for an ideal.

Current programming strategies suck, I grant that. XP is an improvement. But you are sorely flawed in your thinking that if we all "collectively" cooperated, the world would be a better place.

Nothing truly brilliant has ever come out of a committee. One person, with a single vision, has brought each of the brilliant things of this world into being. Group efforts provide the filler of life, brilliant efforts provide the part worth living for.

There is a place for cooperative work---in the trenches. After the vision has been laid out, the work to proceed is best done in small groups being lead by that person with the vision. But there has to be that vision at the head of it, to drive it and do his best not to let it be diluted.

Note I said cooperative, not collective. I would never work for a collective "hive" mentality that you seem to be expressing, purely because I care about me, my friends, my family, but I let everyone else take care of themselves. I take care of my own, you take care of yours. It's the most efficient way.

Our conclusion is the same---that XP will be good overall. I know from personal experience that working towards a goal with one other person is extremely efficient, if the match is good. But your way of thinking, in my opinion, is coming from exactly that which isn't working---mass collectivist programming groups.


korc
[ Parent ]
Yes, But at what cost? (none / 0) (#78)
by henrik on Wed Apr 04, 2001 at 11:56:28 AM EST

Well - i was a bit onesided in the post. I certainly have my cultural biases awell.

Nothing truly brilliant has ever come out of a committee. One person, with a single vision, has brought each of the brilliant things of this world into being. Group efforts provide the filler of life, brilliant efforts provide the part worth living for.

Right. Agree completly.

Note I said cooperative, not collective. I would never work for a collective "hive" mentality that you seem to be expressing, purely because I care about me, my friends, my family, but I let everyone else take care of themselves. I take care of my own, you take care of yours. It's the most efficient way.

Mmm.. i'm not so sure about that. For the US society of today, yes, it's probably so. But the each-man-for-himself attitude isn't very common if you sample all cultures.

The US is starting to experience the downsides of the individualistic ideology aswell - the complaints about "big business" so common on k5 and /. is (to me) a symptom that letting everyone do as he pleases may not be an optimal solution for all cases.

BTW, as an interesting sideline: Some words are very emotionally charged, usually positive or negative. In most of Europe "Socialism" is a very positive word, in the US it's negative. "Communism" is neutral to slightly negative in EU while *strongly* negative in the US. "Capitalism" is a strong positive in the US while it has a negative value in EU. Interesting is that the rethoric sounds the same - once you substiture "socialism" for "capitalism" the EU documents sound like something out of the US. Works the other way around too. In fact, i'd say that "capitalism" on the your side of the pond is used (emotionally) almost exactly the same as "socialism" is here.

Anyway, that has very little to with XP. I'm glad we agree on that atleast. Since XP is mostly intended for small groups (when used properly) the difficulties of managing a large group isn't all that big, and the whole individual vs. the collective issue isnt as major as it will be when the groups grow. I'm afraid the question of how to efficently organize a large group of people is yet unsolved :)

One interesting approach would be to allow the "geniuses" of the group to build a solid, clean, extensible, wellwritten, easy-to-understand framework and then allow grunt coders to fill the framework with easy-to-write code. Of course, the geniuses of the group has to really be that or the whole thing falls apart.

-henrik

Akademiska Intresseklubben antecknar!
[ Parent ]

Re: Yes, But at what cost? (none / 0) (#95)
by korc on Wed Apr 04, 2001 at 06:15:09 PM EST

Mmm.. i'm not so sure about that. For the US society of today, yes, it's probably so. But the each-man-for-himself attitude isn't very common if you sample all cultures.

I've never believed consensus was the best thing, but then my definition of best does not include what's good for everybody. I can see how an objectivist view would be construed as each-man-for-himself, but that's not really it, at least for me...I don't act as though it's me against everyone else but more like I want us all to go forward under our own power and after our own rewards, not hitching a ride on social inertia and for the public good (or in the corporate world, pushed in directions we don't want to go for somebody else's profit). I picture it much like a multiprocessor machine---but one where each has different ideas of what is a goal. Control for SMP's a bitch for more than few processors, but when it's working for those few, it's magic.

Wow...ok, getting totally OT...

The US is starting to experience the downsides of the individualistic ideology aswell - the complaints about "big business" so common on k5 and /. is (to me) a symptom that letting everyone do as he pleases may not be an optimal solution for all cases.

I have to disagree with you here---"letting everyone do as he pleases" I think is the only way you achieve the best end-product...very Darwinian. I've always believed the most stable system is based on a stable structure and then let alone. Right now ours is not stable purely because everyone has their hands in your pocket, or your rights. Behavior that's good for everyone will evolve, because that's a stable system. MHO, of course.


korc
[ Parent ]
Death by committee (none / 0) (#98)
by sigwinch on Wed Apr 04, 2001 at 09:20:05 PM EST

Nothing truly brilliant has ever come out of a committee. One person, with a single vision, has brought each of the brilliant things of this world into being. Group efforts provide the filler of life, brilliant efforts provide the part worth living for.
Hear, hear! My sentiments exactly. (At least regarding conventional committees.)
There is a place for cooperative work---in the trenches. After the vision has been laid out, the work to proceed is best done in small groups being lead by that person with the vision.
But I think that's taking it too far. For tough or complex problems, several minds looking at it from different views can be much more productive by collective effort, even in the design stages.

As an example, consider the design of an air traffic control system (software, computers, and radars). One person cannot know enough to singlehandedly come up with the "vision". It's gonna take a lot of people with a variety of skills *just to understand the problem space*, nevermind writing down the architecture. If those people don't work together closely on the project goals, it'll be a disaster. And I don't just mean some sort of minimal cooperation, I mean wholehearted focus on helping each other develop the architecture. (Of course, the optimum size depends on local politics and the available people. Having more than one person architecting doesn't magically improve a project.)

Note I said cooperative, not collective. I would never work for a collective "hive" mentality that you seem to be expressing, purely because I care about me, my friends, my family, ...
Collective != selfless worker bee sacrificing everything for the good of the hive. Collective == doing something that benefits a group you are part of (and if it has direct benefits for you, all the better).
... but I let everyone else take care of themselves. I take care of my own, you take care of yours. It's the most efficient way.
If ultra-individualism were truly the most efficient way, there would be no cities, and nobody would want to be in a city. But there are, and people do, precisely because having other people around is a benefit in and of itself. One way of looking at contract and property laws is not that they protect individuals, but that they protect the collectivist system from denial of service attacks (by overly greedy people). In the same way, a healthy collective protects itself from deranged bureaucrats and their five year plans by encouraging enterpreneurs. At least in an industrial society, I don't see sharp lines between individualism and collectivism.

--
I don't want the world, I just want your half.
[ Parent ]

Re: Death by committee (none / 0) (#107)
by korc on Thu Apr 05, 2001 at 01:54:55 PM EST

This isn't the place to have this particular philosophical discussion, primarily because we all tend to agree on the benefit of XP and that's what this was originally about. My previous comments were rather hastily sent off without much supporting argument because of time, but I was mainly objecting to henrik's overall approach to it; to me XP's more efficient production over large groups of programmers is in fact a downfall of the communal way of doing things, where an individual fits into a puzzle but isn't made to feel as though his work is meaningful. (Think Office Space, the movie) In a smaller group your voice (your individual voice) can be heard better and your creativity can be more appreciated, and thus your enjoyment (==reward) increases.
There is a place for cooperative work---in the trenches. After the vision has been laid out, the work to proceed is best done in small groups being lead by that person with the vision.
But I think that's taking it too far. For tough or complex problems, several minds looking at it from different views can be much more productive by collective effort, even in the design stages.

As an example, consider the design of an air traffic control system (software, computers, and radars). One person cannot know enough to singlehandedly come up with the "vision". It's gonna take a lot of people with a variety of skills *just to understand the problem space*, nevermind writing down the architecture. If those people don't work together closely on the project goals, it'll be a disaster. And I don't just mean some sort of minimal cooperation, I mean wholehearted focus on helping each other develop the architecture. (Of course, the optimum size depends on local politics and the available people. Having more than one person architecting doesn't magically improve a project.)

Again here, I didn't elaborate. I think XP can be scaled to organization-sized projects with ease---the trick, and this is the crucial factor, is that each member of this vast organization dedicated to some grand goal receive the reward that keeps them motivated to do the work. The completion of the goal is special, yes, but each member of the team must feel they contributed in a significant way, and that's much easier to achieve on a personal level in small groups.

Of course something like a space shuttle can't be built by one person, and there were countless design decisions made by countless people on that project---definitely not arguing that.

Note I said cooperative, not collective. I would never work for a collective "hive" mentality that you seem to be expressing, purely because I care about me, my friends, my family, ....
Collective != selfless worker bee sacrificing everything for the good of the hive. Collective == doing something that benefits a group you are part of (and if it has direct benefits for you, all the better).
... but I let everyone else take care of themselves. I take care of my own, you take care of yours. It's the most efficient way.
If ultra-individualism were truly the most efficient way, there would be no cities, and nobody would want to be in a city. But there are, and people do, precisely because having other people around is a benefit in and of itself. One way of looking at contract and property laws is not that they protect individuals, but that they protect the collectivist system from denial of service attacks (by overly greedy people). In the same way, a healthy collective protects itself from deranged bureaucrats and their five year plans by encouraging enterpreneurs. At least in an industrial society, I don't see sharp lines between individualism and collectivism.

I may have misspoken here; my statement mixed personal and professional views. On a personal level, I'm not out in the woods living on squirrels here---I am part of my local society and carry my weight, but I expect others to do so too. If my friends are in (say, financial) trouble, I'm there to help, but I firmly believe you have to draw the line outside your circle of friends. I'm old school here---I don't want to be a burden to anyone else, including the government, which I picture as the rest of the people of the country, not a separate entity.

On a professional level, I'll just say what I said above---the grand goal is fine, but each worker must believe his work is important to be happy in it and garner his own rewards. In our society as it has grown this century, he has to be an individual, not a cog.



korc
[ Parent ]
Then the developer will leave (none / 0) (#79)
by ubu on Wed Apr 04, 2001 at 12:01:19 PM EST

Individualism runs in the blood of the productive developer, in my opinion. If you got anywhere in IT so far, chances are you made it there by your own blood, sweat, and tears. There are plenty of mediocre performers in software, to be sure, but they just highlight the difference: those whose individual spirit made them doggedly inquisitive and productive are those who excel in technology.

The direct consequence of programs that eliminate individualism in technology will be to expel the type of individual who currently makes software development possible. Perhaps the managers, "process" people, and Certified Engineers will find a way to pick up the slack; perhaps their methods will magically create a new breed of productive worker. But I seriously doubt that.

Ingenuity is a property of individuals. Ingenuity does not arise from processes, methodologies, and assembly lines. It really is no fault of higher-ups that they are looking for ways to streamline and improve efficiency; it's their responsibility and I don't oppose it. But I believe that in their traditional, grotesque manner they have chosen the most important traits of the software developer for sacrifice on the altar of Progress. The charismatic individual is the goose that lays the golden egg in technology and in industry, and for some reason the Collective is determined to slaughter it.

Ubu


--
As good old software hats say - "You are in very safe hands, if you are using CVS !!!"
[ Parent ]
Hmm.. (none / 0) (#80)
by henrik on Wed Apr 04, 2001 at 12:15:03 PM EST

Individualism runs in the blood of the productive developer, in my opinion. If you got anywhere in IT so far, chances are you made it there by your own blood, sweat, and tears. There are plenty of mediocre performers in software, to be sure, but they just highlight the difference: those whose individual spirit made them doggedly inquisitive and productive are those who excel in technology.

Agree again. Individuals learn individually. I've picked up programming myself and learning it collectivly (like in a school envorment) just isnt nearly as effective.

What i'm saying is that those coders could be a lot more productive (aswell as have more fun) if they just talked more and shared code. Sounds a lot like OSS code to me. A group working together != one person controlling every thought and killing anyone who does things differently.

-henrik

Akademiska Intresseklubben antecknar!
[ Parent ]

reply (none / 0) (#85)
by ubu on Wed Apr 04, 2001 at 01:34:31 PM EST

Like OSS? Sure. But OSS is composed of willing individuals writing their own rules. There really isn't a canon of prescriptive processes for running an OSS project. And that, I think, is the fundamental difference I have with any project methodology: it is prescriptive, generalized, and utterly incapable of adaptation without the active participation of really clever individuals.

It's sort of a chicken-and-egg issue. I don't think you can make any methodology work correctly without the spirit of individuality that motivates the developer. But if you can assume productivity and a spirit of individual achievement... do you really want to drag around a methodology?

Again, I don't argue with efforts to improve productivity, per se. It's just that what I see in most cases is actually counter-productive "improvements". I really don't see XP as an exception. And the cultural difference over individuality may be 100% valid but I can't support your conclusions.

Ubu


--
As good old software hats say - "You are in very safe hands, if you are using CVS !!!"
[ Parent ]
Re: reply (5.00 / 1) (#88)
by henrik on Wed Apr 04, 2001 at 02:55:18 PM EST

Like OSS? Sure. But OSS is composed of willing individuals writing their own rules.

Right. And so is any good project organized.

There really isn't a canon of prescriptive processes for running an OSS project. And that, I think, is the fundamental difference I have with any project methodology: it is prescriptive, generalized, and utterly incapable of adaptation without the active participation of really clever individuals.

True, but this is mostly a fault of overzealous managers beliving too much in one methology. "The pragmatic programmer" (ISBN 0-201-61622-X) spends 300 pages telling you what should be common sense. A large part of XP is also the same way - also should be noted that the XP authors themselves dont think XP is a good solution for everything. There's nothing saying that you should mindlessly apply all of XP - go with the parts that make sense and dont use the rest. (except testing. testing shouldnt be optional) :)

It's still a silly name though...

-henrik

Akademiska Intresseklubben antecknar!
[ Parent ]

*laugh* (none / 0) (#93)
by ubu on Wed Apr 04, 2001 at 03:33:13 PM EST

It's still a silly name though...

On that point you will get no argument from me.

Ubu


--
As good old software hats say - "You are in very safe hands, if you are using CVS !!!"
[ Parent ]
XP doesn't kill individuality (none / 0) (#81)
by cezarg on Wed Apr 04, 2001 at 12:17:28 PM EST

and neither does it prescribe streamlining or "software assembly line". It is the opposite of what all previous "processes" were all about. This one actually focuses on hackers and how to make their work more effective. I'd like to refer you to my eariler comment to help you understand how XP is meant to work and why.

[ Parent ]
I agree to disagree (none / 0) (#84)
by ubu on Wed Apr 04, 2001 at 01:28:10 PM EST

I do think that XP discourages individuality, and my main complaint is that it is prescriptive, like most other methodologies. Little "do this" and "do that" prescriptions may turn out to be helpful in the long run, but a comprehensive, prescriptive program just ends up getting in the way of productivity. Sure, I believe it helps certain workflows and teams. But my suspicion is that successful XP adopters owe their success to their own ingenuity and experience, rather than to the XP regimen, itself.

Ubu


--
As good old software hats say - "You are in very safe hands, if you are using CVS !!!"
[ Parent ]
Wanted more talented Individualists (none / 0) (#111)
by dodson on Fri Apr 06, 2001 at 04:27:51 PM EST

No matter how talented an single developer is, he is not creating as much value as he can for his employer if he doesn't have the ability to make others around him more productive.

And I'm sorry programming is not an art, it is applied science. And commercially acceptable does apply. As a professional programmer you are not paid to create lines of code with atomic elegance. You are paid to solve problems. Business problems almost always have a short half-life.

This is the value of a method that values simple solutions and collective ownership. It's up to great programmers to contribute their excellence and raise the productivity of less skilled programmers so that the sum of the whole is greater than that of the parts.

Enough out of me....


[ Parent ]
Oh, indeed! (none / 0) (#112)
by ubu on Fri Apr 06, 2001 at 05:15:36 PM EST

No matter how talented an single developer is, he is not creating as much value as he can for his employer if he doesn't have the ability to make others around him more productive.

I feel 100% certain that developers will create as much value for their employers as they are compensated for. In the meantime, the supply of developers who excel at their assigned tasks will flourish only as long as the developer is respected for his own work, not on his accountability for others who are not, and never were, his responsibility.

I know very well that the Grand Wet Dream of managers and other social engineers is to create a Nietzschean Superman Programmer who toils endlessly for no reward and for no credit, and who delights his coworkers by coddling their deficiencies while -- at the same time -- managing to fulfill his own herculean assignments on time.

I bid you the best of luck in creating this utterly inhuman creature. I hope you find him as palatable as you expect.

It's up to great programmers to contribute their excellence and raise the productivity of less skilled programmers so that the sum of the whole is greater than that of the parts.

Come to think of it, I've met those people! They run around under several disguises: "contractor", "consultant", "departmental guru"... I've even seen them prancing about as managerial staff. They're a funny sort (I've even been one for a while) but in general they fail -- whether by incompetence or by virtue of impossible duty -- to achieve much of anything of consequence. Least of all "raising the productivity of less skilled programmers".

Ubu


--
As good old software hats say - "You are in very safe hands, if you are using CVS !!!"
[ Parent ]
A few comments.... (5.00 / 1) (#73)
by guinsu on Wed Apr 04, 2001 at 11:08:05 AM EST

It seems that just like on Slashdot, people have to rail on XP without ever having tried it. Now, I'll admit I haven't tried it either, but I want to. It just a little hard when you are the only programmer at your own company of 4 people :)

Anway a few issues I noticed with what you wrote:
The second tenet of extreme programming is small releases, in which the product is released on a very regular basis, with very short cycles between releases. ....A disadvantage is the hassle of a repeated build cycle which makes it hard to focus on a particular piece uninterrupted for a period of time; one can't simply work on one piece for a week without having to worry about a regular build cycle.

Actually, due to the way all testing and integration should be 100% automated it is supposed to be very little of a hassle. It is only supposed to take 10 minutes, you can use that time to get yourself a cup of coffee or a coke. Plus, as was pointed out in the books, the longer you wait to integrate a programmers code, the more problems you have getting it to work with everyone elses code.

A fourth tenet of extreme programming is simple design, which basically requires that the simplest program that fulfills the requirements is the one delivered. This is very difficult to analyze on a collectivist/individualist level, as it reflects an overall choice in program design. However, I feel that it is definitely a short term improvement but a long term loss over the alternative, which is designing for the future with extra code written in to provide hooks for future code adaptations.

I belive the creators/users of XP find that it is actually easier to refactor code later than to build in hooks that you might not need or that might need to be re-written.

A fifth tenet of extreme programming, testing, basically encourages the writing of code to pass tests and leaves it to the customer to provide tests that properly reflect their needs from the software. Again, this is a tenet that is difficult to judge on a collectivist vs. individualist perspective. It's clear, again, that it's a fallacy for a long term approach, as regularly-used software will soon begin to take on needs that testing can't accurately portray.

There are two types of testing, unit testing and acceptance testing. Unit testing is guaranteeing that every class/module/whatever in your code doesn't break no matter what you throw at it, no matter how your users use the software. Obviously there will always be some bugs, but this seems to squash a ton of them. Plus even if people start using your software in a different way (I think thats what you meant at the end there), the lack of bugs certainly won't get in their way.

The other type of testing is acceptance testing, which from what I remember is more of a high level design that the program does what its supposed to do, it meets your clients specifications that were given to you on all those index cards. How is giving the customer what they ordered bad for the future? This is a win in the long and short term. If in the long term you need more/different functionality out of the software, you just send it back to the programmers with more stories on index cards. And since they should be really good at refactoring by now, they should be quicker than a traditional programming team. If the design was done traditionally where you didn't have tests for whether things were done/correct or not, how does this help you in the long term? Low quality code is never a plus.

The sixth tenet is refactoring, which is a clearly collectivist approach. It requires a clean code base with no duplication and demands a high level of communication about the code base. The group must work together to protect and clean the code base, regardless of how individuals feel about the approach.

Remember, this is your CUSTOMERS code and you are paid by your BOSS to work on it. I think so cleanliness and neatness standards are appropriate. Engineers and architechts (sp) have been doing this for years and yet they have room for individuality, otherwise you'd never heard anyone refered to as a "brilliant engineer". Plus are you saying a clean code base and a high level of communication are BAD?

I was going to go through a few more, but this is getting long. Really, XP sounds like a very good thing that so many people have a gut-level reaction against without every trying it. The thing is it has worked on several projects already, whereas we've all seen the end products of the traitional development methods.

more on simple design (5.00 / 1) (#92)
by kubalaa on Wed Apr 04, 2001 at 03:31:45 PM EST

I belive the creators/users of XP find that it is actually easier to refactor code later than to build in hooks that you might not need or that might need to be re-written.

To add to this excellent point; "Design" goes beyond hooks and planning. It is an aesthetic principle, it means identifying and coding the "essence" of the task. You go with the most clear conceptual framework for what you need to do. It doesn't always mean go with the least code, because the simplest design is the most consistent, and the most consistent design will mean generalizing things which could be done more easily with exceptions.

If your design fits the task at hand, then it will lend itself naturally to extension in all likely ways. And because it is simple, with no extraneous parts or mysterious irregularities, it will be obvious how to change it to accomodate unexpected needs.

Anytime you are simply coding hooks without attending to the core design, you are contributing to overcomplication that will cost time whether you eventually use the hooks or not. And anytime you are refining the core design, you will find that the hooks you really need will develop themselves.

[ Parent ]

If the average programmer is an individualist... (4.83 / 6) (#74)
by linus nielsen on Wed Apr 04, 2001 at 11:21:00 AM EST

...then the average programmer isn't very good.

I have been a professional programmer for over 10 years, and I have met many programmers over the years. I can say that the absolutely worst examples of bad code that I have seen were written by individualists who never ask for help. They could sit in their corner for days, struggling to solve a problem that could easily be solved with a 5-minute discussion with a fellow programmer. I have worked with pair programming in several projects, and it has always resulted in more fun and better code.

OK, so I may not be the average coder when it comes to individuality, but I want to say that the average coders I have met so far really would have benefitted from pair programming.

Threesomes are good too ;) (5.00 / 1) (#83)
by pallex on Wed Apr 04, 2001 at 12:59:50 PM EST

I think some people are under the impression that companies hire programmers to allow then a space to express their individuality. They dont, they hire them to write code.

"If only Management (spit) would allow me to come to work at 1 oclock in the afternoon, wearing ripped jeans, arse about juggling, net-surfing and solving the worlds problems at the coffee machine, then stay late to do some actual work, they`d see what i can really do! They just dont understand me. Just like my parents. Its so unfair!"




[ Parent ]
Hear, hear (1.00 / 1) (#97)
by persimmon on Wed Apr 04, 2001 at 08:56:37 PM EST

My last CS class required us to work in pairs. My partner and I sat together and took turns typing. We caught SO many trivial errors as we were writing. Even when we weren't working on the same section of code it helped enormously to have someone to bounce ideas off of. I think it also helped that we debugged each other's code together, shielding us from the "my code is sacred" syndrome.
--
It's funny because it's a blancmange!
[ Parent ]
Good luck selling this to management (4.00 / 1) (#77)
by BackSlash on Wed Apr 04, 2001 at 11:53:22 AM EST

I've been in software development for about 5 years now, and the toughest thing for me to understand (other than why I have to be here at 8:00 am) never had anything to do with a project - it was the attitude of managers.

As long as there was code on my screen - any code - I was doing 'work'. Anything else, including discussions on the finer points of object binding, was water-cooler material. I guess object interaction is to us geeks, what football is to the PHB.

To the Teeming Millions of PHB's, the development process is a lot like league bowling. It's a group of indiviguals making up a team, rather than a team made up of a group of indiviguals. Your teammates are there for support and advice, but ONE guy throws the ball. (I would add that,like bowling, consuming copious amounts of beer improves performance, but I digress)

If the Boss-Man saw, horror of horrors, 2 people in a cube developing TOGETHER, his first reaction isn't Sesame-Street flavored coorperation, it's 'paying 2 people for the work of one'. Do you see Accountants huddled together over Accounts Payable? Not unless there's a problem.

I have asked.. begged for daily peer reviews. No one wants to bother. And when I do get them, they are always about style. 'int instead of i','2 space tabs instead of 4', and my personal favorite,'WHAT is foo?' What does this do for code quality? Did they even COMPILE what I did?

XP tries to take software development out of the dungeon where a few independant mad scientists work on it, into the light, exposed to the yardsticks of progress and functionality, on a regular and constant basis. And while I don't agree with everything about it (I too enjoy 16 hour hacking binges with my Mtn Dew, MGD and mushroom pizzas) there are many interesting points, especially the programming in pairs concept. And like every other innovative process, good luck getting YOUR PHB to see beyond the duplication of resources.

just one nitpick (none / 0) (#89)
by kubalaa on Wed Apr 04, 2001 at 03:16:53 PM EST

Okay, this isn't really the point of your post, but I have to comment:

I have asked.. begged for daily peer reviews. No one wants to bother. And when I do get them, they are always about style. 'int instead of i','2 space tabs instead of 4', and my personal favorite,'WHAT is foo?' What does this do for code quality? Did they even COMPILE what I did?

Style is important. There are limits, of course, (2 tabs instead of 4 being silly), but other seemingly trivial things like the placing of braces can make code frustrating to read if they're done inconsistently. It's the brief extra pause it takes to assimilate the change in style. And "What is foo" is probably the most important question that can be asked of code; each line of code describes some action, and the more descriptive it is, the easier it is to read and understand. Any place you use a variable without a clear name, your description of the action for that line---namely what the action operates on---is vague and takes extra work to understand. Not to mention that if you can't come up with a concise name for a variable, you're probably unclear on its function yourself and need a clearer design.

I liken it to language. If you read an essay full of awkward grammar, bad spelling, and poor word choice, it doesn't matter if it contains a brilliant, well-developed argument. It's still no fun to read.

[ Parent ]

Re: Style (none / 0) (#102)
by BackSlash on Thu Apr 05, 2001 at 09:03:53 AM EST

I agree that style is important. The awful habits of old C programmers are one reason C code can be soooo dizzying to read. (i,j,k for loop vars,obsessive use of void *'s, etc..) But what I'm looking for in a code review is a review of my methodology, functionality, even code-writing productivity.

Spaghetti code isn't fun, speaking as one who has had the misfortune of forced-code maintenance of billion-year old apps. But sometimes there are variables that are pretty meaningless. Loop vars, for example.

Fill in the blank (in Basic syntax): for ____ = 1 to 10 ... next. Do you use i? LCV? Idx? Counter1? Foo? Does it really matter?



[ Parent ]
variable naming (none / 0) (#113)
by kubalaa on Sun Apr 08, 2001 at 03:17:33 AM EST

Fill in the blank (in Basic syntax): for ____ = 1 to 10 ... next. Do you use i? LCV? Idx? Counter1? Foo? Does it really matter?

Well, depends what you're using it for. If you're looping through an array of strings, you might call it str_ary_index. If you're just doing something 10 times, you might call it rep or step. It's a small difference, but sometimes it matters; like calling it "offset" tells you a whole lot more than "i". But then, I'm one of those types who sees nothing wrong with long names like db_recordset_iterator_key if there's any chance of a shorter name being unclear or confusing.

[ Parent ]

Hmm. (5.00 / 2) (#86)
by azul on Wed Apr 04, 2001 at 01:43:07 PM EST

I don't know, this whole article seems just one attempt to ditch extreme programming. At first I thought it might show some interesting points about why extreme programming tends to make programming a more collective activity, but it soon became evident than the real thesis in the article was that it is bad, and the whole talk about collective is just one argument for it.

Which is not to say that the article was bad. It was a good read and I'd like to thank its author for taking the time of writing it and publishing it.

I would just like to raise a few issues on which I disagree. I'm not a proponent of extreme programming, but there are a few things on it that I strongly agree with.

Disclaimer: All I know about extreme programming is what I read about it on a good web site (can't remember which) for around 30 minutes sometime ago.

The author seems to see the "simple design" tenet of extreme programming as a bad thing. I see that as one fundamental principle in software design and evolution. The author states that simple designs are very good in the short term but "a long term loss". He goes as far as to say that "it's clear that for a long-term project with changing requirements that [sic] simple design as extreme programming demands is not feasible."

As Einstein said, "Everything should be made as simple as possible, but not simpler." Or, quoting Antoine de Saint-Exupery, "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away."

So how this relates to programming? Well, programs are nothing but models of reality. As things go down from a design to an implementation, many details are added, but they remain as nothing but models of reality. In my experience with programming, I have found that keeping things as simple as possible and never adding complexity makes software by far easier to maintain. When your requirements change, something in your model (whether it is a working program or just a design) has to change. If you spend energy towards keeping it simple, those coming changes are very easy to perform and don't take as much time as on complex models. I see simplicity as an important feature of good design. The simplest a design is, while managing to do well in reality, the best.

I liken this to theories very much. Given different theories to explain a reality, I will always pick the simplest (given, of course, that both are equally acurate from a practical point of view). It saves hassle.

In the case of programs, I find this simplicity very important and, according to my personal experience, the simplest a program/design is, the easier it will be to work with.

So I find my self in complete agreement with the keep-it-simple-stupid principle.

Of course, depending on where you'll want your model to go, there are many times that you'll have to add complexity. This is okay as it is frequent for your model to grow out of sync with the ever changing needs of the real world, but programmers should spend their time and energies towards simplifing things as much as possible (but no more).

Okay, and now about unit testing. You seem to mention it as a bad thing but I regard it as very useful.

It's clear, again, that it [the tenet of unit testing] is a fallacy for a long term approach, as regularly-used software will soon begin to take on needs that testing can't accurately portray.

I find unit testing and the practice of using preconditions, postconditions and invariants very similar activities. They are -very- rewarding in that they allow you to find the new bugs very fast. There is a very interesting paper on this here

As I see it, the proponents of extreme programming are not advertising writing software to merely pass tests, but rather having tests for all the expected features for the program. So whenever you are about to add a new feature, before you do it you add tests that will only be passed if the feature is working. Of course, this is in no way a substitute for quality programming, but filling your code with assertions, as many as possible (and I see those unit tests as nothing but some sort of assertions), is good. You'll often finish adding a new feature, running the tests and finding out you broke another. Being able to automatically find out that sort of things helps.

I have even worked on programs on which there are parts where I have more lines of code in assertions than I have in actual code. In that particular project (which does simulation of objects in the space, some controled remotelly by different clients and other with simple intelligence of their own), that turned extremely rewarding and helped me to find the problems incredibly fast. I don't even want to imagine how long it would have taken me to find all the bugs I found with straight GDB.

Actually, you may be aware that many programmers use printf as their main debugging tool. When they run into problems on different sections of their code, they fill them with printfs to see where things are going wrong. Using assertions is a similar activity, except you have those printfs everywhere, and they are easier to follow since they only output things when things go wrong (so you don't have to check a MBs big log, tracing the state of the program until the very moment when things started going wrong).

So rather than seeing unit testing as a replacement for good programming, I see it just a tool that does help the programmers. I agree that it is very hard to make good unit tests portraying the needs of complex programs, but that is not a reason to say that unit testing is bad. I have found it incredibly helpful.

On the subject of refactoring, I think it helps simplify things. Duplication should be avoided at all costs. It is as if you had three different physics laws that can be grouped in only one slightly more complex than any of the former three.

Okay, and my final rant will be about making releases as often as possible.

You raise the point that it makes it hard to implement big changes and keeping up with frequent releases ("one can't simply work on one piece for a week without having to worry about a regular build cycle").

I can agree that it can be a hassle having to keep the regular releases working, but one very important principle I have found when programming is to -always- have a working version of the program. When you have to implement large changes to your model, rather than taking a week on which no working version is available and waiting until they whole change is implemented, you should start to make many small changes pushing you to the place on which you want to be in the end. I have found that works a lot better than taking a week to do the whole modification.

Personally, for all the software I manage, I -never- stop programming if a working version is not available. That is, sure, I know of many bugs in some of my programs and not stopping until they are all fixed would take me weeks, which rules it out. But I have those bugs documented and I never stop programming with a version that does not compile/work. I am very hesitant when I have to go through a huge portion of my code making changes that take above two hours during which the code will not compile. That is something I try to avoid at all costs. Instead, I try to make many small changes, so the software evolves and eventually gets to where I want it to be. I find this approach better for managing all the complexity of software since it allows you to focus on small changes at once, rather than a big complex change, and I've found it suits me better than the alternative.

So, as I said at the beginning, I don't really know much about extreme programming but, from the few I have read about it, there are a few points on it that match very well my ideas on how software should be developed.

Thanks.

Alejo.
http://bachue.com/alejo



You people are pathetic! (3.33 / 3) (#87)
by greyrat on Wed Apr 04, 2001 at 01:49:25 PM EST

Programming is an engineering practice, not some woozy-feel-good, leave-me-alone-till-its-done art form.

Development of real world production systems and software requires a group, discipline, order and coordination in order to be done right.

That said, I think most of XP is a load of crap. But if you don't have a methodology in place and XP looks practical to you, implementing it will be better than having no methodology at all.
~ ~ ~
Did I actually read the article? No. No I didn't.
"Watch out for me nobbystyles, Gromit!"

So? (none / 0) (#91)
by hardburn on Wed Apr 04, 2001 at 03:24:28 PM EST

Programming is an engineering practice, not some woozy-feel-good, leave-me-alone-till-its-done art form.

We better tell Frank Loyd Wright that he can't make buildings pretty because architecture is an engineering practice, not some woozy-feel-good, leave-me-alone-till-its-done art form.


----
while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }


[ Parent ]
Sorry Honey (none / 0) (#94)
by greyrat on Wed Apr 04, 2001 at 04:51:11 PM EST

If you had any real knowledge of FLLWs work, you would know that his buildings are beautiful precisely because he understood that architecture was an engineering practice not some woozy-feel-good, leave-me-alone-till-its-done art form.

Go learn about the engineering and innovation involved in the column design for the Johnson Wax building, or the careful planning and design that allowed the Larkin Soap building to have central air conditioning -- long before refrigeration was commercially viable.

Or are you suggesting that Falling Water or any of the west coast precast concrete homes which are crumbling from water intrusion are examples of good design?

Frankie had successes and failures, because he was interested in ENGINEERING his structures, not because he was an artsy wuss that wanted to be left alone to play at creating cool stuff.
~ ~ ~
Did I actually read the article? No. No I didn't.
"Watch out for me nobbystyles, Gromit!"

[ Parent ]
Missing the point (none / 0) (#103)
by hardburn on Thu Apr 05, 2001 at 09:09:58 AM EST

You miss the point. Art and engineering are not mutualy exclusive.


----
while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }


[ Parent ]
No, I Get The Point (none / 0) (#105)
by greyrat on Thu Apr 05, 2001 at 10:48:09 AM EST

I agree that they are not mutually exclusive. They are in fact the same thing.

I am trying point out that great programming is not a mano-a-mano excercise. Truly great/effective/successful/useful programming is a team effort involving much more that one guy in torn jeans working from 11:00am to 3:00am off of requirements stored in his head.

As a hypothetical case in point, what if Wright had not been such a monomaniac? He might have had even more people working with him trying to emulate and further develop his ideas. In that case, his product might have had even more and wider ranging impact.

The same is true of any group effort. Have you ever noticed how fast things happen in the scientific community when people working on the same idea put thier egos aside and collaborate?


~ ~ ~
Did I actually read the article? No. No I didn't.
"Watch out for me nobbystyles, Gromit!"

[ Parent ]
Some practicality is needed (3.50 / 2) (#90)
by hardburn on Wed Apr 04, 2001 at 03:22:46 PM EST

I love programming as an art form, and I do believe that programming is largely an individualist persuit. However, no one programmer could ever code a project as complex as (say) a kernel all on their own. You are forced into a system where you must collect many programmers together to get the project done.

I believe the best system for doing this will be the one that is collectivist only as much as nessary and no more. This usualy means doing what most programmers do in their head, just on a larger scale; that is, break the very large problem into simpler components and hand out assignments. On a small scale, the simpler components are tradtionaly given to individual functions. On a large scale, they are given to individual programmers, who in turn break the problem down further into individual functions. A simple, iterative process.


----
while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }


Pair programming (5.00 / 2) (#101)
by cameldrv on Thu Apr 05, 2001 at 01:46:01 AM EST

I have tried pair programming twice, and I really liked it both times. I think the key is to have the right combination of people. I tend to be on the creative yet less rigorous side. Thus, I can often quickly come up with novel solutions to problems. On the flip side, I miss semicolons, forget to search-and-replace, and other things. When I have pair-programmed, I was paired with someone who had less experience than I did, but was pretty good with details. Thus I coded, and I had the other guy looking over my shoulder telling me when I forgot something.

The other great thing about pair programming is that you have to explain what you are doing to the other guy. This helps me work out kinks in my thinking, and really reduces errors.

Bad starting assumption (none / 0) (#110)
by Dacta on Fri Apr 06, 2001 at 07:50:22 AM EST

Extreme programming isn't about hacking a program together - it's about engineering software systems.

You seem to think that building software the way programmers enjoy is the best way to do it. That's like telling construction engineers to go and build a bridge over a river - and let them choose where to build it and how to make it.

Programmers should be kept happy so they are in a good frame of mind when coding - but having happy programmers isn't the goal of software engineering.

The goal of software engineering is to build reliable, maintainable and effecient systems that meet business requirements as quickly as possible.

Every one of your arguements could be used agains software engineering as a whole - not just extreme programming.

Think about your typical UML-modeled waterfall cycle development project. That restricts the programmer's creativity a lot more than collective ownership does - and believe me, it's a lot more fufilling if (like in extreme programming) everyone gets to marvel over a beautiful bit of code you and your parterner wrote - rather than something in some object that no one else ever looks at.

Oh, and BTW: Software engineering is a collective process.



Extreme programming opposes the nature of the programmer | 113 comments (84 topical, 29 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!