We didn't use XP to the full extent either, no automatic testing and no true pair programming but that was only because we didn't have time to change ourselfs.
Thanks for being honest about this; so many people say, "We're doing XP!" while leaving those things out.
When you get the chance, try them. Their contribution to quality is immense. Once a team gets good at pair programming and automated testing, bug rates can get below 1 per month.
That improves things dramatically. Because you spend less time on bugs, you spend more time on features. Because the system is solid, the people paying the bills are happier. And both of those are great for team morale.
If you sit on a fully financed military project for instance I doubt that XP will work for you.
Why would you say that? XP is good at creating an island of sanity in the midst of chaos, but I don't see why it wouldn't work well in a stable environment.
Having participated in a number of OSS projects, and even led/maintained a few, I can't see how Extreme Programming can help - the model is clearly better suited for in-house programming than distributed programming.
I was part of a group that tried doing an OSS/XP project. Your instincts about XP are pretty reasonable.
The main problem we had was getting enough of the team together in one place for long enough to make progress. XP really depends on proximity for communication; that's how it gets away without having any mandatory documentation.
On the other hand, pair programming really helped keep everybody in sync. People could turn up intermittently and that wasn't a problem; they'd just pair for a while with somebody who had been there the previous week.
Another piece that worked really well was mandatory 100% test coverage and test-driven development. A newbie could try out changes and find out quickly if they worked well with the rest of the system or not. And if a newbie somehow broke something without a test case catching it, the attitude was, "Well, I guess our test coverage wasn't as good as it should have been." It was nice for new contributors not to feel scared.
XP teams also have less "truck factor" problems than traditional teams do. A lot of OSS projects really depend on one visionary who does most of the work; on our XP/OSS project it wasn't a big problem if any single person took some time away from it.
Plus, it was also much more fun having a bunch of people in a room. Doing an OSS project solo can be lonely and disheartening sometimes; it was nice to get beers together after the coding sessions.
My initial impression of XP (I haven't tried it but had it explained to me)
Hi! I'd recommend that you try it. I've done it for a few years, and my impressions are different. In particular:
is that it takes a lot of the fun and programmer-as-artist aspect out of software development.
This is certainly not the case on the projects I've been on. Why? A few reasons, I think:
In traditional proceses, somebody drops a big requirements document on your desk and then comes back in a year to tell you that what you've built is all wrong. In XP, you work in close collaboration with the product manager. The product manager still makes the final decision on what features to build, but you have plenty of opportunity to suggest and question. I feel like there's a lot more of me in the output of the XP projects I've worked on.
At the level of coding, XP is even better. XP says that design is so important that we should never stop thinking about it. It demands that we, through merciless refactoring, continually maintain the best design possible, with no compromises and no excuses. On an XP project, I rarely feel like I'm doing some bit of boring work. And when I am, it's always a sign to me that I'm missing the chance to automate that drudgery away.
You know how that when you want to look at somebody's code, they apologize for it being messy? I rarely feel that way on an XP project; XP lets me make code I'm proud of.
Also it is good for making a larger number of so-so programmers as productive as a few really good programmers.
That's not correct. First, maximum XP team size is circa 12. Second any XP expert will tell you that no process will give you good software from bad people. However, XP helps you make the best use of what you have, and does really help with cross training, so that junior people become senior people much more quickly than under less collaborative conditions.
Right now I'm building a new XP team, and I'm not looking for mediocre people. I'm going to get the 6 best people I can. An expert might cost twice as much as a newbie, but an expert is much more than twice as productive, especially in an XP environment, where everybody is encouraged to play at the top of their game all the time.
As we buy Asian products they use that money to buy assets here in the US, as more and more factors of production move offshore (which ricardo said could not happen for his theory of Comparative advantage to be valid).
What factors of production are the Asians buying, exactly? If I understand you rightly, wouldn't they have to buy up a sufficient number of, say, movie cameras that we couldn't produce as many movies?
At a certain point another country will overtake the US as the importing country of choice. When this happens you shall see a massive and nasty devaluation of the dollar.
You're already seeing a slow collapse of the dollar. This will probably go on for decades thanks to Bush defecits and our current account debt. But it's unlikely to be sudden; the various purchasers of dollars (and dollar assets) are driven by forces that will take decades to shift.
And if our currency is lower, that's great for American jobs; that makes our exports cheaper.
As more and more white collar jobs move overseas, you shall see the collapse of both social mobility in the US and the middle class. Increasingly the US will look like a third world country.
That strikes me as unlikely. We will still have a large, well-educated workforce, plenty of capital, good infrastructure, and an entrpreneurial culture second to none. People have been predicting the death of the middle class and massive unemployment since the beginning of the Industrial Revolution, but we've always found something to do. Or rather, smart people have always found productive ways to keep busy.
I think the only thing that will change is that instead of focusing mainly on the US as a market, we'll pay some attention to all those new Asian consumers, the same way they've been paying attention to us for the last 40 years.
You're completely right about Brooks and Deming! But I can't let this pass:
The other point is that it is not fair trade, the jobs leave and labor cannot follow. This is not fair trade.
I see. Is it unfair trade that, say, US movies are so successful around the world? Perhaps we should be noble and shut down Hollywood so that local film industry jobs around the world can flourish?
Of course not. Free trade is a positive-sum game; blocking trade makes us all poorer. If India can make better software for less, then more power to them.
But I think, for exactly the reasons you cite, they can't. In the same way that the Japanese competition forced American cars to improve drmatically, Indian competition will force American software developers to improve. And as you say, they could start by doing the things that Brooks was recommending 30 years ago.
no one seems to have a good idea just how to afford that lateral move and the training it entails, especially for the poor schmucks that are just now graduating
Well, actually, the idea is pretty obvious, and has been used repeatedly for the previous wave of outsourcing in manufacturing jobs.
The basic notion of free trade is it that it makes people richer. (If not, the parties involved wouldn't trade.) We all buy electronics made in Asia because they're cheap; that's a great deal for us as consumers (because we get to have more stuff for the same money) and it's a great deal for Asian manufacturers and their employees (because they get a slice of our wealth). In the long run, everybody is better off.
But as you point out, in the short run people whose jobs go overseas are in a pickle; they have trained for a job that's no longer available. The solution is to tax consumers a bit (so their cheap imports aren't quite as cheap) and pay for job retraining and income support.
There are some programs like this for lost manufaturing jobs, and there should be more. And their needs to be support for those harmed by the new wave of white-collar jobs. Write your congressman!
But the solution isn't to block trade. Trade makes us all richer, and blocking it makes us all poorer.
so what if 6 programmers offshore can't do his job
He's perfect for my new business plan. I call it "double offshoring".
You get a half-dozen kick-ass developers in the US. Then you hire one guy in Bangalore, a "project manager," and put him in an office with a web server and a VOIP PBX. You have him pretend to be running a team of 60 developers in Bangalore.
Then you have one of your US developers pretend to be the US liason to your Indian development team. But instead, he just relays all the client requests to the developers sitting around him. They are happy and motivated, as they are collecting the salary of 10 indian programmers, or $100 per hour, gross. You can even let them talk to the clients occasionally via that Banglore VOIP link; they just have to practice their Apu.
How could this work? Keep in mind that much of the outsourcing work is coming from Fortune 1000 companies. Their standards are already woefully low, or they'd notice that having your developers on the other side of the planet substantially hinders things. So whether they compare you with internal efforts or with outsourcing to India, there is a lot of slack to mine:
Developers at large companies are, on average, pretty average. In fact, from what I've seen, generally below average. (Why? I think this is partly because top people don't like to put up with large-company bullshit, and partly because large companies tend to pay salaries that don't reflect how productive top people are. Also, large companies are much more reluctant to fire people than small ones, so they tend to keep idiots around.)
Studies show that the productivity ratio between top developers and low-grade ones is at least 10:1. And my experience leads me to think it is greater: I've certainly seen projects where the low-end developers, because of how many mistakes they made, were negatively productive.
Large companies also have huge managment overheads. I've seen places where the developers spent at least half their time complying with big-company bullshit, including meetings, reports, superfluous documentation, political nonsense, and process rituals.
Just like the Internet boom sucked a lot of inexperienced and/or untalented workers into the US developer market, so to is the outsourcing boom doing in India. Although there are surely good outfits there, I've heard many horror stories about work outsourced to India.
There's value to understanding the culture. A person who has lived in the US for several years will have picked up a lot of subtle information about the way we do business and live our lives. We in the US have a hard time writing software for non-western countries, and the reverse certainly applies.
Large teams spend a lot of time on communication. Six developers can stay in sync just by being in the same room; with 60 you need all sorts of formal mechanisms to even come close to the same level of coordination.
Put this all together, and a small team of experts will kick so much ass that they'll be more productive than an entire floor of Fortune 1000 mediocre clock-punchers. That leaves plenty of financial room to give big enough discounts that people will think you must be sending the work off to India. As an aside, a friend who works for a large company tells me that their outsourcing efforts are actually only 50% of the cost of in-house development, not 20%. That's because you still pay for US personnel (like product managers). You also make their lives much more difficult by putting the developers on the other side of the planet. And the communication barriers mean more mistakes discovered later, which means expensive rework.
This is bad. Code conventions aren't global, they are local. Each shop has their own. Why should I be forced to use your convention? It's the wrong convention! It doesn't match any of my other code!
I was referring mainly to local conventions. When I'm working on a team, I work hard to make sure my objects serve as good examples for everybody else.
But if one is publishing code to the outside world, it's good to do it in a fashion that works with common conventions. In Java, for example, almost all the published code I've seen uses most of the standard Sun style, especially for naming.
But Spirit was only transmitting "pseudo-noise", a random series of zeroes and ones in binary code and not anything the scientists could decipher. - BBC News
Searching for certificates is the wrong way to handle this. I advise to simply make it a policy to not use any certificates for company use which are not maintained by you.
Ok. The original poster's solution isn't so great, but just declaring it "policy" is about three orders of magnitude dumber.
Here's a simple, 4-step plan to solving the problem.
understand the problem -- Find out why people are creating their own certificates. There will be plenty of legitimate reasons.
give them something better -- Figure out a solution that addresses their needs as well as yours. And wherever possible, make it easier than what they're doing now. For example, create a web-based application that lets anybody in the company instantly get an officially blessed certificate.
make a policy -- Explain, in clear business terms, why your policy is the least-impact way to solve a real business problem.
enforce it -- Now you can set up the fancy automated scanner.
Remember, the other people in your company are, for the most part, doing their jobs in the best way that they know how. (And even when they aren't, it's best to start off treating them that way.) If you know something about how they could do their jobs better (e.g., by improving security though better certificates), then help them to achieve that.
But for fuck's sake, don't just go imposing random mandates on other people like some third-world dictator. I've consulted at some large companies that have so many rules, mandates, procedures, and forms that it's impossible to get anything productive done. And most of the good people figure that out and leave.
With DP case sensitvity just gets in the way - the programmers may not be very technical and any maths used would probably only be complicated by use of the 'same' name for different variables. [...] As Java is often marketed as a DP language it's case-sensetivity is a serious drawback (at least as far as DP is concerned - in other areas of Java's use it may be usefull).
I think a better distinction is between scripting languages and programming languages. Scripting languages are meant for short bits of coding by non-experts. Programming languages are meant for large bases of code built by professionals.
It's a continuum, of course; no language is used for only one of those. But Java is clearly intended to be pretty far towards the professional end of the spectrum. Non-experts working on small projects should pick a language better suited to their needs; Java will seem to them to be balky and annoying.
And as an aside: non-experts should stick to small projects. I think the huge danger with scripting languages (in which category I'd include things like pre-dot-net VB) is that although they are great getting non-programmers into doing a little programming, they let people get away with a lot of stuff that is dangerous on larger scales.
It's as if a guy who successfully changed a lightswitch in his house grabbed his trusty screwdriver and tried to tackle wiring a 500-rack server facility. He might get some stuff working, but it would be flaky, dangerous, and impossible to maintain. Just like so many code bases I've seen put together by "not very technical" programmers.
most programmers I work with need to have discipline imposed on them
Quick tip from one who has tried: imposing discipline on programmers doesn't work in the long run. It doesn't scale; as soon as you stop doing the imposing, they stop doing the discipline. Instead, structure your environment such that they are faced with the pain of their screwups promptly and frequently.
For example, if you give a programmer a particular area of the code that is their own domain and that only they work on, then they have months in which to repeatedly screw up without apparent consequence. Worse, it's so much work to clean up the mess that they're generally allowed to get away with it.
But if you do code reviews, you can reduce that time to a week or two. Add collective code ownership and short iterations and you can get it to days. Add pair programming and you can shorten the feedback loop to minutes.
You should especially favor techniques where peers are the ones doing the bitching, rather than management, and where their complaints are about practical things. Consider how you'd feel hearing a manager say, "You have violated the coding standard that a consultant told us we should follow. Go back and clean it up." Now consider how you'd react to a guy on your team saying, "Dude, I'm trying to extend that code you wrote yesterday and I can't make heads or tails of it. Could you help me clean it up?"
readability has nothing to do with case sensitivity. Code is kept readable by programmers that use sane variable names and, the occasional uppercase letter.
Good start, but take it a little farther.
If you add case sensitivity, then the programmer who designed an object can be sure that people using his object will follow his conventions for capitalization.
This is good in two ways: It makes it harder for somebody sloppy to get away with being sloppy. Also, it gives people who design objects an incentive to be a little more thoughtful; if they screw up on the variable names, they will get unhappy feedback from the users of those objects.
But at least here, in the courts, you can buy a good lawyer (White Anglo-Saxon if need be) no matter which race you are.
Have you ever actually gone to court? For middle-class Americans, even a moderate court battle can be a devastating financial blow. For an immigrant, visitor, or somebody who's just poor, the costs can make good representation impossible.
There are many bleeding hearts out there who will fight for your cause no matter how evil or good you may actually be, as long as you have a good story about being oppressed.
That may be the case in Canada. In the US, there are certainly a number of lawyers that do fantastic pro bono work, but it's not a large number. The public defender system in many areas is woefully underfunded, and that doesn't cover civil cases at all.
Some wags claim that in the US, you get all the justice you can afford. It's not that bad, but it's certainly far from perfect.
You really have to bite your tongue, be polite, keep your opinions to yourself, and be a gracious guest. Saudi justice is not american justice (in court, if it's a muslim's word against a christian's word, the christian can lose automatically) You're NOT a citizen there, and if you forget that detail, you can get yourself in serious trouble.
I don't want to deny the seriousness of your comment at all, and I think overall America is much better than average about how we treat foreigners. But I have a number of Sikh and Muslim friends, and they have similar concerns about the US, even the ones who are citizens, even the ones who grew up here.
They feel the threat not just from ignorant yutzes, but also from the government. Just last night a dear Indian-American friend who grew up in the Detroit area was telling me about her Sikh aunt and uncle's recent visit. Pulled aside for questioning, presumably because of his turban, the uncle did his best to answer their questions in English, a lanugage he's not so familiar with. Long story short, they decided he was being sneaky rather than puzzled and confiscated his passport. A two week visit turned into two months of lawsuit to get his passport back.
Again, I say this not to undermine your point about Saudi Arabia, but just to remind everybody else that it's easy to forget that although we may feel safe in our country and generally trust in the government to behave responsibly, it's easy for foreigners to have a pretty different view of things.
The system doesn't work against paper mills because the output of a paper mill is new content, that's why it is a mill.
That's not very plausible to me. There are certainly sites that sell thatsellpre-existingtermpapers, so this will catch those.
You're right that there are places that offer custom-written ones, but a) you have no real way of knowing that they aren't reusing passages, b) they're much more expensive than pulling them from a database, and c) it's hard for a writer to write basically the same paper over and over without accidentally repeating themselves. An anti-plagiarism database won't stop this completely, but it will make it harder.
You've missed my point entirely. RDBMSes aren't just about storage; they're also about retrieval and processing. Many people don't seem to get that you can build applications without using an RDBMS.
word processors store data in flat files, if you need a whole class on flat files, you need help
Yes, they store it that way. But do they make changes to documents via SQL queries? No.
Also, there's a big difference between dumping some stuff out to disk and a good file format, especially one that needs to be upgradable and interchangable over the span of many years. Having reverse-engineered a number of file formats, I'd say a lot of programmers apparently need a class in file format design.
Networked Quake doesn't even store data on any scale, other than log files.
Except, of course, for megabytes of level data, used mostly on the client. But my point is that Quake, and especially networked Quake, does a whole lot of intense processing of data in a cooperative fashion without a line of SQL. Why? Because it's too slow and doesn't manage the data in the ways that you need.
And I think Google uses an RDBMS at the back end to handle some of the indices. I could be wrong on that one though
Unless they've made radical adjustments, they use no RDBMS in their search. I've heard they use 'em for billing and reporting on the AdWords stuff, but as far as I know, the live stuff gets nowhere near an RDBMS. As it shouldn't.
Why are you taking three semesters of 3 different databases? Have one course: Relational Databases, and take a week to explain the difference between the three. You aren't trying to get someone their certification before graduation.
Heck, why not take out the word "relational" and cover the broader topic?
I'm so tired of hiring people who think there is no possible way to store data besides a relational database. I can't count the number of people I've had to grab by the ear and drag around the office saying, "Look! A word processor! Look! Networked Quake! Look! A giant LDAP directory! Look! Google! None of these things use relational databases but they somehow still haven't fallen over and died. How is this possible?"
Ok! Sorry. My rant for the week is over. I just couldn't take it anymore.
I don't like the class on basic HTML--if you can't pick that up on your own, you're in the wrong major. In fact, I was flat out told that by a professor in one of my first CIS classes.
It would depend on the purpose of the class. In a CS curriculum, I'd agree; a person who can't puzzle out basic HTML should probably look elsewhere.
But in a vocational education program, HTML's not a bad thing to learn. I've been doing adequate HTML since before Netscape, but when I need HTML done right, I always bring in an expert who understands making things that look pretty but that will degrade well on older browsers and weird devices like the new generation of wireless handhelds.
IPv6 doesn't solve the problem of how to reach private addresses, it merely provides tons more public ones to eliminate the need for private ones. Except the lack of public addresses isn't the only reason for the modern use of NAT anymore.
Is there another reason besides security? If so, that's not a big reason; you can still have NAT-style security (dynamic approval of outgoing connections but static configuration of allowed incoming connnections) without a lot of work.
with home-type setups you're liable to get endless clashes
The typical solution here is to have the VPNs set up to do some remapping. Technically, this strikes me as ugly, but a lot less ugly than redoing IP to accomodate bang-path routing. And people have been doing it on a large scale for at least ten years, so the problems are pretty well understood.
But if everybody needs to talk to everybody, the real solution is to give everybody a routable address. Anything other than that is a hack, and hacks grow increasingly expensive over time to maintain, as you have to code for the base layer, the additional hack layers, and all of the weirdnesses that the hacks result in. One fine example is this SpeakFreely package; the thing that pushed him over the edge is trying to deal with the hack of NAT.
Of course they'll incur a significant cost -- more hosts per customer means more traffic per customer.
I'm not sure that's an "of course". Although I'm TVless, my family back home has a number of TVs. I don't think much more television-watching gets done when you add multiple TVs to a house, and I think home computers are already going that way. The first wave of internet appliances failed, but with 802.11 becoming so common, the $300 small terminal in the kitchen becomes more reasonable. Ditto for the internet-enabled appliances.
Some ISPs already forbid attaching more than one machine. IPv6 will not cause them to become more agreeable.
Yep. Some do that to squeeze money out. Some do that because it may really correlate with their costs. (It would for business lines, for example.) The first approach will be less tenable if we end up with good broadband competition.
The second, using IP addresses as a cheap correlate for bandwidth usage, may make sense for some. But if bandwidth is the issue, it's better just to charge for that; it mainly takes better accounting and billing systems. An active file trader probably uses 100 times the bandwidth of somebody checking email, so just number of IPs probably doesn't correlate so well in the home market.
If you're doing your job right, you're probably doing your best to make sure it is blocked at the firewall. It's a workplace, not the users personal playground. Not every application should be allowed to run inside your network. It's the companies' network, not the user's.
That depends on what kind of company you're at. If workers are treated as machiery, that's probably true. For example, running a big call center, you might be able to argue that things should be locked down.
But there are other kinds of companies out there. Any software development shop, for example, that locks things down excessively will lose good developers at an astonishing rate. In fact, pretty much any company where you have people needing to do creative work, there's benefit to locking things down as little as possible.
If there's a legitmate reason to allow an application access to the network, then you can configure the network to allow it. Otherwise, the network's firewall should be blocking it by default. That's what a good netadmin does. Duh.
If a network is of the size and resources to afford a good netadmin who isn't overworked, then that makes sense. I'd guess that covers, say, 5% of the computers out there. For the bulk of the population, we need better solutions.
Well, you use a third-party server to find out the IP address and local port of the other side - and then you just start sending UDP packages. The first few will be lost, but then it should work.
No, it can't work if both are NATed. Here's why:
Start with the case of one NATed box (call it A) and one with a real IP address (B). They meet on a real server, and B gives its address and port. Call it 12345. So A sends B a packet from port 10000 to B's port 12345. A's NAT box notices this, remaps 10000 to, say 20000, and remembers that packets from B on port 20000 are for A's port 10000. Then it sends it on, and all is merry.
So now imagine that B gets stuffed behind a NAT box. A and B meet again and try to swap address and port numbers. The server can figure out the IP addresses of both NAT boxes, so A could send out a packet to B's NAT box. But what port does A send it to? And how will B's NAT box know that the packet goes to B?
As far as I can see, there's no way for this to work without B being able to tell the NAT box to forward a particular port.
What we really need is a generic method of sub-addressing machines.
We already have at least two.
One is IPv6. The other is VPNs. Instead of coming up with a completely new mechanism and getting it in the routers, we should go with one that we've been working on for a while and just get it deployed.
Slashdot Mirror
We didn't use XP to the full extent either, no automatic testing and no true pair programming but that was only because we didn't have time to change ourselfs.
Thanks for being honest about this; so many people say, "We're doing XP!" while leaving those things out.
When you get the chance, try them. Their contribution to quality is immense. Once a team gets good at pair programming and automated testing, bug rates can get below 1 per month.
That improves things dramatically. Because you spend less time on bugs, you spend more time on features. Because the system is solid, the people paying the bills are happier. And both of those are great for team morale.
If you sit on a fully financed military project for instance I doubt that XP will work for you.
Why would you say that? XP is good at creating an island of sanity in the midst of chaos, but I don't see why it wouldn't work well in a stable environment.
Having participated in a number of OSS projects, and even led/maintained a few, I can't see how Extreme Programming can help - the model is clearly better suited for in-house programming than distributed programming.
I was part of a group that tried doing an OSS/XP project. Your instincts about XP are pretty reasonable.
The main problem we had was getting enough of the team together in one place for long enough to make progress. XP really depends on proximity for communication; that's how it gets away without having any mandatory documentation.
On the other hand, pair programming really helped keep everybody in sync. People could turn up intermittently and that wasn't a problem; they'd just pair for a while with somebody who had been there the previous week.
Another piece that worked really well was mandatory 100% test coverage and test-driven development. A newbie could try out changes and find out quickly if they worked well with the rest of the system or not. And if a newbie somehow broke something without a test case catching it, the attitude was, "Well, I guess our test coverage wasn't as good as it should have been." It was nice for new contributors not to feel scared.
XP teams also have less "truck factor" problems than traditional teams do. A lot of OSS projects really depend on one visionary who does most of the work; on our XP/OSS project it wasn't a big problem if any single person took some time away from it.
Plus, it was also much more fun having a bunch of people in a room. Doing an OSS project solo can be lonely and disheartening sometimes; it was nice to get beers together after the coding sessions.
My initial impression of XP (I haven't tried it but had it explained to me)
Hi! I'd recommend that you try it. I've done it for a few years, and my impressions are different. In particular:
is that it takes a lot of the fun and programmer-as-artist aspect out of software development.
This is certainly not the case on the projects I've been on. Why? A few reasons, I think:
In traditional proceses, somebody drops a big requirements document on your desk and then comes back in a year to tell you that what you've built is all wrong. In XP, you work in close collaboration with the product manager. The product manager still makes the final decision on what features to build, but you have plenty of opportunity to suggest and question. I feel like there's a lot more of me in the output of the XP projects I've worked on.
At the level of coding, XP is even better. XP says that design is so important that we should never stop thinking about it. It demands that we, through merciless refactoring, continually maintain the best design possible, with no compromises and no excuses. On an XP project, I rarely feel like I'm doing some bit of boring work. And when I am, it's always a sign to me that I'm missing the chance to automate that drudgery away.
You know how that when you want to look at somebody's code, they apologize for it being messy? I rarely feel that way on an XP project; XP lets me make code I'm proud of.
Also it is good for making a larger number of so-so programmers as productive as a few really good programmers.
That's not correct. First, maximum XP team size is circa 12. Second any XP expert will tell you that no process will give you good software from bad people. However, XP helps you make the best use of what you have, and does really help with cross training, so that junior people become senior people much more quickly than under less collaborative conditions.
Right now I'm building a new XP team, and I'm not looking for mediocre people. I'm going to get the 6 best people I can. An expert might cost twice as much as a newbie, but an expert is much more than twice as productive, especially in an XP environment, where everybody is encouraged to play at the top of their game all the time.
As we buy Asian products they use that money to buy assets here in the US, as more and more factors of production move offshore (which ricardo said could not happen for his theory of Comparative advantage to be valid).
What factors of production are the Asians buying, exactly? If I understand you rightly, wouldn't they have to buy up a sufficient number of, say, movie cameras that we couldn't produce as many movies?
At a certain point another country will overtake the US as the importing country of choice. When this happens you shall see a massive and nasty devaluation of the dollar.
You're already seeing a slow collapse of the dollar. This will probably go on for decades thanks to Bush defecits and our current account debt. But it's unlikely to be sudden; the various purchasers of dollars (and dollar assets) are driven by forces that will take decades to shift.
And if our currency is lower, that's great for American jobs; that makes our exports cheaper.
As more and more white collar jobs move overseas, you shall see the collapse of both social mobility in the US and the middle class. Increasingly the US will look like a third world country.
That strikes me as unlikely. We will still have a large, well-educated workforce, plenty of capital, good infrastructure, and an entrpreneurial culture second to none. People have been predicting the death of the middle class and massive unemployment since the beginning of the Industrial Revolution, but we've always found something to do. Or rather, smart people have always found productive ways to keep busy.
I think the only thing that will change is that instead of focusing mainly on the US as a market, we'll pay some attention to all those new Asian consumers, the same way they've been paying attention to us for the last 40 years.
As long as we're shutting down Hollywood, can we get the major music companies shut down too?
With their brilliant internet strategy ("Internet bad! Must sue customers!") they're doing pretty well at that on their own...
You're completely right about Brooks and Deming! But I can't let this pass:
The other point is that it is not fair trade, the jobs leave and labor cannot follow. This is not fair trade.
I see. Is it unfair trade that, say, US movies are so successful around the world? Perhaps we should be noble and shut down Hollywood so that local film industry jobs around the world can flourish?
Of course not. Free trade is a positive-sum game; blocking trade makes us all poorer. If India can make better software for less, then more power to them.
But I think, for exactly the reasons you cite, they can't. In the same way that the Japanese competition forced American cars to improve drmatically, Indian competition will force American software developers to improve. And as you say, they could start by doing the things that Brooks was recommending 30 years ago.
no one seems to have a good idea just how to afford that lateral move and the training it entails, especially for the poor schmucks that are just now graduating
Well, actually, the idea is pretty obvious, and has been used repeatedly for the previous wave of outsourcing in manufacturing jobs.
The basic notion of free trade is it that it makes people richer. (If not, the parties involved wouldn't trade.) We all buy electronics made in Asia because they're cheap; that's a great deal for us as consumers (because we get to have more stuff for the same money) and it's a great deal for Asian manufacturers and their employees (because they get a slice of our wealth). In the long run, everybody is better off.
But as you point out, in the short run people whose jobs go overseas are in a pickle; they have trained for a job that's no longer available. The solution is to tax consumers a bit (so their cheap imports aren't quite as cheap) and pay for job retraining and income support.
There are some programs like this for lost manufaturing jobs, and there should be more. And their needs to be support for those harmed by the new wave of white-collar jobs. Write your congressman!
But the solution isn't to block trade. Trade makes us all richer, and blocking it makes us all poorer.
He's perfect for my new business plan. I call it "double offshoring".
You get a half-dozen kick-ass developers in the US. Then you hire one guy in Bangalore, a "project manager," and put him in an office with a web server and a VOIP PBX. You have him pretend to be running a team of 60 developers in Bangalore.
Then you have one of your US developers pretend to be the US liason to your Indian development team. But instead, he just relays all the client requests to the developers sitting around him. They are happy and motivated, as they are collecting the salary of 10 indian programmers, or $100 per hour, gross. You can even let them talk to the clients occasionally via that Banglore VOIP link; they just have to practice their Apu.
How could this work? Keep in mind that much of the outsourcing work is coming from Fortune 1000 companies. Their standards are already woefully low, or they'd notice that having your developers on the other side of the planet substantially hinders things. So whether they compare you with internal efforts or with outsourcing to India, there is a lot of slack to mine:
- Developers at large companies are, on average, pretty average. In fact, from what I've seen, generally below average. (Why? I think this is partly because top people don't like to put up with large-company bullshit, and partly because large companies tend to pay salaries that don't reflect how productive top people are. Also, large companies are much more reluctant to fire people than small ones, so they tend to keep idiots around.)
- Studies show that the productivity ratio between top developers and low-grade ones is at least 10:1. And my experience leads me to think it is greater: I've certainly seen projects where the low-end developers, because of how many mistakes they made, were negatively productive.
- Large companies also have huge managment overheads. I've seen places where the developers spent at least half their time complying with big-company bullshit, including meetings, reports, superfluous documentation, political nonsense, and process rituals.
- Just like the Internet boom sucked a lot of inexperienced and/or untalented workers into the US developer market, so to is the outsourcing boom doing in India. Although there are surely good outfits there, I've heard many horror stories about work outsourced to India.
- There's value to understanding the culture. A person who has lived in the US for several years will have picked up a lot of subtle information about the way we do business and live our lives. We in the US have a hard time writing software for non-western countries, and the reverse certainly applies.
- Large teams spend a lot of time on communication. Six developers can stay in sync just by being in the same room; with 60 you need all sorts of formal mechanisms to even come close to the same level of coordination.
Put this all together, and a small team of experts will kick so much ass that they'll be more productive than an entire floor of Fortune 1000 mediocre clock-punchers. That leaves plenty of financial room to give big enough discounts that people will think you must be sending the work off to India.As an aside, a friend who works for a large company tells me that their outsourcing efforts are actually only 50% of the cost of in-house development, not 20%. That's because you still pay for US personnel (like product managers). You also make their lives much more difficult by putting the developers on the other side of the planet. And the communication barriers mean more mistakes discovered later, which means expensive rework.
This is bad. Code conventions aren't global, they are local. Each shop has their own. Why should I be forced to use your convention? It's the wrong convention! It doesn't match any of my other code!
I was referring mainly to local conventions. When I'm working on a team, I work hard to make sure my objects serve as good examples for everybody else.
But if one is publishing code to the outside world, it's good to do it in a fashion that works with common conventions. In Java, for example, almost all the published code I've seen uses most of the standard Sun style, especially for naming.
But Spirit was only transmitting "pseudo-noise", a random series of zeroes and ones in binary code and not anything the scientists could decipher. - BBC News
The Martians probably just upgraded the codecs.
Ok. The original poster's solution isn't so great, but just declaring it "policy" is about three orders of magnitude dumber.
Here's a simple, 4-step plan to solving the problem.
- understand the problem -- Find out why people are creating their own certificates. There will be plenty of legitimate reasons.
- give them something better -- Figure out a solution that addresses their needs as well as yours. And wherever possible, make it easier than what they're doing now. For example, create a web-based application that lets anybody in the company instantly get an officially blessed certificate.
- make a policy -- Explain, in clear business terms, why your policy is the least-impact way to solve a real business problem.
- enforce it -- Now you can set up the fancy automated scanner.
Remember, the other people in your company are, for the most part, doing their jobs in the best way that they know how. (And even when they aren't, it's best to start off treating them that way.) If you know something about how they could do their jobs better (e.g., by improving security though better certificates), then help them to achieve that.But for fuck's sake, don't just go imposing random mandates on other people like some third-world dictator. I've consulted at some large companies that have so many rules, mandates, procedures, and forms that it's impossible to get anything productive done. And most of the good people figure that out and leave.
With DP case sensitvity just gets in the way - the programmers may not be very technical and any maths used would probably only be complicated by use of the 'same' name for different variables. [...] As Java is often marketed as a DP language it's case-sensetivity is a serious drawback (at least as far as DP is concerned - in other areas of Java's use it may be usefull).
I think a better distinction is between scripting languages and programming languages. Scripting languages are meant for short bits of coding by non-experts. Programming languages are meant for large bases of code built by professionals.
It's a continuum, of course; no language is used for only one of those. But Java is clearly intended to be pretty far towards the professional end of the spectrum. Non-experts working on small projects should pick a language better suited to their needs; Java will seem to them to be balky and annoying.
And as an aside: non-experts should stick to small projects. I think the huge danger with scripting languages (in which category I'd include things like pre-dot-net VB) is that although they are great getting non-programmers into doing a little programming, they let people get away with a lot of stuff that is dangerous on larger scales.
It's as if a guy who successfully changed a lightswitch in his house grabbed his trusty screwdriver and tried to tackle wiring a 500-rack server facility. He might get some stuff working, but it would be flaky, dangerous, and impossible to maintain. Just like so many code bases I've seen put together by "not very technical" programmers.
most programmers I work with need to have discipline imposed on them
Quick tip from one who has tried: imposing discipline on programmers doesn't work in the long run. It doesn't scale; as soon as you stop doing the imposing, they stop doing the discipline. Instead, structure your environment such that they are faced with the pain of their screwups promptly and frequently.
For example, if you give a programmer a particular area of the code that is their own domain and that only they work on, then they have months in which to repeatedly screw up without apparent consequence. Worse, it's so much work to clean up the mess that they're generally allowed to get away with it.
But if you do code reviews, you can reduce that time to a week or two. Add collective code ownership and short iterations and you can get it to days. Add pair programming and you can shorten the feedback loop to minutes.
You should especially favor techniques where peers are the ones doing the bitching, rather than management, and where their complaints are about practical things. Consider how you'd feel hearing a manager say, "You have violated the coding standard that a consultant told us we should follow. Go back and clean it up." Now consider how you'd react to a guy on your team saying, "Dude, I'm trying to extend that code you wrote yesterday and I can't make heads or tails of it. Could you help me clean it up?"
readability has nothing to do with case sensitivity. Code is kept readable by programmers that use sane variable names and, the occasional uppercase letter.
Good start, but take it a little farther.
If you add case sensitivity, then the programmer who designed an object can be sure that people using his object will follow his conventions for capitalization.
This is good in two ways: It makes it harder for somebody sloppy to get away with being sloppy. Also, it gives people who design objects an incentive to be a little more thoughtful; if they screw up on the variable names, they will get unhappy feedback from the users of those objects.
But at least here, in the courts, you can buy a good lawyer (White Anglo-Saxon if need be) no matter which race you are.
Have you ever actually gone to court? For middle-class Americans, even a moderate court battle can be a devastating financial blow. For an immigrant, visitor, or somebody who's just poor, the costs can make good representation impossible.
There are many bleeding hearts out there who will fight for your cause no matter how evil or good you may actually be, as long as you have a good story about being oppressed.
That may be the case in Canada. In the US, there are certainly a number of lawyers that do fantastic pro bono work, but it's not a large number. The public defender system in many areas is woefully underfunded, and that doesn't cover civil cases at all.
Some wags claim that in the US, you get all the justice you can afford. It's not that bad, but it's certainly far from perfect.
You really have to bite your tongue, be polite, keep your opinions to yourself, and be a gracious guest. Saudi justice is not american justice (in court, if it's a muslim's word against a christian's word, the christian can lose automatically) You're NOT a citizen there, and if you forget that detail, you can get yourself in serious trouble.
I don't want to deny the seriousness of your comment at all, and I think overall America is much better than average about how we treat foreigners. But I have a number of Sikh and Muslim friends, and they have similar concerns about the US, even the ones who are citizens, even the ones who grew up here.
They feel the threat not just from ignorant yutzes, but also from the government. Just last night a dear Indian-American friend who grew up in the Detroit area was telling me about her Sikh aunt and uncle's recent visit. Pulled aside for questioning, presumably because of his turban, the uncle did his best to answer their questions in English, a lanugage he's not so familiar with. Long story short, they decided he was being sneaky rather than puzzled and confiscated his passport. A two week visit turned into two months of lawsuit to get his passport back.
Again, I say this not to undermine your point about Saudi Arabia, but just to remind everybody else that it's easy to forget that although we may feel safe in our country and generally trust in the government to behave responsibly, it's easy for foreigners to have a pretty different view of things.
The system doesn't work against paper mills because the output of a paper mill is new content, that's why it is a mill.
That's not very plausible to me. There are certainly sites that sell that sell pre-existing term papers, so this will catch those.
You're right that there are places that offer custom-written ones, but a) you have no real way of knowing that they aren't reusing passages, b) they're much more expensive than pulling them from a database, and c) it's hard for a writer to write basically the same paper over and over without accidentally repeating themselves. An anti-plagiarism database won't stop this completely, but it will make it harder.
You've missed my point entirely. RDBMSes aren't just about storage; they're also about retrieval and processing. Many people don't seem to get that you can build applications without using an RDBMS.
word processors store data in flat files, if you need a whole class on flat files, you need help
Yes, they store it that way. But do they make changes to documents via SQL queries? No.
Also, there's a big difference between dumping some stuff out to disk and a good file format, especially one that needs to be upgradable and interchangable over the span of many years. Having reverse-engineered a number of file formats, I'd say a lot of programmers apparently need a class in file format design.
Networked Quake doesn't even store data on any scale, other than log files.
Except, of course, for megabytes of level data, used mostly on the client. But my point is that Quake, and especially networked Quake, does a whole lot of intense processing of data in a cooperative fashion without a line of SQL. Why? Because it's too slow and doesn't manage the data in the ways that you need.
And I think Google uses an RDBMS at the back end to handle some of the indices. I could be wrong on that one though
Unless they've made radical adjustments, they use no RDBMS in their search. I've heard they use 'em for billing and reporting on the AdWords stuff, but as far as I know, the live stuff gets nowhere near an RDBMS. As it shouldn't.
Why are you taking three semesters of 3 different databases? Have one course: Relational Databases, and take a week to explain the difference between the three. You aren't trying to get someone their certification before graduation.
Heck, why not take out the word "relational" and cover the broader topic?
I'm so tired of hiring people who think there is no possible way to store data besides a relational database. I can't count the number of people I've had to grab by the ear and drag around the office saying, "Look! A word processor! Look! Networked Quake! Look! A giant LDAP directory! Look! Google! None of these things use relational databases but they somehow still haven't fallen over and died. How is this possible?"
Ok! Sorry. My rant for the week is over. I just couldn't take it anymore.
I don't like the class on basic HTML--if you can't pick that up on your own, you're in the wrong major. In fact, I was flat out told that by a professor in one of my first CIS classes.
It would depend on the purpose of the class. In a CS curriculum, I'd agree; a person who can't puzzle out basic HTML should probably look elsewhere.
But in a vocational education program, HTML's not a bad thing to learn. I've been doing adequate HTML since before Netscape, but when I need HTML done right, I always bring in an expert who understands making things that look pretty but that will degrade well on older browsers and weird devices like the new generation of wireless handhelds.
IPv6 doesn't solve the problem of how to reach private addresses, it merely provides tons more public ones to eliminate the need for private ones. Except the lack of public addresses isn't the only reason for the modern use of NAT anymore.
Is there another reason besides security? If so, that's not a big reason; you can still have NAT-style security (dynamic approval of outgoing connections but static configuration of allowed incoming connnections) without a lot of work.
with home-type setups you're liable to get endless clashes
The typical solution here is to have the VPNs set up to do some remapping. Technically, this strikes me as ugly, but a lot less ugly than redoing IP to accomodate bang-path routing. And people have been doing it on a large scale for at least ten years, so the problems are pretty well understood.
But if everybody needs to talk to everybody, the real solution is to give everybody a routable address. Anything other than that is a hack, and hacks grow increasingly expensive over time to maintain, as you have to code for the base layer, the additional hack layers, and all of the weirdnesses that the hacks result in. One fine example is this SpeakFreely package; the thing that pushed him over the edge is trying to deal with the hack of NAT.
Of course they'll incur a significant cost -- more hosts per customer means more traffic per customer.
I'm not sure that's an "of course". Although I'm TVless, my family back home has a number of TVs. I don't think much more television-watching gets done when you add multiple TVs to a house, and I think home computers are already going that way. The first wave of internet appliances failed, but with 802.11 becoming so common, the $300 small terminal in the kitchen becomes more reasonable. Ditto for the internet-enabled appliances.
Some ISPs already forbid attaching more than one machine. IPv6 will not cause them to become more agreeable.
Yep. Some do that to squeeze money out. Some do that because it may really correlate with their costs. (It would for business lines, for example.) The first approach will be less tenable if we end up with good broadband competition.
The second, using IP addresses as a cheap correlate for bandwidth usage, may make sense for some. But if bandwidth is the issue, it's better just to charge for that; it mainly takes better accounting and billing systems. An active file trader probably uses 100 times the bandwidth of somebody checking email, so just number of IPs probably doesn't correlate so well in the home market.
If you're doing your job right, you're probably doing your best to make sure it is blocked at the firewall. It's a workplace, not the users personal playground. Not every application should be allowed to run inside your network. It's the companies' network, not the user's.
That depends on what kind of company you're at. If workers are treated as machiery, that's probably true. For example, running a big call center, you might be able to argue that things should be locked down.
But there are other kinds of companies out there. Any software development shop, for example, that locks things down excessively will lose good developers at an astonishing rate. In fact, pretty much any company where you have people needing to do creative work, there's benefit to locking things down as little as possible.
If there's a legitmate reason to allow an application access to the network, then you can configure the network to allow it. Otherwise, the network's firewall should be blocking it by default. That's what a good netadmin does. Duh.
If a network is of the size and resources to afford a good netadmin who isn't overworked, then that makes sense. I'd guess that covers, say, 5% of the computers out there. For the bulk of the population, we need better solutions.
Well, you use a third-party server to find out the IP address and local port of the other side - and then you just start sending UDP packages. The first few will be lost, but then it should work.
No, it can't work if both are NATed. Here's why:
Start with the case of one NATed box (call it A) and one with a real IP address (B). They meet on a real server, and B gives its address and port. Call it 12345. So A sends B a packet from port 10000 to B's port 12345. A's NAT box notices this, remaps 10000 to, say 20000, and remembers that packets from B on port 20000 are for A's port 10000. Then it sends it on, and all is merry.
So now imagine that B gets stuffed behind a NAT box. A and B meet again and try to swap address and port numbers. The server can figure out the IP addresses of both NAT boxes, so A could send out a packet to B's NAT box. But what port does A send it to? And how will B's NAT box know that the packet goes to B?
As far as I can see, there's no way for this to work without B being able to tell the NAT box to forward a particular port.
What we really need is a generic method of sub-addressing machines.
We already have at least two.
One is IPv6. The other is VPNs. Instead of coming up with a completely new mechanism and getting it in the routers, we should go with one that we've been working on for a while and just get it deployed.