Well, the problem is that it isn't obvious. Many people believe in ESP. Many people have experiences that they interpret as having experienced ESP. One of the simple explanations for that is that there is ESP.
Now personally, I agree, it's bunk. But what we still don't have is a convincing and clear explanation of what those experiences are and and explanation of why people keep believing it's ESP.
What we need is for that explanation to be as commonly available and as widely understood as why the moon has phases, or why you can't get to the end of a rainbow. Not that everybody gets those, either, but it's good enough that crazy theories based around rainbow-chasing aren't a big problem.
Calling it a monopoly would be akin to calling ANY BUSINESS a monoploy as you can only buy their product from them.
You seem to have quite a bee in your bonnet on this one. Whenever I get the urge to write in all caps, I go for a walk. Maybe you should try that.
The poster I was responding to was suggesting that CDs are like any other commodity. They aren't. You don't go buy a pound of CDs in the same way you buy a pound of butter. As I explained elsewhere, they're still somewhat subject to supply and demand, but not to the same extent commodity suppliers are.
As to the word "monopoly", you're basically wrong. As experts say in obvious places, copyrights, patents, and trademarks are all government-granted limited monopolies. That a monopoly is limited doesn't make it less a monopoly. If I have a monopoly on the world's beef, people can and will substitute chicken, but that doesn't mean I don't have a monopoly.
Yes, modern businesses make extensive use of these, but that's precisely because they're monopolies, and monopolies allow greater profit than commodities. I'm not even saying that's bad; there's a useful purpose behind all of them. I'm just saying that you can't think about the CD market in the same way you think about the butter market. Butter is pretty much butter, but Madonna is not pretty much Weird Al.
Most other countries have the Copyright on recordings go into public domain about 50 to 90 years
Currently. And that's longer than it once was. There are a lot of people with a lot of money working to change that. Remember, I said, "in practice, eternal." The question is, will we let them?
Comparing music to sugar is a bit of a red herring because sugar is an amorphous white blob with ready substitutions.
I'd agree, but that was my point. The poster I was responding to was suggesting that CDs are just like any other commodity. You and I agree that they are different.
In other words, the law of supply and demand still holds in setting prices. [...] The substitutions for the Weird Al music exist as well: they're other songs and other forms of entertainment.
Oh, I'd agree; I'm just trying to say that the standard intution of markets people have can be misleading because of the monopoly and the differing substitution behavior. That's not to say the big labels can get away with murder, but they can get away with more than a producer of bulk commodities can. Thus, the matching markets-will-take-care-of-themselves intuition is less valid. Especially given the noted give-them-an-inch-and-they'll-take-a-mile abilities of RIAA member companies.
Just like everything else, CDs are subject to supply and demand market forces.
Well, no, they aren't, not entirely.
If one sugar producer decides the "true" price of sugar is $15 a pound, then you can buy sugar from somebody else. But if you want to buy the latest Weird Al or Madonna album, there's only source. It's a monopoly, an in theory limited but in practice eternal one called "copyright". If they double the price of the hot Madonna release, there are a lot of people who won't think that Weird Al is just as good, and vice versa.
It's also important to note that RIAA is a trade association of major music producers, not a single producer. If the major labels (heaven forbid!) were to get together and, say, fix prices then market forces would also not apply. Not that they would do such a thing; RIAA is here to help us. I'm just talking hypotherically, you see.
From the article: "...the symbolic file link (or as it's called in UNIX, the soft link) finally arrives in Windows Vista." - anybody heard "soft link"? Me (after 10 years of using Linux) never...
Yes. The other, much more common kind of link is often called a "hard link". Symbolic links are, probably by analogy, called soft links. A quick look at Google finds thousands of references. You should check that Google thing out sometime; it's pretty cool.
I thought for once we could get through a Slashdot spam discussion without hearing the single most retarded thing people say on this topic. Apparently not.
using SQLgrey(listing), Spamassassin with ClamAV and bayesian filtering enabled (maybe plus Razor, Pyzor, DCC), and not disabling the local bayes-filter in my Thunderbird [...] What's the actual problem?
Do you not see the contradiction? You are using seven different tools or services there.
Starting at least ten years ago and going up until recently, you couldn't have a discussion about spam with some chowderhead saying, "I just hit delete. What's the actual problem?" At least people finally dropped the "I just delete them" nonsense, so that's a start. The actual problem is that spam is a growing problem, and an arms race. Every technical, social, and legal solution we have implemented has been breached by spammers.
The actual problem is that we are now spending billions receiving, processing, storing, and hopefully detecting spam. TFA says that 75% of all mail is now spam. For me, with a few decade-old domains and one fifteen-year-old address, it's well over 90%. Every time we have this discussion on Slashdot, somebody says, "What's the big problem?" Every time, those numbers are worse.
How many nines of crap would you like before you're willing to call it a problem?
New languages every year isn't important in the way it once was; language innovation seems to have slowed compared to say the 1980's. Substitute new design patterns, application frameworks, libraries, etc instead.
That seems very reasonable to me. It's also great when programmers get really interested in what goes on under the hood, so doing microcontroller work or sysadmin stuff can be great, too.
Still, I think people shouldn't ignore languages. There's interesting work being done with domain-specific languages, especially for testing and enabling expert users. And there's enough history out there that I think a lot of non-fogey programmers would benefit by going back and spending some time playing with older languages. There are a surprising number of Java people who really only know Java and C or C++. Without having spent some time with other approaches, I feel like they have a pretty limited mental toolbox.
As somebody who hires people at startups and small companies, my take is "maybe". Programmers are a quirky lot, and I try to take each one individually. Although the arrogant ones get the press, there are quite a number that are ridiculously modest, and you might be one of those.
Even if you aren't, there are advantages to age. The biggest one is maturity. There are mistakes that every novice makes that are (I hope!) behind you. Instead of a drama generator, you are probably a drama shock absorber. Even if your people skills aren't as great as you like, they're probably a lot better than 12 years ago. And best of all, you can see that with age comes some self-awareness. Everybody has problems, but in hiring one of the things I really look for is an awareness of your limitations and the ability to manage them yourself.
When evaluating somebody in your situation, one of the big questions I'd have aside from the usual ones (e.g, can you do the work) is whether you are still like the work and are eager to improve. For example, I feel like every programmer should learn a new language once a year. That doesn't mean that you become expert in it, just that you are stretching your brain. Or you might have a side project you're excited about. Or you might be studying software architecture patterns. Anything that proves you aren't a clock-puncher who just isn't sure what else to do.
So I'd say as long as you are doing work you want to do and doing it well, don't sweat it much. You may have to work harder to find a job than some young hotshot, but there are plenty of employers who value a steady producer who won't be a pain in the ass.
Hi, Christopher. First off, full marks for stepping up and explaining things honestly. You have done more good for Netscape than a dozen PR people. I'm sure you'll take a lot of crap from my fellow Slashdotters, but don't let it throw you. Listen to and acknowledge their legitimate complaints and you'll do fine.
I only wish that someone had brought it to our attention so that I didn't have to find out about it from Slashdot.
If you are looking to learn a lesson from this, how about this one: URLs are forever!
Whenever I make a change to a live server, my biggest concern is to not break existing usage. If I ever change an URL, I make sure to redirect old usage to new usage that's just as good. And if I'm ever not sure something is used, I generally look back at least three months in the logs. Especially if you've inherited a pile full of mystery, good analytical tools for your server logs are vital. Trying to run even a modestly-sized site without them is like running a large store without tracking your inventory: your life will become a series of unfortunate surprises.
I think Google has a case to answer here, I simply don't believe Microsoft maps can possibly legitimately be ranked where it is.
Since this is the first I had heard of Microsoft's map site, I am not struggling with this so much. First, if you search for "map", it's at position six. Looking at the Alexa comparison, the Wayback Machine (compare with the one for Google Maps), and the Wikipedia history for Microsoft's maps, this all seems appropriate to me.
And as the clincher, the SNL skit Lazy Sunday mentions Mapquest, Yahoo Maps, and Google Maps. No mention of Windows Live Local (or is it Microsoft Virtual Earth? Or, as you call it, Microsoft Maps?). As they say, "Google Maps is the best. Double true!"
But what about the privacy issues involved? Would you like it if your creepy next door neighbour was filming you for a couple of hours every day, just waiting for you to make a wrong move?
There's a next stage to this. It's when people start using electronic surveillance to expose and shame people who are taking electronic surveillance too far.
it is not in your companies interests to give reasons for rejecting a candidate.
I disagree.
When I reject, I generally just reject. Nicely, mind you. But without reasons.
If somebody asks why, however, and especially if they ask for feedback, I tell them. And not in terms of "you are lame because of X", either, but more like "well, for this job, we are looking for more of A". Or, "the person we hired had more experience with B". Or, "If I were you, I'd work on C".
I think it's worth the time just on grounds of general niceness. But that niceness pays off. Even if I don't hire a person now doesn't mean I won't hire them in the future. If they can spend a year building skills I want, we both win. And I've definitely had people say, "Oh, you should talk to my friend..."
For all sorts of reasons, I try to hire people with good social networks. If I hire them, I want them to tell all their friends what a cool outfit we are. And if I don't hire them, I want them doing exactly the same thing. If a little feedback will make them happy about the interview, I'm glad to give it to them.
Er, get a new job? A company that cares about certification, especially in a technology that you're not even using, doesn't sound like a good one to work for. When I see it on a resume, my first thought isn't "Wow, here's an expert!"; it's "Why did this person need to get certification?"
Amen. When I'm screening resumes, having certifications, especially a bunch of them, is a warning sign. It doesn't guarantee a trip to the trash can, but as with LauraW, it makes me suspicious. I'm hiring people to get things done, so what I'm looking for is people who have gotten things done.
When I see certifications, I'm worried that they're the kind of person who values the officially blessed answer over the one that works best. Or, worse, that they've spent a lot of time working for companies who have so little idea how to hire and promote programmers that they rely on multiple-choice tests.
Of course, I mainly work in startups and small companies, where the cost of a loose canon or a mediocre performer is intolerable. YMMV.
All of Google's businesses other than search generate little if any revenue. Really, stuff like Google's office systems exist to push back against Microsoft, not because running a word processor in the browser is a good idea.
This year, anyhow. From the people I've talked to there, they seem to be making a broad array of bets, many of which they don't expect to pay off for years. And that makes a fair bit of sense; if only one of them hits as big as their search/ad combination, it will keep them in the money for another decade.
Google has alot of money and they haven't had a chance to be taught a lesson in frugality. Once shareholders start demanding the impossible and they can not meet these demands with their profits from advertising only, you better believe that gourmet chef's job will be the first to go!
It's unlikely to come soon. By the stock price, the stockholders clearly believe that Google will do well not just from existing businesses, but from ones they have yet to create. They have gotten an amazing number of talented, creative people by offering to take a lot of bullshit out of their lives so that they can just make great stuff in an environment filled with other smart, happy, work-focused people.
If Google dumps the perks, many employees will (probably rightly) take it as a sign that Google management is more interested in this quarter's numbers than making creative products that will pay off five years from now. And they will leave. Going back to the small, VC-funded companies that are Silicon Valley's more traditional home for creative techies.
Why do I think this? Because currently I'm looking to hire engineers in the area, and Google is a giant vacuum cleaner. At least for the pals I have there, there's no hope of prying them loose. Not yet, anyhow.
Likewise, with software development (and really most computer systems development), everyone wants to rush out and start coding as fast as possible...but if they'd made sure there were no assumptions, defined their problem specifically, and spent way more time than they wanted to developing an architecture, the coding afterwards would just be data entry for the most part.
I think for many interesting problems, this is effectively impossible. That's because the future environment into which your software must fit is, for many projects, unknowable. Even if you really could collect every current available fact and carefully work out every logical implication, that wouldn't be enough because there are teams of other people just as smart as you working hard to beat you any way they can.
In the end, I've just accepted that requirements will change all the time. Every week our team says, "Given everything that we have figured out so far, what's the most useful thing to build this week?"
To you I'm sure that sounds crazy, but let me add that I agree with your next points: everything should be tested, we should invest vigorously in good architecture, in highly reusable code, and the product should be kept spotless and taut, like a well-run sailing ship. I think the only place we differ is in that you'd like to put most of that effort up front, while I'd like to do it continously.
At least for my environment, that seems more sustainable. Instead of fighting people for time up front, I start coding as soon as they feel like they can name one week of work that they're sure will be useful. But when they ask me to hack something together, to cut corners that we'll clean up in that mythical land called "later", that's when I fight them tooth and nail. Every week I give them some features they want built the best way I know how.
My other point is that it is virtually impossible to design an application when there are more than a few people all wanting to 'help' design.
I disagree. And I'd bet what you really mean is "I don't know how to..." not, "It is virtually impossible to..." Unless you have some mathematical proof that I'm unaware of.
You simply don't get as coherent a product if you have a team of designers all trying to push their agenda.
Yes. If you have a bunch of people trying to push agendas, that would be bad. What if you instead had a whole team that shared one agenda: the making of a great product? That's how I spend my days, and it works well for us.
Novels are typically written by one person (although chromatic's right, it's more "one primary person with a lot of collaboration" from what I've seen). But there are much more collaborative creative works. With my own eyes I've seen ensemble theater pieces with substantial creative input from a dozen people. Improvisational theater groups regularly produce extended coherent works with no central control. And I understand improvisational music works similarly.
For more information on this, see the excellent book Artful Making.
Although this would probably mean a huge downscaling of the software industry, as everyone would just write their own applications.
I doubt it. Take the example you mentioned, the printing press. There are now millions of people with the basic skills and material circumstances necessary to write and lay out a book and have it printed. How many do? And of those, how many write good ones? And how few write great ones?
For me it's been the ever-changing requirements which delay projects the most.
I think changing requirements are a fact of life. The only solution I see is to work in small enough increments that requirements change is a business problem, not a technical one.
The teams I run do weekly iterations, and that seems about right to me. A week is long enough to get something useful 100% done, but short enough that even the most antsy product manager can be persuaded to let the team focus on the work at hand. And then you ship the work and make a fresh start the following week.
Well, most of the time, anyhow. Occasionally a real emergency will come along and throw an iteration into disarray. But very worst case, you lose a week's work. And because the beginning of the next iteration is so close, most "emergencies" can really be handled in the normal course of things.
If the choice is between screwing yourself by becoming dependent on a bunch of different companies or screwing yourself by turning everything over to one monstrous internal bureaucracy, I'd say go with the former. It might be hard to fire one vendor and turn a project over to another, but it will be completely impossible to fire the central organization.
Really, though, I suspect you've created a false dichotomy. Among the vast soup of tasks you're looking at, some are probably done best by vendors, some by distributed internal staff, and some by centralized internal staff. But even for the centralizable ones, there's no reason it has to be the same center for each one, any more than your phone provider and your electric provider need to be the same company.
Of course lack of capital can be disastrous and create serious barriers to entry for wanna-be capitalists. However, I argue that the main cause of poverty is lack of skills, intelligence, imagination, and ability.
Seriously, do you know many poor people?
You should really take a closer look at success microfinance has had. People get loans for things like cows or hand tools or sewing machines. They can already imagine the cow. They may not have the precise skills needed, but the group loan structure means that their neighbors will be making sure they learn them. They are already reasonably intelligent, and the ability needed to work a cow is, while not small, well within their reach. What they need is capital and support from their community.
When they get it, the numbers are amazing. The last microfinance organization I visited had, on over 100,000 loans, a 100% repayment rate. It sounds crazy, but it's true.
The fundamental problem with Extreme Programming is that it proceeds from the assumption that no one on the team is a good software designer.
I don't know who gave you that idea, but they got it pretty wrong.
Some of the leaders of Extreme Programming and other agile methods are fantastic designers. Martin Fowler, for example, produces a fine variety of books on design. Eric Evans is another good example. Personally, I'm also a big fan of great design, and like XP precisely because it helps me produce better-designed code. Here's why:
I'm sure we concur that the biggest factor in the quality of your design is the information you have. If I just say, "Give me a design for a system," and leave it at that, I've given you zero information; no matter how good your skills are, your design is unlikely to be the right one. And the more you know, the better off you are. Agreed?
An inescapable fact about a software project is that you know the least at the beginning and the most at the end. Even if your research is 100% perfect (which, since that would be infinitely expensive, it won't be) new information will come to light. People will say, "Now that I've used X, what I really want is Y and Z." Your competitors, who are actively hiding as much as they can from you, will release new things. An executive will get replaced, causing a shift in direction. The business environment will change.
Ergo, we should wait as late as possible until making design decisions, so that we have maximum information. And we should keep things as flexible as possible, so that when we figure out something better, or when the world changes and our design is no longer optimal, we can correct the design at low cost. Which is XP's basic approach to design.
I also feel that XP is a big step forward because one isn't supposed to think about or invest in the design just at the beginning. It's a continuous process, so one never stops thinking about the design. It's not just for one person; everybody coding is supposed to be thinking about how to improve the design. And since I get to pair with everybody, they get to learn how I design, and I get to learn tricks from them.
Sure, like you, I spend plenty of time at the beginning of a project thinking about where it's going, and coming up with plausible answers; I want to be sure I won't paint myself into a corner. Those plausible answers look a lot like the napkin-and-notebook versions of design documents. The difference is that when I set down at the keyboard, I don't pay them much mind. We came up with them once, and generally I'm not afraid we won't come up with something just as good. If we get stuck, I may go back and look at early designs for inspiration, but I may just as happily look elsewhere. There's no reason to limit my thinking to the best ideas we had months ago.
Of course, that sort of change would be impossible without high-quality, well-tested code. Which is also why I do test-driven development, refactor mercilessly, and pair.
Does that make it clearer? If I thought XP produced bad designs, or was for people who can't design, I'd drop it a hot second. But having tried developing both ways, I have no questions which gives me more design time or produces better design results.
Slashdot Mirror
So long and thanks for confirming the obvious.
Well, the problem is that it isn't obvious. Many people believe in ESP. Many people have experiences that they interpret as having experienced ESP. One of the simple explanations for that is that there is ESP.
Now personally, I agree, it's bunk. But what we still don't have is a convincing and clear explanation of what those experiences are and and explanation of why people keep believing it's ESP.
What we need is for that explanation to be as commonly available and as widely understood as why the moon has phases, or why you can't get to the end of a rainbow. Not that everybody gets those, either, but it's good enough that crazy theories based around rainbow-chasing aren't a big problem.
That's an outright confession of fraud.
Not quite. Fraud is where you intentionally fool others. These guys are just unintentionally fooling themselves.
Calling it a monopoly would be akin to calling ANY BUSINESS a monoploy as you can only buy their product from them.
You seem to have quite a bee in your bonnet on this one. Whenever I get the urge to write in all caps, I go for a walk. Maybe you should try that.
The poster I was responding to was suggesting that CDs are like any other commodity. They aren't. You don't go buy a pound of CDs in the same way you buy a pound of butter. As I explained elsewhere, they're still somewhat subject to supply and demand, but not to the same extent commodity suppliers are.
As to the word "monopoly", you're basically wrong. As experts say in obvious places, copyrights, patents, and trademarks are all government-granted limited monopolies. That a monopoly is limited doesn't make it less a monopoly. If I have a monopoly on the world's beef, people can and will substitute chicken, but that doesn't mean I don't have a monopoly.
Yes, modern businesses make extensive use of these, but that's precisely because they're monopolies, and monopolies allow greater profit than commodities. I'm not even saying that's bad; there's a useful purpose behind all of them. I'm just saying that you can't think about the CD market in the same way you think about the butter market. Butter is pretty much butter, but Madonna is not pretty much Weird Al.
Most other countries have the Copyright on recordings go into public domain about 50 to 90 years
Currently. And that's longer than it once was. There are a lot of people with a lot of money working to change that. Remember, I said, "in practice, eternal." The question is, will we let them?
Comparing music to sugar is a bit of a red herring because sugar is an amorphous white blob with ready substitutions.
I'd agree, but that was my point. The poster I was responding to was suggesting that CDs are just like any other commodity. You and I agree that they are different.
In other words, the law of supply and demand still holds in setting prices. [...] The substitutions for the Weird Al music exist as well: they're other songs and other forms of entertainment.
Oh, I'd agree; I'm just trying to say that the standard intution of markets people have can be misleading because of the monopoly and the differing substitution behavior. That's not to say the big labels can get away with murder, but they can get away with more than a producer of bulk commodities can. Thus, the matching markets-will-take-care-of-themselves intuition is less valid. Especially given the noted give-them-an-inch-and-they'll-take-a-mile abilities of RIAA member companies.
Just like everything else, CDs are subject to supply and demand market forces.
Well, no, they aren't, not entirely.
If one sugar producer decides the "true" price of sugar is $15 a pound, then you can buy sugar from somebody else. But if you want to buy the latest Weird Al or Madonna album, there's only source. It's a monopoly, an in theory limited but in practice eternal one called "copyright". If they double the price of the hot Madonna release, there are a lot of people who won't think that Weird Al is just as good, and vice versa.
It's also important to note that RIAA is a trade association of major music producers, not a single producer. If the major labels (heaven forbid!) were to get together and, say, fix prices then market forces would also not apply. Not that they would do such a thing; RIAA is here to help us. I'm just talking hypotherically, you see.
Yes. You, and eight zillion people who are getting most of their news via things other than dead trees.
From the article: "...the symbolic file link (or as it's called in UNIX, the soft link) finally arrives in Windows Vista." - anybody heard "soft link"? Me (after 10 years of using Linux) never...
Yes. The other, much more common kind of link is often called a "hard link". Symbolic links are, probably by analogy, called soft links. A quick look at Google finds thousands of references. You should check that Google thing out sometime; it's pretty cool.
I thought for once we could get through a Slashdot spam discussion without hearing the single most retarded thing people say on this topic. Apparently not.
using SQLgrey(listing), Spamassassin with ClamAV and bayesian filtering enabled (maybe plus Razor, Pyzor, DCC),
and not disabling the local bayes-filter in my Thunderbird [...] What's the actual problem?
Do you not see the contradiction? You are using seven different tools or services there.
Starting at least ten years ago and going up until recently, you couldn't have a discussion about spam with some chowderhead saying, "I just hit delete. What's the actual problem?" At least people finally dropped the "I just delete them" nonsense, so that's a start. The actual problem is that spam is a growing problem, and an arms race. Every technical, social, and legal solution we have implemented has been breached by spammers.
The actual problem is that we are now spending billions receiving, processing, storing, and hopefully detecting spam. TFA says that 75% of all mail is now spam. For me, with a few decade-old domains and one fifteen-year-old address, it's well over 90%. Every time we have this discussion on Slashdot, somebody says, "What's the big problem?" Every time, those numbers are worse.
How many nines of crap would you like before you're willing to call it a problem?
New languages every year isn't important in the way it once was; language innovation seems to have slowed compared to say the 1980's. Substitute new design patterns, application frameworks, libraries, etc instead.
That seems very reasonable to me. It's also great when programmers get really interested in what goes on under the hood, so doing microcontroller work or sysadmin stuff can be great, too.
Still, I think people shouldn't ignore languages. There's interesting work being done with domain-specific languages, especially for testing and enabling expert users. And there's enough history out there that I think a lot of non-fogey programmers would benefit by going back and spending some time playing with older languages. There are a surprising number of Java people who really only know Java and C or C++. Without having spent some time with other approaches, I feel like they have a pretty limited mental toolbox.
Great line. Can I steal it?
Absolutely. I'm glad to do anything I can do to reduce the amount of needless drama in the world.
As somebody who hires people at startups and small companies, my take is "maybe". Programmers are a quirky lot, and I try to take each one individually. Although the arrogant ones get the press, there are quite a number that are ridiculously modest, and you might be one of those.
Even if you aren't, there are advantages to age. The biggest one is maturity. There are mistakes that every novice makes that are (I hope!) behind you. Instead of a drama generator, you are probably a drama shock absorber. Even if your people skills aren't as great as you like, they're probably a lot better than 12 years ago. And best of all, you can see that with age comes some self-awareness. Everybody has problems, but in hiring one of the things I really look for is an awareness of your limitations and the ability to manage them yourself.
When evaluating somebody in your situation, one of the big questions I'd have aside from the usual ones (e.g, can you do the work) is whether you are still like the work and are eager to improve. For example, I feel like every programmer should learn a new language once a year. That doesn't mean that you become expert in it, just that you are stretching your brain. Or you might have a side project you're excited about. Or you might be studying software architecture patterns. Anything that proves you aren't a clock-puncher who just isn't sure what else to do.
So I'd say as long as you are doing work you want to do and doing it well, don't sweat it much. You may have to work harder to find a job than some young hotshot, but there are plenty of employers who value a steady producer who won't be a pain in the ass.
Hi, Christopher. First off, full marks for stepping up and explaining things honestly. You have done more good for Netscape than a dozen PR people. I'm sure you'll take a lot of crap from my fellow Slashdotters, but don't let it throw you. Listen to and acknowledge their legitimate complaints and you'll do fine.
I only wish that someone had brought it to our attention so that I didn't have to find out about it from Slashdot.
If you are looking to learn a lesson from this, how about this one: URLs are forever!
Whenever I make a change to a live server, my biggest concern is to not break existing usage. If I ever change an URL, I make sure to redirect old usage to new usage that's just as good. And if I'm ever not sure something is used, I generally look back at least three months in the logs. Especially if you've inherited a pile full of mystery, good analytical tools for your server logs are vital. Trying to run even a modestly-sized site without them is like running a large store without tracking your inventory: your life will become a series of unfortunate surprises.
I think Google has a case to answer here, I simply don't believe Microsoft maps can possibly legitimately be ranked where it is.
Since this is the first I had heard of Microsoft's map site, I am not struggling with this so much. First, if you search for "map", it's at position six. Looking at the Alexa comparison, the Wayback Machine (compare with the one for Google Maps), and the Wikipedia history for Microsoft's maps, this all seems appropriate to me.
And as the clincher, the SNL skit Lazy Sunday mentions Mapquest, Yahoo Maps, and Google Maps. No mention of Windows Live Local (or is it Microsoft Virtual Earth? Or, as you call it, Microsoft Maps?). As they say, "Google Maps is the best. Double true!"
But what about the privacy issues involved? Would you like it if your creepy next door neighbour was filming you for a couple of hours every day, just waiting for you to make a wrong move?
There's a next stage to this. It's when people start using electronic surveillance to expose and shame people who are taking electronic surveillance too far.
it is not in your companies interests to give reasons for rejecting a candidate.
I disagree.
When I reject, I generally just reject. Nicely, mind you. But without reasons.
If somebody asks why, however, and especially if they ask for feedback, I tell them. And not in terms of "you are lame because of X", either, but more like "well, for this job, we are looking for more of A". Or, "the person we hired had more experience with B". Or, "If I were you, I'd work on C".
I think it's worth the time just on grounds of general niceness. But that niceness pays off. Even if I don't hire a person now doesn't mean I won't hire them in the future. If they can spend a year building skills I want, we both win. And I've definitely had people say, "Oh, you should talk to my friend..."
For all sorts of reasons, I try to hire people with good social networks. If I hire them, I want them to tell all their friends what a cool outfit we are. And if I don't hire them, I want them doing exactly the same thing. If a little feedback will make them happy about the interview, I'm glad to give it to them.
Er, get a new job? A company that cares about certification, especially in a technology that you're not even using, doesn't sound like a good one to work for. When I see it on a resume, my first thought isn't "Wow, here's an expert!"; it's "Why did this person need to get certification?"
Amen. When I'm screening resumes, having certifications, especially a bunch of them, is a warning sign. It doesn't guarantee a trip to the trash can, but as with LauraW, it makes me suspicious. I'm hiring people to get things done, so what I'm looking for is people who have gotten things done.
When I see certifications, I'm worried that they're the kind of person who values the officially blessed answer over the one that works best. Or, worse, that they've spent a lot of time working for companies who have so little idea how to hire and promote programmers that they rely on multiple-choice tests.
Of course, I mainly work in startups and small companies, where the cost of a loose canon or a mediocre performer is intolerable. YMMV.
All of Google's businesses other than search generate little if any revenue. Really, stuff like Google's office systems exist to push back against Microsoft, not because running a word processor in the browser is a good idea.
This year, anyhow. From the people I've talked to there, they seem to be making a broad array of bets, many of which they don't expect to pay off for years. And that makes a fair bit of sense; if only one of them hits as big as their search/ad combination, it will keep them in the money for another decade.
Google has alot of money and they haven't had a chance to be taught a lesson in frugality. Once shareholders start demanding the impossible and they can not meet these demands with their profits from advertising only, you better believe that gourmet chef's job will be the first to go!
It's unlikely to come soon. By the stock price, the stockholders clearly believe that Google will do well not just from existing businesses, but from ones they have yet to create. They have gotten an amazing number of talented, creative people by offering to take a lot of bullshit out of their lives so that they can just make great stuff in an environment filled with other smart, happy, work-focused people.
If Google dumps the perks, many employees will (probably rightly) take it as a sign that Google management is more interested in this quarter's numbers than making creative products that will pay off five years from now. And they will leave. Going back to the small, VC-funded companies that are Silicon Valley's more traditional home for creative techies.
Why do I think this? Because currently I'm looking to hire engineers in the area, and Google is a giant vacuum cleaner. At least for the pals I have there, there's no hope of prying them loose. Not yet, anyhow.
Likewise, with software development (and really most computer systems development), everyone wants to rush out and start coding as fast as possible...but if they'd made sure there were no assumptions, defined their problem specifically, and spent way more time than they wanted to developing an architecture, the coding afterwards would just be data entry for the most part.
I think for many interesting problems, this is effectively impossible. That's because the future environment into which your software must fit is, for many projects, unknowable. Even if you really could collect every current available fact and carefully work out every logical implication, that wouldn't be enough because there are teams of other people just as smart as you working hard to beat you any way they can.
In the end, I've just accepted that requirements will change all the time. Every week our team says, "Given everything that we have figured out so far, what's the most useful thing to build this week?"
To you I'm sure that sounds crazy, but let me add that I agree with your next points: everything should be tested, we should invest vigorously in good architecture, in highly reusable code, and the product should be kept spotless and taut, like a well-run sailing ship. I think the only place we differ is in that you'd like to put most of that effort up front, while I'd like to do it continously.
At least for my environment, that seems more sustainable. Instead of fighting people for time up front, I start coding as soon as they feel like they can name one week of work that they're sure will be useful. But when they ask me to hack something together, to cut corners that we'll clean up in that mythical land called "later", that's when I fight them tooth and nail. Every week I give them some features they want built the best way I know how.
My other point is that it is virtually impossible to design an application when there are more than a few people all wanting to 'help' design.
I disagree. And I'd bet what you really mean is "I don't know how to..." not, "It is virtually impossible to..." Unless you have some mathematical proof that I'm unaware of.
You simply don't get as coherent a product if you have a team of designers all trying to push their agenda.
Yes. If you have a bunch of people trying to push agendas, that would be bad. What if you instead had a whole team that shared one agenda: the making of a great product? That's how I spend my days, and it works well for us.
Novels are typically written by one person (although chromatic's right, it's more "one primary person with a lot of collaboration" from what I've seen). But there are much more collaborative creative works. With my own eyes I've seen ensemble theater pieces with substantial creative input from a dozen people. Improvisational theater groups regularly produce extended coherent works with no central control. And I understand improvisational music works similarly.
For more information on this, see the excellent book Artful Making.
Although this would probably mean a huge downscaling of the software industry, as everyone would just write their own applications.
I doubt it. Take the example you mentioned, the printing press. There are now millions of people with the basic skills and material circumstances necessary to write and lay out a book and have it printed. How many do? And of those, how many write good ones? And how few write great ones?
For me it's been the ever-changing requirements which delay projects the most.
I think changing requirements are a fact of life. The only solution I see is to work in small enough increments that requirements change is a business problem, not a technical one.
The teams I run do weekly iterations, and that seems about right to me. A week is long enough to get something useful 100% done, but short enough that even the most antsy product manager can be persuaded to let the team focus on the work at hand. And then you ship the work and make a fresh start the following week.
Well, most of the time, anyhow. Occasionally a real emergency will come along and throw an iteration into disarray. But very worst case, you lose a week's work. And because the beginning of the next iteration is so close, most "emergencies" can really be handled in the normal course of things.
If the choice is between screwing yourself by becoming dependent on a bunch of different companies or screwing yourself by turning everything over to one monstrous internal bureaucracy, I'd say go with the former. It might be hard to fire one vendor and turn a project over to another, but it will be completely impossible to fire the central organization.
Really, though, I suspect you've created a false dichotomy. Among the vast soup of tasks you're looking at, some are probably done best by vendors, some by distributed internal staff, and some by centralized internal staff. But even for the centralizable ones, there's no reason it has to be the same center for each one, any more than your phone provider and your electric provider need to be the same company.
I'm curious - what evidence are you referring to? I'd like to read it - and no, your own personal, anecdotal incident does not count as evidence.
Yes, I am aware that anecdotes do not add up to data. Foolishly, I was thinking people could use Google. Thanks for setting me straight on that.
For a consumer-level intro, start with "Punished by Rewards" by Kohn.
Of course lack of capital can be disastrous and create serious barriers to entry for wanna-be capitalists. However, I argue that the main cause of poverty is lack of skills, intelligence, imagination, and ability.
Seriously, do you know many poor people?
You should really take a closer look at success microfinance has had. People get loans for things like cows or hand tools or sewing machines. They can already imagine the cow. They may not have the precise skills needed, but the group loan structure means that their neighbors will be making sure they learn them. They are already reasonably intelligent, and the ability needed to work a cow is, while not small, well within their reach. What they need is capital and support from their community.
When they get it, the numbers are amazing. The last microfinance organization I visited had, on over 100,000 loans, a 100% repayment rate. It sounds crazy, but it's true.
The fundamental problem with Extreme Programming is that it proceeds from the assumption
that no one on the team is a good software designer.
I don't know who gave you that idea, but they got it pretty wrong.
Some of the leaders of Extreme Programming and other agile methods are fantastic designers. Martin Fowler, for example, produces a fine variety of books on design. Eric Evans is another good example. Personally, I'm also a big fan of great design, and like XP precisely because it helps me produce better-designed code. Here's why:
I'm sure we concur that the biggest factor in the quality of your design is the information you have. If I just say, "Give me a design for a system," and leave it at that, I've given you zero information; no matter how good your skills are, your design is unlikely to be the right one. And the more you know, the better off you are. Agreed?
An inescapable fact about a software project is that you know the least at the beginning and the most at the end. Even if your research is 100% perfect (which, since that would be infinitely expensive, it won't be) new information will come to light. People will say, "Now that I've used X, what I really want is Y and Z." Your competitors, who are actively hiding as much as they can from you, will release new things. An executive will get replaced, causing a shift in direction. The business environment will change.
Ergo, we should wait as late as possible until making design decisions, so that we have maximum information. And we should keep things as flexible as possible, so that when we figure out something better, or when the world changes and our design is no longer optimal, we can correct the design at low cost. Which is XP's basic approach to design.
I also feel that XP is a big step forward because one isn't supposed to think about or invest in the design just at the beginning. It's a continuous process, so one never stops thinking about the design. It's not just for one person; everybody coding is supposed to be thinking about how to improve the design. And since I get to pair with everybody, they get to learn how I design, and I get to learn tricks from them.
Sure, like you, I spend plenty of time at the beginning of a project thinking about where it's going, and coming up with plausible answers; I want to be sure I won't paint myself into a corner. Those plausible answers look a lot like the napkin-and-notebook versions of design documents. The difference is that when I set down at the keyboard, I don't pay them much mind. We came up with them once, and generally I'm not afraid we won't come up with something just as good. If we get stuck, I may go back and look at early designs for inspiration, but I may just as happily look elsewhere. There's no reason to limit my thinking to the best ideas we had months ago.
Of course, that sort of change would be impossible without high-quality, well-tested code. Which is also why I do test-driven development, refactor mercilessly, and pair.
Does that make it clearer? If I thought XP produced bad designs, or was for people who can't design, I'd drop it a hot second. But having tried developing both ways, I have no questions which gives me more design time or produces better design results.