Not only is faster and cheaper preferable to correct, simpler is preferable to correct. If I have two explanations and one is complex but correct and the other is simple but incorrect, most people will chose the latter. I will stop typing here in hopes that people will consider my explanation insightful.
While I understand what you are saying, I'm not sure that I agree 100%. Let's say I take whole bunch of data in an MP3 and reproduce it with my own bits and bytes, at my own expense, following the pattern in the original. Then I offer it to other people for less money than the original. Is this not the same as taking a drug, reproducing it, at my own expense, following the pattern in the original? If I then offer it to other people for less money than the original, isn't it at least somewhat similar?
I think, conceptually, the two things *are* similar, but of course they are *very* different in law. Also, MP3s are usually offered at no-cost, while the drugs are being made to have a profit. Does this matter? Personally, I can't see any reason why it should, but maybe that just me.
The important thing for me is that the government is getting involved in a civil matter. They are interfering so as to limit damages to one party without a lawsuit ever having been heard. And it is possible that after the action by the government is taken, a lawsuit will never be heard. In other words the government is acting by fiat on a civil law matter without having due process. Whether it is for counterfeit drugs or pirated MP3s, this is very, very worrisome.
And less risky.. Who now wants to be labeled as an 'anti American dissident' because they complained?
I like American bashing as much as the next guy, but being a self-proclaimed American dissident hasn't appeared to hurt Noam Chomsky that much. At least not in comparison to dissidents in other countries. No, for all its faults this seems to be one thing the US does reasonably well (unless someone would like to educate me with another example???)
As a non-American I often listen on in bewilderment when I hear American's talk about their left-wing and right-wing parties... From where I stand they are both pretty far right. I can understand that American's don't like left-wing politics, but it's absolutely insane to think that the only thing left of the Democrats is communism. To be brutally honest, apart from some minor differences between the Republicans and Democrats, I can't really see a lot separating their policies. There *is* a huge difference between the social backgrounds of the people that identify with the two parties, so I often wonder if that's why people think they are different...
What's even better is that your pool of programmers isn't fixed. if the software is very popular, your available pool of talented programmers is very large. Like you say, even a small project can have hundreds programmers interested in it. When a problem comes up your chance of finding someone able to fix the problem is high. Not everyone will participate. But you are likely to find someone with the skills that are needed. In something like the kernel, how many times have we seen people fix bugs in different ways with Linus choosing the one he likes? This could never happen with other development models.
This is why I often say that users of free software pay for their use by making it popular. Only when the software is popular will these other programmers show up. Proper marketing is probably the biggest problem that most free software projects have (mine included -- I think I may be the only user;-) Probably it would help to release current versions every once in a while...)
The word you are searching for is "consortium". And yes, open source development is often done as a consortium, albeit one in which anyone who is interested may join. It's not the only possible business model, but it's good for getting people who have trouble thinking out of the box to understand open source.
The problem in the USA today isn't a lack of quality teaching and quality schools or even a lack of quality curriculum. It is an attitude that doing well in school is for social outcast nerds and to be cool you have to ignore school and learning in general.
It most certainly is the teaching quality. I work in education, and while there are quite a few good and excellent teachers there, there are plenty of teachers that shouldn't be. It is like dodging raindrops.
I also work in education after having previously been a programmer. The problem is that teaching is really, really hard. And it's really, really easy to convince yourself, as a teacher, that the lack of progress you are making is due to the shortfalls of your students. When I worked as a programmer, I would often run into people who shouldn't be programming. So I don't think that lack of ability to do your job is unique to teaching.
But what I found in programming was that usually start ups had a higher percentage of programmers who could code. This is because start ups can't afford any dead wood. If you hire 4 programmers and 2 of them are complete shit, you run out of money very quickly -- natural selection. Not only that, but the pressures in the start up cause the good programmers to complain about the bad programmers. You *have* to deliver in May and this idiot is in your way. Problems come to the surface very quickly. But in large organizations, it is very easy to be polite and to not make waves. Even if you know your colleague is shit, it's not like you are going to say anything. Seriously, who tries to get their co-workers fired?
Schools don't close when the teachers are bad. Schools are big. Schools are stable places of employment. Schools are full of politics that have nothing to do with teaching. If you wanted to make sure that your teachers are all good, a school is probably not a good place to be. It is precisely the kind of place that attracts people who want a stable career where they can hide away with out too much scrutiny. Personally, I can't see how to make progressive changes that would work in the general case.
No offence but different people learn differently. Especially if we're talking about something like comp sci, it's not like it requires a huge amount of insight to understand undergraduate material. Go to a book store and buy the textbooks for the courses. If you want feedback on programming, participate in open source projects - you will get better feedback there than virtually any college I know of (although it might be painful at times...)
The cool thing about the internet is that it's easy to talk to people you don't know. And, especially in comp sci, people doing interesting work are often very generous with their time. If you read somebody's paper and send an email to them asking an intelligent question, you will almost certainly get a response. Learning is up to you, not your teacher, and so there is no need to feel restricted by small things like what college you go to.
The diploma is said to be necessary to show a level of commitment to study, and to show that you have been introduced to all the basics. But for those people who are already self motivated and have an eager mind, college can be a bit of a grind.
There are many things that lead to a successful company. Development of a product is one of them. There are a lot of other issues as well.
But if we concentrate on development of a product, the initial idea is not the important part. It's the million of little details that make the idea come together. When the parent said that "it's the implementation that matters", I think that's what they mean. It's not just coding part of implementation, it's the analysis of the idea and finding out exactly how it can work that's important. Often when people say that have a great idea, but just need a programmer, I think that they haven't actually had an idea. They have the beginning of an idea and they need someone to have the next 99% of the idea for them.
Then of course even when it is all fleshed out and implemented you have other challenges. Business is tough.
I don't want to be critical because generally I agree with you, but I wonder if these numbers are correct for the practical case.
For instance, batteries are not 100% efficient. A Lithion ion battery is 80-90% efficient, so only 80-90% of the energy you put into the batter can be used. It also has a self discharge rate of 8-15% per month depending on temperature. So if you leave it sitting around, without driving it, it loses energy. Electricity can't be delivered 100% efficiently either (although this is also true of gasoline).
I don't have time to run all the numbers, but it seems to me that your figures could be off by as much as 20%. It is still a very valid point that electricity is competitive with gasoline for CO2 emissions, but I think the specific numbers are more difficult to calculate than you imply.
If they are actually losing money on these cars, I can't quite figure out their logic. I assume that they expect that their actions will lead to lower costs from their suppliers. Then eventually the costs will be low enough to start making money. But if this is the case then they are paying for the entire industry. Their competitors can come in late to the game and benefit from GM's investment without having to make a similar investment themselves. So in other words, the only advantage GM would have would be the recognition of being "first to the market", but they will be saddled with both the cost of doing so and the inevitable bugs that crop up from being first. It's a bit like Apple's Newton. They paid for all the innovation, while Palm made all the profit.
Wait, did I just make a computer analogy in a car thread?
This is somewhat off topic, but I was considering purposely shortening the copyright term for the software that I write. At the moment, all of the software I write is GPL. My plan is to release major revisions of my software as public domain after they have been around for 5 years. I've thought about it a lot and I can't see any major downside for me. If you are going to extend my project, you are unlikely to want 5 year old code. But if I sit on my ass for 5 years and don't extend it myself, then the current code goes public domain. It's an incentive for me to keep writing. The major problem for me is that I think I have to keep track of my code. I'm not sure if I can make a stipulation, "After X date, you may use consider this code as public domain, or use Y permissive license if your country doesn't have the concept of public domain." ahead of time.
You only have to see my previous posts to see that I'm as big a free software advocate as you can get. But even I understand that *users* should use whatever tools that work for them. Free software is essentially a *consumer* movement. It is meant to protect the user, not the producer. All of the rhetoric about the immorality of software that isn't free speaks about producers taking freedoms away from the user. If a user values the functionality in a piece of software more than the freedoms they could enjoy, that is unfortunate, but not immoral. There is no way that *using* Windows is shameful. Forcing others to use it may very well be another story...;-)
From a free software advocacy position, we need to understand why people like you choose to go through the hassle of maintaining both a free and non-free platform in parallel. Clearly you see some value in your Debian setup. On the Windows side it seems like the "killer apps" (Photoshop, etc) keep you there. I'm willing to bet that the same is not true for the Debian side. What exists on Debian that doesn't exist on Windows? Rather, whether you realize it or not, I suspect that the culture of freedom and/or the utility of open source development practices keep you there.
Where free software advocates fail is that we aren't able to communicate the benefits of free software to the average person. For instance, when you buy Photoshop part of the money you spend goes into improving the software. When the next version comes out, you buy it, realize the improvements and the cycle starts again. But in free software it is your very use of the software that leads to its improvement. More users bring corporate players to consider using the software and extending it. More eyes finds bugs, poor work flow, and feature opportunities. The more you exercise your freedoms, the better the software will get.
This is why it is unfortunate that you choose to use Photoshop on Windows. If you, and other people, could get involved in the Gimp it would benefit everyone. Instead of paying for every release of Photoshop (or pirating it, and thereby only being a leech in the process), your efforts to learn the Gimp, write bugs, distribute to your friends, etc become your payment. And eventually it will reap the rewards that you already enjoy with other software on your Debian system.
As with most crimes in progress, the law allows the police to take action to stop the crime and seize the evidence. The disposition of the evidence and means of committing the crime will be dealt with as part of whatever trial is coming.
In this case, it looks like a ICE took down a bunch of sellers of counterfeit goods and may have overreached on the torrent site. That said, we'll all soon learn what the relationship of torrent-finder.com is to the rest of the seized domains.
I think this is the main point. Copyright infringement is not a crime (yet). A government office should not be interfering in a civil matter.
Index cards alone may not be. But each story should be accompanied by acceptance tests. I would hazard a guess that a short description of what you are building followed by a rigorous set of tests that show whether or not the functionality is acceptable would be exactly what they are looking for. If the tests are automated and you can show whether or not the production version of the software passes the acceptance tests, I think you would be much better off than a standard requirements document.
Wouldn't it be great if when a medical device kills a bunch of patients, somebody could go have a look at the acceptance tests, decide if they were rigorous enough and if not remove the license of programmers/PGMs to build medical software (wouldn't it be great if there *was* such a license)?
Scalability and process control are two different subjects, but I'll try to answer what I think your question is.
I'm mostly familiar with XP. There are a lot of other so-called "Agile" methodologies, but XP has the most well defined set of development practices. Other methodologies don't specify what you should be doing, so a lot is left up to the individuals (which can be good or bad). But just because it is "Agile" doesn't mean it isn't well controlled. For example, doing full XP you should be writing acceptance tests (both manual and automated) for all functionality (though I have rarely seen anyone actually do this). The story cards along with the acceptance tests form the requirements. The "Customer" (I call it the customer proxy since they are rarely the actual customer) should be reviewing the application with respect to the acceptance tests at the end of every iteration. Stories are marked off as they are completed. Regardless of what you use to write the story on (I often used a wiki), handing the card in, or setting the status to DONE means it is finished. The iteration plan (or backlog in Scrum) gives your commitment for the iteration., etc, etc. From an ISO/CMMI perspective I can't think of a single thing that is missing. Of course many people view "Agile" as a synonym for "Ad Hoc" and proceed accordingly. This is unfortunate.
One of the knocks on XP is that it isn't scalable. This is both true and false. On the one hand, if you are asking about scalability I might be tempted to say that you have too many programmers and would be better off with less. The problem isn't in the amount of code you can generate. The problem is that it is very, very difficult to specify a lot of requirements at once and have it not turn into a pile of shit. Your bottleneck is not in your programmers, it is in your customer proxy. Traditionally we ignore true specification (or user centered design) and let the programmers make decisions. If the decisions are questioned at all it is by the QA people (which results in a lot of pointless back and forth arguing). Nobody has the big picture because the millions of tiny decisions made everyday are impossible to absorb by a single person. The cure for this is time. Let the program take longer in development in order to understand what it is you truly need. Have someone play with the system and understand the implications of the changes before making the next step.
So, scalability is not really more of a problem for XP than it is for other methods. It's just that the problem is more obvious. If you really need more programmers working, then an issue tracking system is a decent replacement for index cards (although most issue tracking systems have difficulty assigning ordinal priority). Your requirements will still suck, though, just like other methods. If you can partition your problem and find a group of application designers (i.e., subject matter experts who can tell you what your application should be doing) that can communicate with each other well, then you can easily scale XP. I think you can probably keep one of those designers (customer proxy) busy with 8 programmers (or 6 good programmers). Depending on the problem I suppose that would allow you to scale to 50 programmers or so. More than that will probably raise the risk unacceptably no matter what method you choose. But 50 programmers should be able to maintain a rate of about 30K lines of production code per week (in fully TDD code). I have to say that I can't imagine wanting to go faster than that... Finding 50 programmers who can do XP well might be rather challenging, though.
Yes, you are correct. In fact there are a whole raft of tools that you probably would like to have once you know what you need. I find it interesting that the OP is asking/. about advice for tools having already built all the tools that they need. This tells me that they are likely trying to find a tool to fix process problems. That is backwards. You should fix your process and then notice that you are missing a tool (or a feature in one of your tools). Then it's pretty obvious what you need to get. I suppose it is remotely possible that one of those all-singing, all-dancing process improvement suites implement everything they way you are already doing it, but it seems unlikely. And there is no possible way that anyone on/. would know which one to recommend.
People, in general, are a cost and not necessarily an asset. Making sure all your activities are returning value is an important part of running a business. More warm bodies looking busy doesn't make you more efficient, that's for sure. And in many large organizations I've worked in the "Process People" have often been "warm bodies looking busy".
However, there is a difference between a bad idea and a bad implementation. Having been involved in CMMI/ISO audits I have seen what kind of joke it can be. Those warm bodies are doing exactly what you suggest -- the minimum to pass their audit (which is barely anything at all, if I am honest -- mostly running around hiding evidence that the process is not being followed). But ISO and CMMI is not to blame for this injustice. The problem is those warm bodies and attitudes like yours.
Most "Process People" sit around fantasizing about what process everyone should follow. Then they write it down and tell everyone to follow it. Never mind that they have never actually seen what people are actually doing now. This is precisely the opposite of what is recommended by these meta-processes. How many times have I heard, "Well, normally it takes 5 years to get to CMMI level 4, but I think we can do it in 2 months if everyone cooperates"? Having said that, they have demonstrated their ignorance for any point at all in CMMI.
Document what everyone is doing. Not what they say they are doing; not what they want to be doing; not what you wish they were doing; what they are actually doing. That's your process. Compliance? Dead easy. They are already doing it. Documentation? It's not exactly rocket science. Make sure people put version numbers on documents. Or better yet, put everything in an SCM and say that all paper versions are merely drafts. Done.
You are right that you should do the very minimum that you can do with ISO and CMMI. Not because it is a waste of time, but because sitting around concocting elaborate plans for a cool process doesn't align with reality. Neither ISO nor CMMI tells you what you should be doing in your process. It tells you what you should be observing and thinking about. For level 2 you can write down pretty much anything you want for each section.
But the point is, once you have everything written down you can look at it and say, "Hmmm... we have some inefficiencies here. Bob, if you were to do X before Y it would help out Sally. Would that be OK?" Also, having written everything down it makes it easy for new people to come in and get an idea of the existing culture without having to discover it through trial and error. It allows them to quickly identify areas that they may want to change -- "You know guys, in my last company we did X. What do you think".
As you may have guessed, I have had the misfortune of being one of those "Process Guys". I prefer coding, but sometimes you have to do what you have to do. In my time as a process guy I tried to spend 80% of my time documenting what people were doing, identifying things that had changed over time and asking why the changes were made. I spent 10% measuring various things and making pretty graphs for upper management. I spent 10% of my time giving advice for things that teams might want to try to improve their efficiency. I spent 0% of my time enforcing compliance. If people didn't follow the process, then the process was wrong. I think that the fact that my management preferred me to do this work than write code (despite my protests) says something about the value I returned to the company.
Finally, to answer the question of the OP -- Don't buy a tool. A tool models someone else's vision of reality -- not what your people are actually doing. If you buy a tool off the shelf then you will spend most of your time chasing compliance rather than improving workflow. It really will be a waste of time and money.
Oh, and I dare not start asking about the visa status of some of these workers. It's a sensitive subject. Many will just get up and walk away.
If you are asking the foreign workers themselves, what you may not realize is that they are often threatened a lot about their visa status -- by HR or even their own management. In many of the big companies where I worked I found out that management/HR would threaten to fire foreign workers if they didn't work insane hours, or do exactly what they were told. Sure it's improper dismissal, but it's hard to argue from another continent. Or worse, their salary is often the lifeblood of their entire extended family. Even a short intermission in the money could lead to serious hardship. Their visa status is a very sore point because it is how they are able to be treated so badly by others.
Well, I was going to call bullshit on this, but I checked and it seems Indian Software developers make less than $7K US per year. I'm pretty frugal and even I would have a hard time living on less than $10K in the west.
It is interesting, though. I've been through enough outsourcing disasters to know that even at 10x the cost, it's worth it to have your management and developers on the same continent. As someone else said, surely someone will think of doing something like doubling the salary, skimming off all the best Indian (or whatever) programmers and kicking everyone else's butt. I guess the saving grace is that there is hardly anyone that knows how to hire programmers and get something other than completely random skill levels...
Your value may grow, but money is not a measure of value (it's an odd concept, I know). It's really lubrication that allows you to realize value. So in your example, with the extra money, the farmer can realize value and we get growth. The money supply *does* increase, but not because we increased value. It increases because we increased debt. Even if the farmer doesn't increase his efficiency, we will still increase the money supply because money is created when we have debt. Someone will have more money -- whether or not it is the farmer is a moot point.
The real question comes when you wonder, "where does the money come from to pay the farmer his extra 20% profit". Well, that also comes from debt. And that money also has to be repaid with interest. So we have bank who makes 2 loans. Loan f goes to farmer F and loan b goes to buyer B. Farmer F sells his produce to buyer B and gives him the money b. The money b is equal to the farmer's load f plus the interest on f. Farmer F uses the money to pay off his loan. But B now has food and a debt for b (which is bigger than f, remember). What can he do? Well he can sell some of the food at a profit. But the money from that has to come from the bank. So the bank make a loan to C for c amount. C buys the food and B repays his loan with c. Remember c has to include the interest for b, so it it bigger than b.
Since all money poofs into existence from loans, the debt gets bigger and bigger. There isn't enough money in the money supply at any one time to satisfy the debt. It just keeps getting bigger and bigger until people default on their loans and the whole thing comes crashing down. It is a classical Ponzi scheme.
Except, earlier in this discussion someone pointed out that there is an alternative. The banks make profit, which is the interest that they made on the loans. If they spend their money in on consumable items (like food, fuel, etc), they this money will make it back into the economy and can offset the problem. However, banks aren't really renown for spending their profits on consumables. They usually use those profits to invest in more profit making enterprises.
The main point is that unless we have continuous growth, we can potentially have serious problems. This is why government panic so much when their population decreases, even when they are overpopulated.
I often wonder whether the universe simply uses lazy evaluation. In other words, the position, momentum etc are not evaluated until a particle actually interacts with another particle. From the perspective of being in the universe we can't observe the unevaluated state because any attempt at observation causes particles to interact, creating the evaluated state.
If that is true, I start to wonder if there is "local evaluation". So if two particles interact, they are evaluated in their own reference frame, but from the perspective of other particles not involved in the interaction, are they still unevaluated?
Then I start to think, if that is true maybe everything runs in parallel. So every particle is evaluated in its own reference frame, but unevaluated in other reference frames unless the two reference frames interact. Then whether or not reference frames interact should be computable (outside the universe). In other words, even though an electron has a non-zero probability to exist anywhere in the universe, if all reference frames are evaluated from their own perspective, the chance of interaction with another reference frame could be zero. Of course, being part of the universe, we can't observe this because those other reference frames are unevaluated from our perspective.
But then I think... I don't have a fucking clue how quantum physics works and this is likely very naive. But it gives me a way to wrap my head around the concept...
I like games, but I fall into a category of people that couldn't really be called a gamer.
I don't have 40-60 hours of free time. I mean, seriously. How long is this game supposed to last? Should I really spend 1-2 hours a day for the next month of my life playing a game? I could get some exercise, or learn a language, or clean my house, or get a girlfriend.
I'm not saying this to make fun of people who choose to spend that time playing games, but it's a huge time commitment for a normal person. And you don't really get much payback IRL. I could maybe do something like 30-40 minutes 2 or 3 times a week, but then this game is going to take me more than a year. I'm going to get seriously tired of it. Also, I'll never build up the skills necessary to actually complete the game.
For me the grinding isn't just annoying. I deeply resent it. I might actually have some hope of completing the game -- of enjoying the story line, if it weren't for all the mindless grind. Even worse (especially in Japanese RPGs) is the meaningless dialog. You can tell somebody has added cut scenes and dialog just to pad out the length.
Couldn't we have a short mode, in addition to a difficulty mode in these games. Cut out all the mindless stuff, multiply the XPs and get me through the game in 10 hours. For a guy like me 10 hours of solid entertainment is well worth the price of a game. You don't have to pad it. Or to put it more accurately, if you pad it I won't buy it because I have no hope of seeing the whole thing (who would pay for a movie they will only watch 25% of...)
I really wish I remember who said this, but I once heard an interview and the person was asked, "Did sanctions on South Africa help end apartheid?"
The answer was that none of the economic sanctions did any bit of good at all. There are ways around those kinds of issues. But the sanctions on sport was felt keenly and deeply in South Africa. More than anything else, this was the one thing that outside countries did to help end Apartheid. Whether or not it is true I don't know, but I thought it was very interesting observation.
Obviously I can't know exactly what they are thinking, but here's my guess. To us the business case is obvious: if you provide a service which is convenient and cheap enough, most people will opt for convenience and pay for the product. I mean you *could* have a garden and grow your own food, and you could prepare that food yourself. It isn't *that* much work and the result is very rewarding. But most people would rather get in their car and drive to Mac Donald's. Why? Because it is convenient. People are willing to pay for that convenience as long as the cost is reasonable.
But the media execs, even if they realize this, want the freedom to charge whatever they want for things. What is a movie *worth*? Well, since you don't need it at all it doesn't have any intrinsic value. It's only value comes from creating a desire to want to see it and limiting the availability to see it. The value of the movie becomes what the customer is willing to pay, not what it's intrinsic worth is.
The media industry has also realized that high prices serve their interest even if they don't directly make high profits as a result. People will want to see movies more if there are huge amounts of special effects, high priced actors, etc, etc. If the average movie costs $1 million to make, you will have a lot of competition from other companies. But if it costs $100 million, there aren't many groups with the capital to break in and compete with you. So if you can raise prices and spend all your money on production, advertising, etc, etc you still end up ahead. This is especially true if you are performing all those services and skim a profit at each step (i.e., the movie makes no profit but every service performed makes a profit and since you own those services you make a profit).
So in other words, they need to keep supply low to keep prices high to maintain their monopoly position in the industry. I believe this is their real interest in DRM. The "convenience" price point is too low to accomplish this.
Slashdot Mirror
Not only is faster and cheaper preferable to correct, simpler is preferable to correct. If I have two explanations and one is complex but correct and the other is simple but incorrect, most people will chose the latter. I will stop typing here in hopes that people will consider my explanation insightful.
While I understand what you are saying, I'm not sure that I agree 100%. Let's say I take whole bunch of data in an MP3 and reproduce it with my own bits and bytes, at my own expense, following the pattern in the original. Then I offer it to other people for less money than the original. Is this not the same as taking a drug, reproducing it, at my own expense, following the pattern in the original? If I then offer it to other people for less money than the original, isn't it at least somewhat similar?
I think, conceptually, the two things *are* similar, but of course they are *very* different in law. Also, MP3s are usually offered at no-cost, while the drugs are being made to have a profit. Does this matter? Personally, I can't see any reason why it should, but maybe that just me.
The important thing for me is that the government is getting involved in a civil matter. They are interfering so as to limit damages to one party without a lawsuit ever having been heard. And it is possible that after the action by the government is taken, a lawsuit will never be heard. In other words the government is acting by fiat on a civil law matter without having due process. Whether it is for counterfeit drugs or pirated MP3s, this is very, very worrisome.
And less risky.. Who now wants to be labeled as an 'anti American dissident' because they complained?
I like American bashing as much as the next guy, but being a self-proclaimed American dissident hasn't appeared to hurt Noam Chomsky that much. At least not in comparison to dissidents in other countries. No, for all its faults this seems to be one thing the US does reasonably well (unless someone would like to educate me with another example???)
As a non-American I often listen on in bewilderment when I hear American's talk about their left-wing and right-wing parties... From where I stand they are both pretty far right. I can understand that American's don't like left-wing politics, but it's absolutely insane to think that the only thing left of the Democrats is communism. To be brutally honest, apart from some minor differences between the Republicans and Democrats, I can't really see a lot separating their policies. There *is* a huge difference between the social backgrounds of the people that identify with the two parties, so I often wonder if that's why people think they are different...
What's even better is that your pool of programmers isn't fixed. if the software is very popular, your available pool of talented programmers is very large. Like you say, even a small project can have hundreds programmers interested in it. When a problem comes up your chance of finding someone able to fix the problem is high. Not everyone will participate. But you are likely to find someone with the skills that are needed. In something like the kernel, how many times have we seen people fix bugs in different ways with Linus choosing the one he likes? This could never happen with other development models.
This is why I often say that users of free software pay for their use by making it popular. Only when the software is popular will these other programmers show up. Proper marketing is probably the biggest problem that most free software projects have (mine included -- I think I may be the only user ;-) Probably it would help to release current versions every once in a while...)
The word you are searching for is "consortium". And yes, open source development is often done as a consortium, albeit one in which anyone who is interested may join. It's not the only possible business model, but it's good for getting people who have trouble thinking out of the box to understand open source.
It most certainly is the teaching quality. I work in education, and while there are quite a few good and excellent teachers there, there are plenty of teachers that shouldn't be. It is like dodging raindrops.
I also work in education after having previously been a programmer. The problem is that teaching is really, really hard. And it's really, really easy to convince yourself, as a teacher, that the lack of progress you are making is due to the shortfalls of your students. When I worked as a programmer, I would often run into people who shouldn't be programming. So I don't think that lack of ability to do your job is unique to teaching.
But what I found in programming was that usually start ups had a higher percentage of programmers who could code. This is because start ups can't afford any dead wood. If you hire 4 programmers and 2 of them are complete shit, you run out of money very quickly -- natural selection. Not only that, but the pressures in the start up cause the good programmers to complain about the bad programmers. You *have* to deliver in May and this idiot is in your way. Problems come to the surface very quickly. But in large organizations, it is very easy to be polite and to not make waves. Even if you know your colleague is shit, it's not like you are going to say anything. Seriously, who tries to get their co-workers fired?
Schools don't close when the teachers are bad. Schools are big. Schools are stable places of employment. Schools are full of politics that have nothing to do with teaching. If you wanted to make sure that your teachers are all good, a school is probably not a good place to be. It is precisely the kind of place that attracts people who want a stable career where they can hide away with out too much scrutiny. Personally, I can't see how to make progressive changes that would work in the general case.
No offence but different people learn differently. Especially if we're talking about something like comp sci, it's not like it requires a huge amount of insight to understand undergraduate material. Go to a book store and buy the textbooks for the courses. If you want feedback on programming, participate in open source projects - you will get better feedback there than virtually any college I know of (although it might be painful at times...)
The cool thing about the internet is that it's easy to talk to people you don't know. And, especially in comp sci, people doing interesting work are often very generous with their time. If you read somebody's paper and send an email to them asking an intelligent question, you will almost certainly get a response. Learning is up to you, not your teacher, and so there is no need to feel restricted by small things like what college you go to.
The diploma is said to be necessary to show a level of commitment to study, and to show that you have been introduced to all the basics. But for those people who are already self motivated and have an eager mind, college can be a bit of a grind.
There are many things that lead to a successful company. Development of a product is one of them. There are a lot of other issues as well.
But if we concentrate on development of a product, the initial idea is not the important part. It's the million of little details that make the idea come together. When the parent said that "it's the implementation that matters", I think that's what they mean. It's not just coding part of implementation, it's the analysis of the idea and finding out exactly how it can work that's important. Often when people say that have a great idea, but just need a programmer, I think that they haven't actually had an idea. They have the beginning of an idea and they need someone to have the next 99% of the idea for them.
Then of course even when it is all fleshed out and implemented you have other challenges. Business is tough.
I don't want to be critical because generally I agree with you, but I wonder if these numbers are correct for the practical case.
For instance, batteries are not 100% efficient. A Lithion ion battery is 80-90% efficient, so only 80-90% of the energy you put into the batter can be used. It also has a self discharge rate of 8-15% per month depending on temperature. So if you leave it sitting around, without driving it, it loses energy. Electricity can't be delivered 100% efficiently either (although this is also true of gasoline).
I don't have time to run all the numbers, but it seems to me that your figures could be off by as much as 20%. It is still a very valid point that electricity is competitive with gasoline for CO2 emissions, but I think the specific numbers are more difficult to calculate than you imply.
If they are actually losing money on these cars, I can't quite figure out their logic. I assume that they expect that their actions will lead to lower costs from their suppliers. Then eventually the costs will be low enough to start making money. But if this is the case then they are paying for the entire industry. Their competitors can come in late to the game and benefit from GM's investment without having to make a similar investment themselves. So in other words, the only advantage GM would have would be the recognition of being "first to the market", but they will be saddled with both the cost of doing so and the inevitable bugs that crop up from being first. It's a bit like Apple's Newton. They paid for all the innovation, while Palm made all the profit.
Wait, did I just make a computer analogy in a car thread?
This is somewhat off topic, but I was considering purposely shortening the copyright term for the software that I write. At the moment, all of the software I write is GPL. My plan is to release major revisions of my software as public domain after they have been around for 5 years. I've thought about it a lot and I can't see any major downside for me. If you are going to extend my project, you are unlikely to want 5 year old code. But if I sit on my ass for 5 years and don't extend it myself, then the current code goes public domain. It's an incentive for me to keep writing. The major problem for me is that I think I have to keep track of my code. I'm not sure if I can make a stipulation, "After X date, you may use consider this code as public domain, or use Y permissive license if your country doesn't have the concept of public domain." ahead of time.
You only have to see my previous posts to see that I'm as big a free software advocate as you can get. But even I understand that *users* should use whatever tools that work for them. Free software is essentially a *consumer* movement. It is meant to protect the user, not the producer. All of the rhetoric about the immorality of software that isn't free speaks about producers taking freedoms away from the user. If a user values the functionality in a piece of software more than the freedoms they could enjoy, that is unfortunate, but not immoral. There is no way that *using* Windows is shameful. Forcing others to use it may very well be another story... ;-)
From a free software advocacy position, we need to understand why people like you choose to go through the hassle of maintaining both a free and non-free platform in parallel. Clearly you see some value in your Debian setup. On the Windows side it seems like the "killer apps" (Photoshop, etc) keep you there. I'm willing to bet that the same is not true for the Debian side. What exists on Debian that doesn't exist on Windows? Rather, whether you realize it or not, I suspect that the culture of freedom and/or the utility of open source development practices keep you there.
Where free software advocates fail is that we aren't able to communicate the benefits of free software to the average person. For instance, when you buy Photoshop part of the money you spend goes into improving the software. When the next version comes out, you buy it, realize the improvements and the cycle starts again. But in free software it is your very use of the software that leads to its improvement. More users bring corporate players to consider using the software and extending it. More eyes finds bugs, poor work flow, and feature opportunities. The more you exercise your freedoms, the better the software will get.
This is why it is unfortunate that you choose to use Photoshop on Windows. If you, and other people, could get involved in the Gimp it would benefit everyone. Instead of paying for every release of Photoshop (or pirating it, and thereby only being a leech in the process), your efforts to learn the Gimp, write bugs, distribute to your friends, etc become your payment. And eventually it will reap the rewards that you already enjoy with other software on your Debian system.
But I agree. Not shameful; just unfortunate.
As with most crimes in progress, the law allows the police to take action to stop the crime and seize the evidence. The disposition of the evidence and means of committing the crime will be dealt with as part of whatever trial is coming.
In this case, it looks like a ICE took down a bunch of sellers of counterfeit goods and may have overreached on the torrent site. That said, we'll all soon learn what the relationship of torrent-finder.com is to the rest of the seized domains.
I think this is the main point. Copyright infringement is not a crime (yet). A government office should not be interfering in a civil matter.
Index cards alone may not be. But each story should be accompanied by acceptance tests. I would hazard a guess that a short description of what you are building followed by a rigorous set of tests that show whether or not the functionality is acceptable would be exactly what they are looking for. If the tests are automated and you can show whether or not the production version of the software passes the acceptance tests, I think you would be much better off than a standard requirements document.
Wouldn't it be great if when a medical device kills a bunch of patients, somebody could go have a look at the acceptance tests, decide if they were rigorous enough and if not remove the license of programmers/PGMs to build medical software (wouldn't it be great if there *was* such a license)?
Scalability and process control are two different subjects, but I'll try to answer what I think your question is.
I'm mostly familiar with XP. There are a lot of other so-called "Agile" methodologies, but XP has the most well defined set of development practices. Other methodologies don't specify what you should be doing, so a lot is left up to the individuals (which can be good or bad). But just because it is "Agile" doesn't mean it isn't well controlled. For example, doing full XP you should be writing acceptance tests (both manual and automated) for all functionality (though I have rarely seen anyone actually do this). The story cards along with the acceptance tests form the requirements. The "Customer" (I call it the customer proxy since they are rarely the actual customer) should be reviewing the application with respect to the acceptance tests at the end of every iteration. Stories are marked off as they are completed. Regardless of what you use to write the story on (I often used a wiki), handing the card in, or setting the status to DONE means it is finished. The iteration plan (or backlog in Scrum) gives your commitment for the iteration., etc, etc. From an ISO/CMMI perspective I can't think of a single thing that is missing. Of course many people view "Agile" as a synonym for "Ad Hoc" and proceed accordingly. This is unfortunate.
One of the knocks on XP is that it isn't scalable. This is both true and false. On the one hand, if you are asking about scalability I might be tempted to say that you have too many programmers and would be better off with less. The problem isn't in the amount of code you can generate. The problem is that it is very, very difficult to specify a lot of requirements at once and have it not turn into a pile of shit. Your bottleneck is not in your programmers, it is in your customer proxy. Traditionally we ignore true specification (or user centered design) and let the programmers make decisions. If the decisions are questioned at all it is by the QA people (which results in a lot of pointless back and forth arguing). Nobody has the big picture because the millions of tiny decisions made everyday are impossible to absorb by a single person. The cure for this is time. Let the program take longer in development in order to understand what it is you truly need. Have someone play with the system and understand the implications of the changes before making the next step.
So, scalability is not really more of a problem for XP than it is for other methods. It's just that the problem is more obvious. If you really need more programmers working, then an issue tracking system is a decent replacement for index cards (although most issue tracking systems have difficulty assigning ordinal priority). Your requirements will still suck, though, just like other methods. If you can partition your problem and find a group of application designers (i.e., subject matter experts who can tell you what your application should be doing) that can communicate with each other well, then you can easily scale XP. I think you can probably keep one of those designers (customer proxy) busy with 8 programmers (or 6 good programmers). Depending on the problem I suppose that would allow you to scale to 50 programmers or so. More than that will probably raise the risk unacceptably no matter what method you choose.
But 50 programmers should be able to maintain a rate of about 30K lines of production code per week (in fully TDD code). I have to say that I can't imagine wanting to go faster than that... Finding 50 programmers who can do XP well might be rather challenging, though.
Yes, you are correct. In fact there are a whole raft of tools that you probably would like to have once you know what you need. I find it interesting that the OP is asking /. about advice for tools having already built all the tools that they need. This tells me that they are likely trying to find a tool to fix process problems. That is backwards. You should fix your process and then notice that you are missing a tool (or a feature in one of your tools). Then it's pretty obvious what you need to get. I suppose it is remotely possible that one of those all-singing, all-dancing process improvement suites implement everything they way you are already doing it, but it seems unlikely. And there is no possible way that anyone on /. would know which one to recommend.
People, in general, are a cost and not necessarily an asset. Making sure all your activities are returning value is an important part of running a business. More warm bodies looking busy doesn't make you more efficient, that's for sure. And in many large organizations I've worked in the "Process People" have often been "warm bodies looking busy".
However, there is a difference between a bad idea and a bad implementation. Having been involved in CMMI/ISO audits I have seen what kind of joke it can be. Those warm bodies are doing exactly what you suggest -- the minimum to pass their audit (which is barely anything at all, if I am honest -- mostly running around hiding evidence that the process is not being followed). But ISO and CMMI is not to blame for this injustice. The problem is those warm bodies and attitudes like yours.
Most "Process People" sit around fantasizing about what process everyone should follow. Then they write it down and tell everyone to follow it. Never mind that they have never actually seen what people are actually doing now. This is precisely the opposite of what is recommended by these meta-processes. How many times have I heard, "Well, normally it takes 5 years to get to CMMI level 4, but I think we can do it in 2 months if everyone cooperates"? Having said that, they have demonstrated their ignorance for any point at all in CMMI.
Document what everyone is doing. Not what they say they are doing; not what they want to be doing; not what you wish they were doing; what they are actually doing. That's your process. Compliance? Dead easy. They are already doing it. Documentation? It's not exactly rocket science. Make sure people put version numbers on documents. Or better yet, put everything in an SCM and say that all paper versions are merely drafts. Done.
You are right that you should do the very minimum that you can do with ISO and CMMI. Not because it is a waste of time, but because sitting around concocting elaborate plans for a cool process doesn't align with reality. Neither ISO nor CMMI tells you what you should be doing in your process. It tells you what you should be observing and thinking about. For level 2 you can write down pretty much anything you want for each section.
But the point is, once you have everything written down you can look at it and say, "Hmmm... we have some inefficiencies here. Bob, if you were to do X before Y it would help out Sally. Would that be OK?" Also, having written everything down it makes it easy for new people to come in and get an idea of the existing culture without having to discover it through trial and error. It allows them to quickly identify areas that they may want to change -- "You know guys, in my last company we did X. What do you think".
As you may have guessed, I have had the misfortune of being one of those "Process Guys". I prefer coding, but sometimes you have to do what you have to do. In my time as a process guy I tried to spend 80% of my time documenting what people were doing, identifying things that had changed over time and asking why the changes were made. I spent 10% measuring various things and making pretty graphs for upper management. I spent 10% of my time giving advice for things that teams might want to try to improve their efficiency. I spent 0% of my time enforcing compliance. If people didn't follow the process, then the process was wrong. I think that the fact that my management preferred me to do this work than write code (despite my protests) says something about the value I returned to the company.
Finally, to answer the question of the OP -- Don't buy a tool. A tool models someone else's vision of reality -- not what your people are actually doing. If you buy a tool off the shelf then you will spend most of your time chasing compliance rather than improving workflow. It really will be a waste of time and money.
Oh, and I dare not start asking about the visa status of some of these workers. It's a sensitive subject. Many will just get up and walk away.
If you are asking the foreign workers themselves, what you may not realize is that they are often threatened a lot about their visa status -- by HR or even their own management. In many of the big companies where I worked I found out that management/HR would threaten to fire foreign workers if they didn't work insane hours, or do exactly what they were told. Sure it's improper dismissal, but it's hard to argue from another continent. Or worse, their salary is often the lifeblood of their entire extended family. Even a short intermission in the money could lead to serious hardship. Their visa status is a very sore point because it is how they are able to be treated so badly by others.
Well, I was going to call bullshit on this, but I checked and it seems Indian Software developers make less than $7K US per year. I'm pretty frugal and even I would have a hard time living on less than $10K in the west.
It is interesting, though. I've been through enough outsourcing disasters to know that even at 10x the cost, it's worth it to have your management and developers on the same continent. As someone else said, surely someone will think of doing something like doubling the salary, skimming off all the best Indian (or whatever) programmers and kicking everyone else's butt. I guess the saving grace is that there is hardly anyone that knows how to hire programmers and get something other than completely random skill levels...
Your value may grow, but money is not a measure of value (it's an odd concept, I know). It's really lubrication that allows you to realize value. So in your example, with the extra money, the farmer can realize value and we get growth. The money supply *does* increase, but not because we increased value. It increases because we increased debt. Even if the farmer doesn't increase his efficiency, we will still increase the money supply because money is created when we have debt. Someone will have more money -- whether or not it is the farmer is a moot point.
The real question comes when you wonder, "where does the money come from to pay the farmer his extra 20% profit". Well, that also comes from debt. And that money also has to be repaid with interest. So we have bank who makes 2 loans. Loan f goes to farmer F and loan b goes to buyer B. Farmer F sells his produce to buyer B and gives him the money b. The money b is equal to the farmer's load f plus the interest on f. Farmer F uses the money to pay off his loan. But B now has food and a debt for b (which is bigger than f, remember). What can he do? Well he can sell some of the food at a profit. But the money from that has to come from the bank. So the bank make a loan to C for c amount. C buys the food and B repays his loan with c. Remember c has to include the interest for b, so it it bigger than b.
Since all money poofs into existence from loans, the debt gets bigger and bigger. There isn't enough money in the money supply at any one time to satisfy the debt. It just keeps getting bigger and bigger until people default on their loans and the whole thing comes crashing down. It is a classical Ponzi scheme.
Except, earlier in this discussion someone pointed out that there is an alternative. The banks make profit, which is the interest that they made on the loans. If they spend their money in on consumable items (like food, fuel, etc), they this money will make it back into the economy and can offset the problem. However, banks aren't really renown for spending their profits on consumables. They usually use those profits to invest in more profit making enterprises.
The main point is that unless we have continuous growth, we can potentially have serious problems. This is why government panic so much when their population decreases, even when they are overpopulated.
I often wonder whether the universe simply uses lazy evaluation. In other words, the position, momentum etc are not evaluated until a particle actually interacts with another particle. From the perspective of being in the universe we can't observe the unevaluated state because any attempt at observation causes particles to interact, creating the evaluated state.
If that is true, I start to wonder if there is "local evaluation". So if two particles interact, they are evaluated in their own reference frame, but from the perspective of other particles not involved in the interaction, are they still unevaluated?
Then I start to think, if that is true maybe everything runs in parallel. So every particle is evaluated in its own reference frame, but unevaluated in other reference frames unless the two reference frames interact. Then whether or not reference frames interact should be computable (outside the universe). In other words, even though an electron has a non-zero probability to exist anywhere in the universe, if all reference frames are evaluated from their own perspective, the chance of interaction with another reference frame could be zero. Of course, being part of the universe, we can't observe this because those other reference frames are unevaluated from our perspective.
But then I think... I don't have a fucking clue how quantum physics works and this is likely very naive. But it gives me a way to wrap my head around the concept...
I like games, but I fall into a category of people that couldn't really be called a gamer.
I don't have 40-60 hours of free time. I mean, seriously. How long is this game supposed to last? Should I really spend 1-2 hours a day for the next month of my life playing a game? I could get some exercise, or learn a language, or clean my house, or get a girlfriend.
I'm not saying this to make fun of people who choose to spend that time playing games, but it's a huge time commitment for a normal person. And you don't really get much payback IRL. I could maybe do something like 30-40 minutes 2 or 3 times a week, but then this game is going to take me more than a year. I'm going to get seriously tired of it. Also, I'll never build up the skills necessary to actually complete the game.
For me the grinding isn't just annoying. I deeply resent it. I might actually have some hope of completing the game -- of enjoying the story line, if it weren't for all the mindless grind. Even worse (especially in Japanese RPGs) is the meaningless dialog. You can tell somebody has added cut scenes and dialog just to pad out the length.
Couldn't we have a short mode, in addition to a difficulty mode in these games. Cut out all the mindless stuff, multiply the XPs and get me through the game in 10 hours. For a guy like me 10 hours of solid entertainment is well worth the price of a game. You don't have to pad it. Or to put it more accurately, if you pad it I won't buy it because I have no hope of seeing the whole thing (who would pay for a movie they will only watch 25% of...)
I really wish I remember who said this, but I once heard an interview and the person was asked, "Did sanctions on South Africa help end apartheid?"
The answer was that none of the economic sanctions did any bit of good at all. There are ways around those kinds of issues. But the sanctions on sport was felt keenly and deeply in South Africa. More than anything else, this was the one thing that outside countries did to help end Apartheid. Whether or not it is true I don't know, but I thought it was very interesting observation.
Obviously I can't know exactly what they are thinking, but here's my guess. To us the business case is obvious: if you provide a service which is convenient and cheap enough, most people will opt for convenience and pay for the product. I mean you *could* have a garden and grow your own food, and you could prepare that food yourself. It isn't *that* much work and the result is very rewarding. But most people would rather get in their car and drive to Mac Donald's. Why? Because it is convenient. People are willing to pay for that convenience as long as the cost is reasonable.
But the media execs, even if they realize this, want the freedom to charge whatever they want for things. What is a movie *worth*? Well, since you don't need it at all it doesn't have any intrinsic value. It's only value comes from creating a desire to want to see it and limiting the availability to see it. The value of the movie becomes what the customer is willing to pay, not what it's intrinsic worth is.
The media industry has also realized that high prices serve their interest even if they don't directly make high profits as a result. People will want to see movies more if there are huge amounts of special effects, high priced actors, etc, etc. If the average movie costs $1 million to make, you will have a lot of competition from other companies. But if it costs $100 million, there aren't many groups with the capital to break in and compete with you. So if you can raise prices and spend all your money on production, advertising, etc, etc you still end up ahead. This is especially true if you are performing all those services and skim a profit at each step (i.e., the movie makes no profit but every service performed makes a profit and since you own those services you make a profit).
So in other words, they need to keep supply low to keep prices high to maintain their monopoly position in the industry. I believe this is their real interest in DRM. The "convenience" price point is too low to accomplish this.