Oh please, not another hax0r artiste.
on
Mob Software
·
· Score: 1
Yeah OK so the guy has serious creds at a code level but that doesn't mean he's automatically right, nor original. I am so tired of these hax0r artise / code poet essays on/.; when will it end?
In my experience you can categorize programmers into the following three groups: lone rangers, uninspired key pushers, and team developers. Lone rangers can be extremely productive on their own and know it, but don't know how to split up work, resolve disagreements, and make sure the important dirty work gets done. The uninspired key pushers are the ones who prove the axiom that a great programmer can be 10x as productive as a bad one. They're the ones who write spaghetti code, use code generating wizards and don't understand how the environment they're programming for works. Finally there are team developers, who may not be as productive alone as a lone ranger but who can actually break up work, debate ideas rather than descending into ad hominem pissing matches, and who get all the work done (not just the fun stuff). I suspect that/. is read by vocal code poets and a horde of lurking team developers. I see the team developers speak up every now and then.
The idea of mob development is not original, but I argue that it's not limited to open source either. You don't have to be an aeronautical engineer to know that a rocket shouldn't blow up on the launch pad. Likewise, commercial software gets pushed on users who definitely have plenty of eyeballs capable of testing software. The sad part is that they pay for the privilege, where in open source at least the helpful eyeballs don't have to pay. Open source has the advantage of allowing outside developers to fix problems, but it's not as though commercial software customers don't notice bugs because they don't have the source.
I strongly disagree with the author in a couple of cases.
The cathedral analogy is completely bogus. This is ESR's fault, and it's a logical fallacy that code poets often use to "prove" that open source code poetry is the One True Path. Cathedrals have very basic requirements compared to a piece of software, and involve designs which were centuries old at the time. Hire an amazing artist to do some art for the cover of your software manuals, retail box, splash screen, etc. Wow, what an incredibly clever development process you've discovered, he didn't introduce any bugs into the product! The glue used to bind the manual smells nice, because you hired a fragrance designer? You are a software development guru now, because that person didn't get in the way of the code being developed. What?? It doesn't make sense because these are very distinct concepts, easy to modularize. To get a realistic comparison, try getting 40 sculptors to work together on the front door, another 20 on the tympanum above the door, 10 on the side door tympanums, and make sure they all coordinate their efforts so everything looks consistent and follows a unifying theme. Now you see how the analogy breaks down.
Gargoyles, stained glass windows, pulpits, they're just ornate versions of everyday objects that everybody already understands. In techie terms, I'm saying is that a Cathedral is not only a highly modularizable design, but that the interfaces between modules are minimal, and that the overall design is obvious and familiar to all involved. Software generally isn't like that, particularly large software. It's unfamiliar; it's not something you can touch; the requirements are poorly understood / shifting / disagreed upon by stakeholders. This is why the popular CS ideas are the ones that favor a design that changes during the implementation phase(s). The rocketry analogy is much better - in that case it was something unfamiliar and huge. Fortunately you can touch a rocket, and pretty much everybody wanted to put a small object in orbit. Compared to software, rocket science is easy:) j/k
Also, the biological analogy is bogus. Those little critters are running some seriously mature software (tested for more than 20 years, I assure you) that I dare not estimate in terms of lines of code. I don't think we have billions of years to get our software right via genetic algorithms. We have to play creator and move things along faster than they would on their own.
Yes there are a number of *nixen out there, but considering just the free ones, I doubt there is much reinventing of the wheel since most of it comes from the same GNU sources, compiled for each kernel.
Finally, the author disparages computers based on stuffy old math inspired languages such as Fortran and C, and then goes on to laud a series of open source projects (as proof that the mob approach works in small sizes, meaning just a few million developers I guess) which are all written in... C.
>Because TCP/IP is a standard, there should not
>be performance differences between stacks
>whereas a stack performs better speaking to
>another stack of the same design. TCP/IP
>should be completely interoperable.
Where did you get the idea that interoperability has anything to do with performance?
The correctness of a TCP/IP implementation has to do with whether it changes state properly, gives appropriate responses, delivers data intact, etc. It has nothing to do with benchmarks as compared to other implementations. The carrier pigeons implementation should make this clear - correctness doesn't depend upon speed.
This is pretty fatalistic. Ad-funded analog free TV will never die (sorry, digital TV hornswagglers), but lots of people spend lots of money on cable and satellite TV. Nobody wants to watch commercials, and it's a lot easier to run a business when you're focused on giving customers what they want rather than walking the fine line of providing desirable content without pissing off sponsors. Cable has proven that there is a pay model for TV that makes it profitable to deliver more narrowly targetted content to people who have a bit of money to spend.
The only reason there isn't even more targetted content offered for more money without ads to an even narrower audience is that content publishers are paranoid about piracy. As they were with the VCR, and as the music folks were about the cassette tape. What they fail to realize is that movie trading is tedious, very time consuming, and the resulting quality is pretty bad (compared to a DVD or laserdisc). Convenient delivery of extremely high quality digital content is something that people would pay for, but greed on the part of content owners drives them to refuse to try it until they have a total control, through a 100% foolproof means of defeating piracy. Of course this is impossible.
What will change is the attitudes of content owners. They are still living in a fantasy world, and regardless of what they annouce as their intentions or wish for how things will work, they will be forced to accede to customers' wishes. Content won't be totally free (that's a fantasy world too), but it will be cheap, because nothing else will succeed when pitted against the consumer's other option: piracy.
I agree; I've been a NetFlix customer for about two months and so far it's great. About 1 in 10 DVDs is scratched and is unplayable (so far) but they handle that well. I haven't had the unavailability problems that the other poster has. It's very convenient, particularly because I'm in SF and NetFlix is in San Jose, so the snail mail delivery time is pretty quick.
Here's to hoping that paying for a service will keep it in business.
Cost: this is a very valid point, pair programming is counterintuitive from a cost vs. productivity point of view. XP evangelists and would-be adopters need more ammo in the form of studies that show that pair programming works.
Trust: pair programming isn't about a smart guy driving and a not so smart guy watching, nor is it about you driving and a DMV instructor writing down all the mistakes you make. If you know how to use the development tools and the language you can drive perfectly well while the other developer brain-dumps code through your hands. Likewise, you can sit back and say "damn, that's some pretty clever shit right there" and learn from what you're seeing the other developer do.
Inertia: Making reasonably competent managers and other business people change is a matter of selling solutions to known problems (fewer bugs make it to QA; we start hitting our milestones) and business value (greater development capacity, more small releases mean you can see that things are or are not tracking to plan sooner) rather than the implementation plan for solutions (let's do more testing, let's have the same number of developers working on half as many issues at a time). Sometimes managers won't improve things because they are afraid, at which point it's hopeless and you should either quit or go over their head.
Users and developers are on equal footing but users don't get to decide on estimating how long it takes to implement something. Part of XP is the assertion that the different practices are distinct but that they definitely reinforce one another - take out pair programming and quality goes down. Take out refactoring and you're completely screwed; you can't design a process around incremental as-needed redesign (refactoring) to avoid a big design phase up front, and then remove design altogether.
These are doubts which are directly addressed in "Extreme Programming Explained" as well as numerous web sites... learn about the process before dismissing it as too idealistic.
Everybody seems to think that working in pairs means that you sit at the computer, and the other guy bothers you, so you can't get in the zone.
What if you're the one "riding", what's to stop you from getting in the zone? In fact, you have less to distract you since all you're doing is looking at and thinking about the code. No need to worry about tab stops, mouse wheelie scrolling, and curly brackets. Just what the code should be.
Another uninformed comment. Can't anyone be bothered to learn something about the topic they're attacking? Oh wait, I forgot I was on/.
I spoke with a guy last year who had worked at Amazon, and he said that some of their developers were citing XP as written justification for a lack of any methodology whatsoever. Just start coding shit up and hope for the best because it's too hard to plan, document, test, or coordinate team efforts. That is *not* what it's about. The most significant practice from my point of view is the very robust testing: going from defining features to defining test cases that prove feature completeness to writing test harnesses that test code for correctness to code that satisfies all of these tests. Hacking to me means making it up as you code, with simple tests afterwards to make sure it at least works in the obvious case.
Team programming is explicit in XP, and that goes beyond the usual open source non-methodology of CVS + majordomo. Tell pesky junior developers to shut up, to watch, to write questions down, and to email them to you later if you have to. That's a pretty selfish attitude from a team standpoint, but I could see that being a valid approach given an extreme situation (such as, you already answered those same questions yesterday, and the day before, and the boss won't fire the doofus).
In my experience, sometimes pair programming means 20 minutes of silence while one person rocks out and the other just watches and nods, or even one person struggling until the other says "dude, I know how to nail this, just let me drive for a couple of minutes."
I was on a fairly recent project that involved pretty much constant pair programming. It wasn't by choice; the assignment was to fix a particularly hairy and dense section of an application, and it was so badly written that we couldn't find any clean way to split the work between the two of us, so we pretty much had to work as a pair. It was amazing. I was definitely the more senior one - more experience, more familiarity with the language and runtime environment - but the other guy stunned me with his ability to skim a tangled loop construct and instantly spot what was wrong. He was also able to think about the larger process more quickly than I because he wasn't distracted with the mechanical process of build, test, check in, etc. In a normal situation I wouldn't have had any problems keeping up with this but this was somebody else's screwy development environment, and the way the code we were fixing was written by a madman. In a normal situation I would expect that pair programming benefits would be more along the lines of real-time QA and design reviews.
BTW, given the amount of positive sentiment about XP from actual developers (as opposed to methodology crazed academics), I'm surprised how many people are willing to reject it offhand. It's a pretty skinny book, and it's not hard to just try pair programming and see whether it works.
Pair programming doesn't mean you have a taskmaster cracking the whip, that's not where the extra productivity comes from. It means that when you're in coding mode, there's someone there with you. This person needs to take breaks too.
The extra productivity comes from having one person typing, "mousing", and generally fooling with the computer, and someone else who is free to just look at the code, think, and make suggestions. Of course the "driver" reads and thinks too, but the "rider" isn't distracted by the mechanical aspects of coding.
Also, there is a great deal of value in just watching someone else work. The "driver" might do something cool (like use a better editor, whatever) and the "rider" can learn, or the "rider" may make suggestions. By switching pairs around, best practices migrate around quickly.
Pair programming *is* important. It assists collective code ownership, it helps junior developers by letting them watch senior developers work or by having senior developers make suggestions, it keeps developers honest, and it allows for real-time design discussions.
Also, UML is not discredited IMHO, although the RUP is. With the proper modeling tools (such as the spectacular Together/J), UML diagrams are interchangeable with source code and are just another, more visually concise way of looking at the design structure of the application (as opposed to the logic). UML is a much better design-phase representation an object model than source code. Try printing out & taping to a wall (a) dozens of classes in source form and (b) a big UML diagram on a plotter, and see which works best.
Advice to geeks, especially ones who haven't been in the job market for very long: Be careful not to reduce a job opportunity's value down to a dollar figure. Geeks seem to overlook this and then complain about how much their job sucks, but based on the ravenous job market, there's really no excuse other than inertia. If you're looking now, make sure you consider the qualitative properties of a job.
If you look back a few weeks you will see a story about working in a tech sweatshop. Bear that in mind when looking at employers. You can get a big salary and lots of options but it may not be worth it if you are expected to work 80 hours a week. Or, you may be expected to be on call 24/7, which is a hell of a lot more than the 45-55 hours which are typical of the industry. Asking what happens salary wise when you work 100 hours in a week can be very eye-opening. I got an answer from one employer of "nothing, you are expected to do a job, however long that takes." And guess what the hours looked like...
Also, what about knowledge management? Are you doing the same work that has been done before by co-workers? How will you find someone who has done what you are doing? Yeah, trailblazing is fun and all, but rediscovering known bugs isn't especially fun. Also, there should be KM from you to the rest of the organization. Being the main tech go-to guy is dangerous. If you are so important, will they ever let you take a vacation and leave you alone? The geeky analogy is clustering - you don't want to be a single point of failure or the pointy-haired ones will never want to let you out of their sight, much less out of town for a week. Will you be working on Xmas eve, New year's eve? Will you get yelled at if you take a 75 minute lunch?
What is the technology environment? Just because you like *nix doesn't mean your boss does. Will you be forced to use something you don't want to? What is the email environment? Who makes these decisions and how binding are they on the individual? Will you be forced to run Win98 and Outlook just because the MS Exchange sales pitch to the IT manager was slick? How developed is the company intranet? What if you have something useful to post - what is the process for getting your info out there?
If you are looking at a startup, what is the non-stock risk factor? For example, is the current boss going to be replaced by a "real CEO" (answer: almost certainly). What will this CEO's vision be, if any? Will the office move to an inconvenient location? Will you be sure to get a paycheck every time, on time? Are they hiring so fast that a few (or a lot of) a-holes are bound to get in as well? Will they be identified and fired, or will they become your boss?
Ask about things like how project deadlines are set. There needs to be a process - "whenever I need it done by" isn't going to be very fair to you. You should be involved in the process of setting deadlines, or else it's always going to be based on when they want it done (yesterday), not when it is feasible to do.
Consider the commute. If you can take public transportation, that may mean that you can sell your car and save $hundreds a month, or at least you can get back productive time (laptop or magazine on the subway / bus). Plus, sitting in bumper to bumper traffic for an hour each way is a serious pain in the butt, and it doesn't ever really get better unless you move.
If you ever want to go make friends, find/retain a significant other, and see your family, think about more than just the cash and options.
Shameless plug: I like to think I have found a great employer who pays market rate *and* has a great culture, and particularly has a core value of life balance. E-mail me if you are interested - jamie.flournoy@viant.com. Include a resume if you want, of course:)
Don't forget about the life-balance thing. Geeks seem to overlook this and then complain about it, but based on the ravenous job market, there is no excuse other than inertia. If you're looking already, make sure you pick a company based on more than just $$$.
If you look back a few weeks(?) you will see a/. story about tech sweatshops. Bear that in mind when looking at employers. You can get a big salary and lots of options but it may not be worth it if you are expected to work 80 hours a week. Or, you may be expected to be on call 24/7, which is a hell of a lot more than the 45-55 hours which are typical of the industry. Asking what happens salary wise when you work 100 hours in a week can be very eye-opening. I got an answer from one employer of "nothing, you are expected to do a job, however long that takes." And guess what the hours looked like...
Also, what about the knowledge-sharing? If you are so important, will they ever let you take a vacation and leave you alone? The geeky analogy is clustering - you don't want to be a single point of failure or the pointy-haired ones will never want to let you out of their sight, much less out of town for a week. Will you be working on Xmas eve, New year's eve? Will you get yelled at if you take a 75 minute lunch?
Ask about things like how project deadlines are set. There needs to be a process - "whenever I need it done by" isn't going to be very fair to you. You should be involved in the process of setting deadlines, or else it's always going to be based on when they want it done (yesterday), not when it is feasible to do.
If you ever want to go make friends, find/retain a significant other, and see your family, think about more than just the cash and options.
Shameless plug: I like to think I have found a great employer who pays market rate *and* has a great culture, and particularly has a core value of life balance. E-mail me if you are interested - jamie@white-mountain.org .
Hope the twitchy lawyer types don't sue you for giving them free publicity.
Windoze OEM = distro + supported hardware
on
Red Hat at Dell?
·
· Score: 1
It's hardly a violation of the GPL. You can't get the exact combo of stuff in Red Hat 5.1, except by getting Red Hat 5.1, But it's still all free. You could gather all those files together on your own, but why? Who would bother distributing the exact same thing for the same price, when Red Hat is already doing it?
Besides, all any Wintel hardware vendor does is slap some hardware & software together, make sure it all works, and ship it. It's the same thing a Linux distributor does: bundle the OS and lots of apps and utilities, and make sure they all work together... but with the addition of hardware/drivers.
If you just order up 200 units of various models desktop machines and 50 units of various models laptops with whatever random hardware the vendors are dishing out, and then try and put Linux on it, chances are you will have problems. You'll find out that the installer can't see your hard disk properly, or that (real world example) the Hitachi laptop ethernet controller and sound chip are supported only in bleeding edge releases that it might take a couple of days/weeks to track down. These aren't insurmountable problems, but they take some time and expertise to fix. For a linux geek that's OK, but for an MIS that's a catastrophe. He ordered 250 machines and it took weeks to get them all working. At least in the Wintel world, they wait a couple of weeks before randomly corrupting their Registries:)
So they like the "value-add" that comes from knowing that when they order a system, that hardware configuration definitely works as installed and shipped. They don't want to futz with altavista and dejanews trying to find a beta driver for that new card, they want to pay a field-tech monkey to take it out of the box, plug in all the cables, turn it on, and start running installers.
Of course Wintel OEMs sometimes fall down on their asses and fail to provide the value I just described, but that's the whole reason they persist when you can slap your own PC together from parts catalogs for less. It's the delta between the pile of parts, and the definitely-working system (h/w and s/w) that the Wintel OEMs provide.
VA Research is in exactly the same place, and they're apparently doing a more complete job of it. Don't freak out and accuse Dell of being evil and clueless - they're entrenched deeply in the Wintel worls, but are moving cautiously in the right direction. They're no heroes or anything, but after a few months, when they find out that supporting Linux is a viable business, they'll undoubtedly take on the "risk" of supporting something other than a vanilla configuration.
In the meantime, just be sure to tell Dell that you're ordering from VA Research instead of them, and why:) That will tell them that there is demand for real servers (SMP/RAID) and that they are losing that business to a competitor.
Slashdot Mirror
Yeah OK so the guy has serious creds at a code level but that doesn't mean he's automatically right, nor original. I am so tired of these hax0r artise / code poet essays on /.; when will it end?
/. is read by vocal code poets and a horde of lurking team developers. I see the team developers speak up every now and then.
:) j/k
In my experience you can categorize programmers into the following three groups: lone rangers, uninspired key pushers, and team developers. Lone rangers can be extremely productive on their own and know it, but don't know how to split up work, resolve disagreements, and make sure the important dirty work gets done. The uninspired key pushers are the ones who prove the axiom that a great programmer can be 10x as productive as a bad one. They're the ones who write spaghetti code, use code generating wizards and don't understand how the environment they're programming for works. Finally there are team developers, who may not be as productive alone as a lone ranger but who can actually break up work, debate ideas rather than descending into ad hominem pissing matches, and who get all the work done (not just the fun stuff). I suspect that
The idea of mob development is not original, but I argue that it's not limited to open source either. You don't have to be an aeronautical engineer to know that a rocket shouldn't blow up on the launch pad. Likewise, commercial software gets pushed on users who definitely have plenty of eyeballs capable of testing software. The sad part is that they pay for the privilege, where in open source at least the helpful eyeballs don't have to pay. Open source has the advantage of allowing outside developers to fix problems, but it's not as though commercial software customers don't notice bugs because they don't have the source.
I strongly disagree with the author in a couple of cases.
The cathedral analogy is completely bogus. This is ESR's fault, and it's a logical fallacy that code poets often use to "prove" that open source code poetry is the One True Path. Cathedrals have very basic requirements compared to a piece of software, and involve designs which were centuries old at the time. Hire an amazing artist to do some art for the cover of your software manuals, retail box, splash screen, etc. Wow, what an incredibly clever development process you've discovered, he didn't introduce any bugs into the product! The glue used to bind the manual smells nice, because you hired a fragrance designer? You are a software development guru now, because that person didn't get in the way of the code being developed. What?? It doesn't make sense because these are very distinct concepts, easy to modularize. To get a realistic comparison, try getting 40 sculptors to work together on the front door, another 20 on the tympanum above the door, 10 on the side door tympanums, and make sure they all coordinate their efforts so everything looks consistent and follows a unifying theme. Now you see how the analogy breaks down.
Gargoyles, stained glass windows, pulpits, they're just ornate versions of everyday objects that everybody already understands. In techie terms, I'm saying is that a Cathedral is not only a highly modularizable design, but that the interfaces between modules are minimal, and that the overall design is obvious and familiar to all involved. Software generally isn't like that, particularly large software. It's unfamiliar; it's not something you can touch; the requirements are poorly understood / shifting / disagreed upon by stakeholders. This is why the popular CS ideas are the ones that favor a design that changes during the implementation phase(s). The rocketry analogy is much better - in that case it was something unfamiliar and huge. Fortunately you can touch a rocket, and pretty much everybody wanted to put a small object in orbit. Compared to software, rocket science is easy
Also, the biological analogy is bogus. Those little critters are running some seriously mature software (tested for more than 20 years, I assure you) that I dare not estimate in terms of lines of code. I don't think we have billions of years to get our software right via genetic algorithms. We have to play creator and move things along faster than they would on their own.
Yes there are a number of *nixen out there, but considering just the free ones, I doubt there is much reinventing of the wheel since most of it comes from the same GNU sources, compiled for each kernel.
Finally, the author disparages computers based on stuffy old math inspired languages such as Fortran and C, and then goes on to laud a series of open source projects (as proof that the mob approach works in small sizes, meaning just a few million developers I guess) which are all written in... C.
>Because TCP/IP is a standard, there should not
>be performance differences between stacks
>whereas a stack performs better speaking to
>another stack of the same design. TCP/IP
>should be completely interoperable.
Where did you get the idea that interoperability has anything to do with performance?
The correctness of a TCP/IP implementation has to do with whether it changes state properly, gives appropriate responses, delivers data intact, etc. It has nothing to do with benchmarks as compared to other implementations. The carrier pigeons implementation should make this clear - correctness doesn't depend upon speed.
This is pretty fatalistic. Ad-funded analog free TV will never die (sorry, digital TV hornswagglers), but lots of people spend lots of money on cable and satellite TV. Nobody wants to watch commercials, and it's a lot easier to run a business when you're focused on giving customers what they want rather than walking the fine line of providing desirable content without pissing off sponsors. Cable has proven that there is a pay model for TV that makes it profitable to deliver more narrowly targetted content to people who have a bit of money to spend.
The only reason there isn't even more targetted content offered for more money without ads to an even narrower audience is that content publishers are paranoid about piracy. As they were with the VCR, and as the music folks were about the cassette tape. What they fail to realize is that movie trading is tedious, very time consuming, and the resulting quality is pretty bad (compared to a DVD or laserdisc). Convenient delivery of extremely high quality digital content is something that people would pay for, but greed on the part of content owners drives them to refuse to try it until they have a total control, through a 100% foolproof means of defeating piracy. Of course this is impossible.
What will change is the attitudes of content owners. They are still living in a fantasy world, and regardless of what they annouce as their intentions or wish for how things will work, they will be forced to accede to customers' wishes. Content won't be totally free (that's a fantasy world too), but it will be cheap, because nothing else will succeed when pitted against the consumer's other option: piracy.
I agree; I've been a NetFlix customer for about two months and so far it's great. About 1 in 10 DVDs is scratched and is unplayable (so far) but they handle that well. I haven't had the unavailability problems that the other poster has. It's very convenient, particularly because I'm in SF and NetFlix is in San Jose, so the snail mail delivery time is pretty quick.
Here's to hoping that paying for a service will keep it in business.
Cost: this is a very valid point, pair programming is counterintuitive from a cost vs. productivity point of view. XP evangelists and would-be adopters need more ammo in the form of studies that show that pair programming works.
Trust: pair programming isn't about a smart guy driving and a not so smart guy watching, nor is it about you driving and a DMV instructor writing down all the mistakes you make. If you know how to use the development tools and the language you can drive perfectly well while the other developer brain-dumps code through your hands. Likewise, you can sit back and say "damn, that's some pretty clever shit right there" and learn from what you're seeing the other developer do.
Inertia: Making reasonably competent managers and other business people change is a matter of selling solutions to known problems (fewer bugs make it to QA; we start hitting our milestones) and business value (greater development capacity, more small releases mean you can see that things are or are not tracking to plan sooner) rather than the implementation plan for solutions (let's do more testing, let's have the same number of developers working on half as many issues at a time). Sometimes managers won't improve things because they are afraid, at which point it's hopeless and you should either quit or go over their head.
Users and developers are on equal footing but users don't get to decide on estimating how long it takes to implement something. Part of XP is the assertion that the different practices are distinct but that they definitely reinforce one another - take out pair programming and quality goes down. Take out refactoring and you're completely screwed; you can't design a process around incremental as-needed redesign (refactoring) to avoid a big design phase up front, and then remove design altogether.
These are doubts which are directly addressed in "Extreme Programming Explained" as well as numerous web sites... learn about the process before dismissing it as too idealistic.
Everybody seems to think that working in pairs means that you sit at the computer, and the other guy bothers you, so you can't get in the zone.
What if you're the one "riding", what's to stop you from getting in the zone? In fact, you have less to distract you since all you're doing is looking at and thinking about the code. No need to worry about tab stops, mouse wheelie scrolling, and curly brackets. Just what the code should be.
Another uninformed comment. Can't anyone be bothered to learn something about the topic they're attacking? Oh wait, I forgot I was on /.
I spoke with a guy last year who had worked at Amazon, and he said that some of their developers were citing XP as written justification for a lack of any methodology whatsoever. Just start coding shit up and hope for the best because it's too hard to plan, document, test, or coordinate team efforts. That is *not* what it's about. The most significant practice from my point of view is the very robust testing: going from defining features to defining test cases that prove feature completeness to writing test harnesses that test code for correctness to code that satisfies all of these tests. Hacking to me means making it up as you code, with simple tests afterwards to make sure it at least works in the obvious case.
Team programming is explicit in XP, and that goes beyond the usual open source non-methodology of CVS + majordomo. Tell pesky junior developers to shut up, to watch, to write questions down, and to email them to you later if you have to. That's a pretty selfish attitude from a team standpoint, but I could see that being a valid approach given an extreme situation (such as, you already answered those same questions yesterday, and the day before, and the boss won't fire the doofus).
In my experience, sometimes pair programming means 20 minutes of silence while one person rocks out and the other just watches and nods, or even one person struggling until the other says "dude, I know how to nail this, just let me drive for a couple of minutes."
I was on a fairly recent project that involved pretty much constant pair programming. It wasn't by choice; the assignment was to fix a particularly hairy and dense section of an application, and it was so badly written that we couldn't find any clean way to split the work between the two of us, so we pretty much had to work as a pair. It was amazing. I was definitely the more senior one - more experience, more familiarity with the language and runtime environment - but the other guy stunned me with his ability to skim a tangled loop construct and instantly spot what was wrong. He was also able to think about the larger process more quickly than I because he wasn't distracted with the mechanical process of build, test, check in, etc. In a normal situation I wouldn't have had any problems keeping up with this but this was somebody else's screwy development environment, and the way the code we were fixing was written by a madman. In a normal situation I would expect that pair programming benefits would be more along the lines of real-time QA and design reviews.
BTW, given the amount of positive sentiment about XP from actual developers (as opposed to methodology crazed academics), I'm surprised how many people are willing to reject it offhand. It's a pretty skinny book, and it's not hard to just try pair programming and see whether it works.
Gee, you must be very smart...
Pair programming doesn't mean you have a taskmaster cracking the whip, that's not where the extra productivity comes from. It means that when you're in coding mode, there's someone there with you. This person needs to take breaks too.
The extra productivity comes from having one person typing, "mousing", and generally fooling with the computer, and someone else who is free to just look at the code, think, and make suggestions. Of course the "driver" reads and thinks too, but the "rider" isn't distracted by the mechanical aspects of coding.
Also, there is a great deal of value in just watching someone else work. The "driver" might do something cool (like use a better editor, whatever) and the "rider" can learn, or the "rider" may make suggestions. By switching pairs around, best practices migrate around quickly.
Pair programming *is* important. It assists collective code ownership, it helps junior developers by letting them watch senior developers work or by having senior developers make suggestions, it keeps developers honest, and it allows for real-time design discussions. Also, UML is not discredited IMHO, although the RUP is. With the proper modeling tools (such as the spectacular Together/J), UML diagrams are interchangeable with source code and are just another, more visually concise way of looking at the design structure of the application (as opposed to the logic). UML is a much better design-phase representation an object model than source code. Try printing out & taping to a wall (a) dozens of classes in source form and (b) a big UML diagram on a plotter, and see which works best.
Advice to geeks, especially ones who haven't been in the job market for very long: Be careful not to reduce a job opportunity's value down to a dollar figure. Geeks seem to overlook this and then complain about how much their job sucks, but based on the ravenous job market, there's really no excuse other than inertia. If you're looking now, make sure you consider the qualitative properties of a job.
:)
If you look back a few weeks you will see a story about working in a tech sweatshop. Bear that in mind when looking at employers. You can get a big salary and lots of options but it may not be worth it if you are expected to work 80 hours a week. Or, you may be expected to be on call 24/7, which is a hell of a lot more than the 45-55 hours which are typical of the industry. Asking what happens salary wise when you work 100 hours in a week can be very eye-opening. I got an answer from one employer of "nothing, you are expected to do a job, however long that takes." And guess what the hours looked like...
Also, what about knowledge management? Are you doing the same work that has been done before by co-workers? How will you find someone who has done what you are doing? Yeah, trailblazing is fun and all, but rediscovering known bugs isn't especially fun. Also, there should be KM from you to the rest of the organization. Being the main tech go-to guy is dangerous. If you are so important, will they ever let you take a vacation and leave you alone? The geeky analogy is clustering - you don't want to be a single point of failure or the pointy-haired ones will never want to let you out of their sight, much less out of town for a week. Will you be working on Xmas eve, New year's eve? Will you get yelled at if you take a 75 minute lunch?
What is the technology environment? Just because you like *nix doesn't mean your boss does. Will you be forced to use something you don't want to? What is the email environment? Who makes these decisions and how binding are they on the individual? Will you be forced to run Win98 and Outlook just because the MS Exchange sales pitch to the IT manager was slick? How developed is the company intranet? What if you have something useful to post - what is the process for getting your info out there?
If you are looking at a startup, what is the non-stock risk factor? For example, is the current boss going to be replaced by a "real CEO" (answer: almost certainly). What will this CEO's vision be, if any? Will the office move to an inconvenient location? Will you be sure to get a paycheck every time, on time? Are they hiring so fast that a few (or a lot of) a-holes are bound to get in as well? Will they be identified and fired, or will they become your boss?
Ask about things like how project deadlines are set. There needs to be a process - "whenever I need it done by" isn't going to be very fair to you. You should be involved in the process of setting deadlines, or else it's always going to be based on when they want it done (yesterday), not when it is feasible to do.
Consider the commute. If you can take public transportation, that may mean that you can sell your car and save $hundreds a month, or at least you can get back productive time (laptop or magazine on the subway / bus). Plus, sitting in bumper to bumper traffic for an hour each way is a serious pain in the butt, and it doesn't ever really get better unless you move.
If you ever want to go make friends, find/retain a significant other, and see your family, think about more than just the cash and options.
Shameless plug: I like to think I have found a great employer who pays market rate *and* has a great culture, and particularly has a core value of life balance. E-mail me if you are interested - jamie.flournoy@viant.com. Include a resume if you want, of course
Don't forget about the life-balance thing. Geeks seem to overlook this and then complain about it, but based on the ravenous job market, there is no excuse other than inertia. If you're looking already, make sure you pick a company based on more than just $$$.
/. story about tech sweatshops. Bear that in mind when looking at employers. You can get a big salary and lots of options but it may not be worth it if you are expected to work 80 hours a week. Or, you may be expected to be on call 24/7, which is a hell of a lot more than the 45-55 hours which are typical of the industry. Asking what happens salary wise when you work 100 hours in a week can be very eye-opening. I got an answer from one employer of "nothing, you are expected to do a job, however long that takes." And guess what the hours looked like...
If you look back a few weeks(?) you will see a
Also, what about the knowledge-sharing? If you are so important, will they ever let you take a vacation and leave you alone? The geeky analogy is clustering - you don't want to be a single point of failure or the pointy-haired ones will never want to let you out of their sight, much less out of town for a week. Will you be working on Xmas eve, New year's eve? Will you get yelled at if you take a 75 minute lunch?
Ask about things like how project deadlines are set. There needs to be a process - "whenever I need it done by" isn't going to be very fair to you. You should be involved in the process of setting deadlines, or else it's always going to be based on when they want it done (yesterday), not when it is feasible to do.
If you ever want to go make friends, find/retain a significant other, and see your family, think about more than just the cash and options.
Shameless plug: I like to think I have found a great employer who pays market rate *and* has a great culture, and particularly has a core value of life balance. E-mail me if you are interested - jamie@white-mountain.org .
I have some more photos which I took at JavaOne, on my home page. Check 'em out.
.white-mountain.org/jamie/news/1999_javaone_photos /mindstorms/
http://www
Hope the twitchy lawyer types don't sue you for giving them free publicity.
It's hardly a violation of the GPL. You can't get the exact combo of stuff in Red Hat 5.1, except by getting Red Hat 5.1, But it's still all free. You could gather all those files together on your own, but why? Who would bother distributing the exact same thing for the same price, when Red Hat is already doing it?
:)
:) That will tell them that there is demand for real servers (SMP/RAID) and that they are losing that business to a competitor.
Besides, all any Wintel hardware vendor does is slap some hardware & software together, make sure it all works, and ship it. It's the same thing a Linux distributor does: bundle the OS and lots of apps and utilities, and make sure they all work together... but with the addition of hardware/drivers.
If you just order up 200 units of various models desktop machines and 50 units of various models laptops with whatever random hardware the vendors are dishing out, and then try and put Linux on it, chances are you will have problems. You'll find out that the installer can't see your hard disk properly, or that (real world example) the Hitachi laptop ethernet controller and sound chip are supported only in bleeding edge releases that it might take a couple of days/weeks to track down. These aren't insurmountable problems, but they take some time and expertise to fix. For a linux geek that's OK, but for an MIS that's a catastrophe. He ordered 250 machines and it took weeks to get them all working. At least in the Wintel world, they wait a couple of weeks before randomly corrupting their Registries
So they like the "value-add" that comes from knowing that when they order a system, that hardware configuration definitely works as installed and shipped. They don't want to futz with altavista and dejanews trying to find a beta driver for that new card, they want to pay a field-tech monkey to take it out of the box, plug in all the cables, turn it on, and start running installers.
Of course Wintel OEMs sometimes fall down on their asses and fail to provide the value I just described, but that's the whole reason they persist when you can slap your own PC together from parts catalogs for less. It's the delta between the pile of parts, and the definitely-working system (h/w and s/w) that the Wintel OEMs provide.
VA Research is in exactly the same place, and they're apparently doing a more complete job of it. Don't freak out and accuse Dell of being evil and clueless - they're entrenched deeply in the Wintel worls, but are moving cautiously in the right direction. They're no heroes or anything, but after a few months, when they find out that supporting Linux is a viable business, they'll undoubtedly take on the "risk" of supporting something other than a vanilla configuration.
In the meantime, just be sure to tell Dell that you're ordering from VA Research instead of them, and why