"Seriously, it's the magic of the invisible hand that issues like that are taken care of."
Seriously, you are right.
This means the buyer is perfectly informed (hint: it is not. No matter how many "energy stars" you apply, the long run economics on such a diluted good as electricity in a house are far beyond what's reasonable expectable from a buyer) and that all cost/benefit ballance is exactly between seller and buyer (hint: it is not. Electricity is a strongly subsidized/governmentcontrolled bussiness that needs *hugh* support structures for its supportability. I. e.: even if a new rich can stand for 1MW/year at his home the nation still has to provide electric grid for it; since electricity is of strategic value for any nation you don't want it enterily on private hands. At least *I* don't want it exclusively, regulation included, on private hands).
So, yes, you are rigth regarding the value of the "invisible hand". It's only that the "invisible hand" is of very limited application here.
"Machiavelli is in the same club with Nero, Caligula, etc. Maybe not in the same circle of that club, but the same club nonetheless. Not a good way to be remembered."
"Uh, what? You are so wrong. That's not how science necessarily works."
Not at all. But *you* are so wrong. Where was I talking about science? I was talking about *patents*, which should be tied to an industrial endevour.
"Ideas are precisely what patents are designed to protect"
*You* are *so* wrong! Please pay a little attention what patents are about and come later. Hint: patents are about protecting industrial processes, machines, articles of manufactures, not ideas.
But it's true there's a strong lobby tending to blur what a patent is about so public opinion thinks it's about ideas. That way it'll be much more easier to pass laws so ideas are the object of a patent (this is what everybody thinks patents are about so why not?)
"I wonder how they know that the download is pirated. Do they know if the downloader has or not the music on CD?"
I don't need to own the CD and still downloading it from a P2P for my private usage is not illegal.
Remember this was an international study and that behaviour is perfectly legal in at least some countries (while organizations alike RIAA are strongly lobbying to change this both at the political level and at the public opinion one).
"The amount of P2P traffic with copyrighted material is still huge."
But the IFPI is equating P2P traffic with copyrighted material with illegal traffic and this is not the case. Most if not all EU countries have protections for the private copy and P2P is on that category so it is perfectly legal.
"An amusing case study was when Icelandic police shut down a popular local torrent site featuring mostly copyrighted material."
Check Iceland laws just in case. In Spain it wouldn't be the first case of a "local torrent site featuring mostly copyrighted material" shut down by police with hugh media coverage about how those bastard pirates are destroying "art". Of course, when months later SGAE (Spanish RIAA) lost the case or it was even rejected you don't see equivalent media coverage and the hurting is already done.
"Im thinkin the real weight of the patent system isnt even touched by major corps. Individual and small group/investment firm patent companys like Eolas looking for that ONE patent to go home on, by sheer numbers, probably dwarf the IBM and MS's of the world.. regardless.."
I really don't know, but it doesn't matter. The core of the bussines here is not having "that ONE patent" but having that one patent WITHOUT an industry backing it up. Big corps have used patents as deterrent weapons against their rivals for decades now but the problem here is not a little tech company with the "ONE patent": as long as they produce something, they are probably in violation of dozens of patents belonging to the very ones they want to license to, so they will be forced into a mutual agreement; if the case is between two big corps they have such a big patent arsenal that they again are forced to cooperate or face an assured mutual destruction scenario. But lawyer-based firms don't produce anything so they are immune to the usual patent counterattack which has made the patent system flaws more obvious.
"Let's say I create Startup Inc, and design a new type of lithography. I don't have the money to build a fab or anything, so I show the tech to Intel and offer to let them use it in exchange for royalties."
In order for you to convince Intel you show them a prototype. *Then* you have a working example covering your patent. If you don't have even a prototype then all you have is an idea and ideas shouldn't be subjected to patents.
"Patent trolls suck, and there should be a way to stop them through litigation, but we have to be sure that we don't kill off real innovators in the process."
"On one hand if you agree to a contract, then it's binding."
It's binding as long at it is legal. You have this even on the USA (as you already stated you cannot contract yourself into slavery): remember all those clauses the kind of "to the extent allowed by local laws" and "this clause being found unforceable doesn't void the rest of the contract". In Europe all these things go into the "abusive clause" field and are unforceable (of course that doesn't mean on party cannot try -specially telecoms are known for it, it only means that if you are prepared for a long years battle to go to the highest courts on the basis of principles for those lame 100 you will win 100% of times).
And then, in order to "agree to a contract" some contract is needed. A contract needs to be clear, legal and based on good faith. Of course what "clear, legal and based on good faith" does exactly mean is up to a judge to decide but using other's Trade Mark and hiding the fact that there are unexpected and up front undeclared costs involved doesn't usually fit on the definiton.
"This story is really about German law allowing all sorts of scammers [...] all sorts of junk in EULAs as "binding contracts""
Well, it's usually said that devil is in the details. On one hand, to the best of my knowledge, German law is about "contracts", not "EULAs"; that makes an interesting point because a "contract" is not whatever one side of the deal says so but quite a complex thingie where both parties must be in a position of good faith information. I wouldn't say that a 6p letter page not linked from anything but the "show me all pages" index and a payment that is not explicitly stated till the good is already on posesion of the buying side has all conditions for a deal to be considered "a contract" (Legal TM).
On the other hand, "OpenOffice.org" is not a generic name last I saw but a protected trade mark. Since these kinds of scams can damage the image of the product I'd say Sun and/or the OpenOffice.org foundation can and probably should approach the scammer company privately asking it for 1000x retaliation if not cease and desist. That should do it with no need of somebody being hurt.
No, I meant to refer to the "broken window" parable: while it's true that "reinventing the wheel" is perfectly of application to closed source development I meant to focus on those that defend closed source because of the "tens of thousands of IT jobs" that "reinventing the wheel" due to closed source would allow for, as if just "doing things in order for money changing hands" were sufficient for wealth to be magically created, which is exactly the message from the "broken window".
"Oh Jesus Christ. Have you just invented a new derogatory term for closed source"
I'd accept to have invented a new term (without your "derogatory") but it was simply that I'm Spanish and I falled on a "false friend" term. Transalation into Spanish for "closed source" is "código privativo" so my fault.
Now, about the "derogatory" thing. Is it "derogatory" simply not supporting the opinion of the parent post? Or you will kindly point out where the "derogatory" part was?
"as to why Open Source is good?"
While I certainly hold my own opinions, I don't think those were explicitly stated on my post. All I did was expressing that saying "When you write some software [...] Things have a habit of being rewritten completely in relatively short intervals" is not applicable to all software equally but mainly to a subset ot it: that distributed under a closed source license. After that I went on reasoning why I supported such opinion which seems to be a bit over your 'standard practices'.
"When you write some software [...] Things have a habit of being rewritten completely in relatively short intervals."
When you write *privative* software, you meant. Privative software suffers from the "broken glass" problem: for the most part is redo what already was done, both among competing products and between versions of the same product (well, version shifting is more to add featuritis and in cases of dominant products both for vendor lock-in and to maintain third party/competing products at a distance). This is not usually the way with open source software.
"How much of the code from Linux of even 15 years ago is in the current kernel?"
Taking into account Linux is barely 15 y.o. not much, true. But there's indeed quite a lot of code that has been there for long years. And even then, you forget that even shifting code it there to allow third parties to cooperate.
"How much of AutoCAD 1.0 is in the current version?"
Privative software: at the very least one of the major differences among versions is changing file formats for lock-in and disallow competing products to stay at path. Not much benefit on this work for the users.
"The code gets rewritten and forgotten."
It is not. Minix is still used as a learning platform as it is with older versions of *BSDs. I bet that code from ls cp or a lot of basic Unix-related commands haven't changed for ages.
"If we're going to spend unfathomable amounts of MY money, lets have something to show for it that will still be useful in 80 years."
Nobody can forecast the future but, certainly, you will optimize your bets if such a software is open sourced.
"One of the main commandments in agile development is that the requirements cannot change."
Maybe you read the wrong book. In my book requirements don't change *within a sprint*.
"Also, you are supposed to plan and code for a feature to be shippable when it is done."
And you plan it so it can be done within a sprint. So before the sprint you get the client to accept feature "A" (you will show him a list of features so is he, not you, then one that sorts them). After the sprint you offer your client the promised feature "A" (and ideally, you bill your client for the feature).
"But in the office, requirements keep changing as much as they did with waterfall"
And that's exactly why agile exists: because it recognices requirements *will* change. Since they'll change why expend a lot of time on producing a very long list of intermingled requirements, then a long (and costly) development cycle, then after a long time and expenditure show the whole list of asked for requirements done only to find that 25% of the original requirments were not indeed required because the client didn't properly understood them, 25% of them were wanted no more because on such a long time situation changed and 50% new requirements arosen because, again, the long time awaited?
You better agree on a sketchy *cheap* and *fast* gross list of requirements, short them as for the client's percieved value and start producing functionally complete code ASAP. The client is glad because gets to see the advance on the project; your company is glad, because the client is glad, it can suck money faster from it, and due to the constant exchange of ideas is easy to engage on new projects. When agile is possible is a win-win proposition.
"This messes up the schedule."
That clearly means you are not doing agile at all. If you have a long run schedule, you are not doing agile. If you are doing agile, then there's no long run schedule to mess up with. You can have a starting grosstimate at best and the continous feedback with your client will make him easly understand and accept any delays because it will have strong feedback about being him not you the main responsible for the slippage.
"And features only get to the "done enough for now" stage which means that they are good enough to sort of work and build on, but they are not complete or shippable."
Again, you are clearly not doing "agile". Of course bugs can arise but if you do it the proper way there's no way for a feature to be so long running and complex that they can slip too much (they should fit within a single sprint), and since you are doing tests->autodoc->prototype->implementation there's no chance of shipping "done enough" features as is the case when you develop functionality for the easy cases->corner cases->documentation (this too common way is the one that always gets cut up at step one "easy cases" since then it "seems" to work; the first way only seems to work when it indeed works).
"not everyone is going to say no to the boss"
Again, "agile" works on the assumption that in fact nobody can say "no" to the boss producing a framework where you won't need to say "no" to the boss.
"The seminar example was a web app [...] In my office, the software is much more complex"
This seems to be the only sensical assertion you made to this point. Yes it's true: agile is not the solution for every project. While proper practice and experience can help you to find a way to split more and more problems so it can become "agile-tractable" there will definetly be situations where due to the inherent complexity and internal coupling of the problem "agile" is not the way to go. If the seminar guy explicitly told or make the impression that "agile" is a silver bullet for any software project, then that just were a "snake oil vendor seminar", not to say that there are no little numbers of them.
"I think you're suggesting that Microsoft "gained" their monopoly fair and square. As if "apparently people liked [Windows].""
Well, to some extent, they did. Or, to say it better, current outcome would be probably similar even if Microsoft limited itselt to their fair practices disregarding the bad ones.
On the beginning Gates were just lucky and had the eye to take advantage of his luckyness: the first PC for the masses was preloaded with his OS (DOS). Then, by the early days of Windows, Apple tried to be "too clever" trying to get both the hardware and the software market. It didn't work. IBM tried to be "too clever" trying to get the hardware market for them only. It didn't work. The big UNIX names thought that the big money was securely tied on their side and disregarded those "toy" hardware and software new systems. It didn't work.
Then the first days of networking came. Again the UNIX guys didn't see what was coming. Novell thought they could retain their grip on the emerging market not considering their fragility against Microsoft's natural strategy: the OS is Microsoft; main productivity apps are growingly belonging to us... what do you think that will happen as soon as we deliver even a half-assed "network system" (as it were 3.11 for workgroups first and NT after that)? That's right: why having to deal with two companies and two phylosophies when we can get it done with just one and lower costs and complexities?
Of course that doesn't mean I have great sympathy for their "other" practices (backstabbing IBM on the OS/2 issue; making Dr DOS seem buggy when detected; forbiding integrators to deal with other OS vendors like BeOS; changing standards just to break compatibility with other vendors as they tried with J++, early versions of Exchange, the days of the browser wars or currently with Kerberos; changing their own protocols just to break third party compatibility as it happend with Samba...) but that they cleverly knew how to build their advantage on all fields, either ethical or unethical.
"Schools prefer to use Windows because it's what the vast majority of their faculty and staff know, it's what the vast majority of their software runs on, and it's what students will encounter on the vast majority of computers they will use in the real world."
I can accept points one and two but point three, "it's what students will encounter on the vast majority of computers they will use in the real world" is and always has been total utter bullshit. Whatever the students are using now will have only minor correlation to whatever they'll found in "the real world" few years from now. When I were in school it were the days of Microsoft DOS. How much does it resembles Windows Vista to Microsoft DOS except that there's "Microsoft" in the name? Is it really so much similar Windows 98 to Windows Vista than it is to current versions of Gnome or KDE upon Linux?
In fact, the reverse is truer: whatever I learnt about DOS on my school days serves me nothing on current versions of Microsoft OS and apps. On the other hand, what I learnt on my university days about NFS, X Window, DNS, SMTP, Vi... is still serving me now almost word by word about fifteen years later. And this is not per chance: Microsoft, being the principal actor and living out of selling licenses is *forced* to add new features and change the way of doing things just "to stay the same" while others, specially if not competing on selling usage licenses, can maintain whatever is already working just the same for ages.
"So it's possible for more than one missile to hit a target."
Yes. But obviously that renders a less than 100% hit ratio for any single missil and "just" (supposedly) 100% kill ratio for multiple missiles. In order to have "100+%" kill ratio you must kill somebody at least twice.
"You say that as if it's a good thing or an unchangeable fact of life."
Of course it's not a good thing but, to an extent yes, is an unchangeable fact of life. You just take the corporation case to the extreme and imagine a single corporation hiring the whole world population, or at least, the whole population of "whatever" (say, Java developers). It's then self-evident that their average-whatever will be *exactly* world's average for such position. This is the limit corporations tend to as they grow their ranks.
"A coder who can't properly handle a daily SCM workflow [...] Anyone who tolerates such people on their team either has no clue"
"Proper" daily SCM workflow for an average coder limits to update and check out; changing his working branch at most. Anything else is probably that the team organization "has no clue". And this three common operations can be managed by a visual app or simple command line aliases at worst so no coder has the chance to screw or slack due to this.
And regarding "tolerating such people on their teams" I just point to this very Slashdot article: just see how *many* people says it's from quite incovenient to intolerable that Git has no proper plug-in for their IDE du jour being that SCM operations are basically independent from their development efforts. In your account most if not all of them enter on the category of those not being worth enough and should be fired. Now ask them if they really consider themselves unfitted for their share of software development and/or ask their managers. The developers will tend to consider themselves "avobe average" on average and their managers will probably consider them "average".
"It's no secret anymore that the difference in productivity between a great coder and a mediocre coder is measured in orders of magnitude."
True. As it has been known for ages that some horses run faster than others. The key is to know in advance *which* horse will run the race faster than the others. An inspection to the horse-racing gambling bussiness, it seems not to be such an easy task.
"Google, Yahoo, Microsoft, Oracle and others are all said to aim for top-notch only."
Looking at their factual results it would seem that well, either "aiming" and "getting" is quite a different bussiness or that there's no such big difference on net results between "top-notch" and "average". On the other hand, that they aim for (and maybe even get) top-notch doesn't mean that their internal management practices are not oriented towards allowing mediocrity to add up productivity and not hurting too much.
"But the idea is to have Einsteins in all critical positions"
Of course yes. But "average team programmer" is not a "critical position". Corporation-wide "critical position" means CxO and related.
"The best thing, IMHO, is that in Git I can make changes that break the build, and check them in anyway."
Then it is the process the one broken, not the central SCM tool. SCM stands for Source Code Management it says nothing about "it must compile". If it makes sense, then the process around the tool should allow you to commit without "breaking" anything.
"Then I keep working, and keep making checkins, until it's ready to go up on the master server"
You are adding unqualified semantics, again, due to poor processes in place. Why are you saying "it's ready to go up to the master server" when you really meant "it's ready to compile", or to go to QA or anyhting to such point?
"I guess I could do something similar on a centralized version control system, if I could work in my own branch"
Exactly! That's a common pattern. Well, it's an antipattern (a branch per developer) but you start to see the light; a brach per bug/feature is better. And applying patches from trunk to a "build branch" maybe by means of a moving tag is even better.
"as long as merging the branch later is really easy"
Quite true: some tools are better on that regard than others (svn for instance has its own nuisances about it, but branching/merge back is cheap and easy, once the process is properly understood -basically just remember at which revision did you started the branch with "svn cp" plus "svn switch" and then "svn merge" plus "svn switch" again when you are finished and even this is becoming easier on new svn versions). And some processes are better suited than others (and the so common "we build out of the head of the trunk, so you don't dare break the build process with your commits" is probably the worse of them and the one that makes DCMS so attractive for developers on a corporate environment where centralized SCM usually makes the most sense).
"I have a better idea: Why don't you just fire the incompetent slacker instead of slowing down the rest of your team?"
Because as the previous poster already stated, it is a corporation environment. You can hope on a short company to have above average developers, but on a big corporation you know your average whatever, (not only developer) will be, well, average, and then the clever thing is to manage for that. And then, that average worker's job is not dealing with the SCM but dealing with his part of code; if he does it well enough then is nothing but proper management practice to get out of his way anything else. Remember corporate burocracy is basically the art of dealing with mediocrity.
Slashdot Mirror
"Seriously, it's the magic of the invisible hand that issues like that are taken care of."
Seriously, you are right.
This means the buyer is perfectly informed (hint: it is not. No matter how many "energy stars" you apply, the long run economics on such a diluted good as electricity in a house are far beyond what's reasonable expectable from a buyer) and that all cost/benefit ballance is exactly between seller and buyer (hint: it is not. Electricity is a strongly subsidized/governmentcontrolled bussiness that needs *hugh* support structures for its supportability. I. e.: even if a new rich can stand for 1MW/year at his home the nation still has to provide electric grid for it; since electricity is of strategic value for any nation you don't want it enterily on private hands. At least *I* don't want it exclusively, regulation included, on private hands).
So, yes, you are rigth regarding the value of the "invisible hand". It's only that the "invisible hand" is of very limited application here.
"Machiavelli is in the same club with Nero, Caligula, etc. Maybe not in the same circle of that club, but the same club nonetheless. Not a good way to be remembered."
I bet you never read The Prince.
"As a manager, I would NEVER have this type of attitude towards people or allow that type of attitude to germinate in my department"
So do you really think managers never have to reach a point where they must say "that's the way it goes, take it or leave"?
"Uh, what? You are so wrong. That's not how science necessarily works."
Not at all. But *you* are so wrong. Where was I talking about science? I was talking about *patents*, which should be tied to an industrial endevour.
"Ideas are precisely what patents are designed to protect"
*You* are *so* wrong! Please pay a little attention what patents are about and come later. Hint: patents are about protecting industrial processes, machines, articles of manufactures, not ideas.
But it's true there's a strong lobby tending to blur what a patent is about so public opinion thinks it's about ideas. That way it'll be much more easier to pass laws so ideas are the object of a patent (this is what everybody thinks patents are about so why not?)
"Use a virtualisation prooduct, and on two of your hosts run 2 VMs with Windows 2008 Core, Active Direcotry and DHCP serivces."
Then have a hardware problem on your virtualization hardware and return to square 1.
"I wonder how they know that the download is pirated.
Do they know if the downloader has or not the music on CD?"
I don't need to own the CD and still downloading it from a P2P for my private usage is not illegal.
Remember this was an international study and that behaviour is perfectly legal in at least some countries (while organizations alike RIAA are strongly lobbying to change this both at the political level and at the public opinion one).
"The amount of P2P traffic with copyrighted material is still huge."
But the IFPI is equating P2P traffic with copyrighted material with illegal traffic and this is not the case. Most if not all EU countries have protections for the private copy and P2P is on that category so it is perfectly legal.
"An amusing case study was when Icelandic police shut down a popular local torrent site featuring mostly copyrighted material."
Check Iceland laws just in case. In Spain it wouldn't be the first case of a "local torrent site featuring mostly copyrighted material" shut down by police with hugh media coverage about how those bastard pirates are destroying "art". Of course, when months later SGAE (Spanish RIAA) lost the case or it was even rejected you don't see equivalent media coverage and the hurting is already done.
"Im thinkin the real weight of the patent system isnt even touched by major corps. Individual and small group/investment firm patent companys like Eolas looking for that ONE patent to go home on, by sheer numbers, probably dwarf the IBM and MS's of the world.. regardless.."
I really don't know, but it doesn't matter. The core of the bussines here is not having "that ONE patent" but having that one patent WITHOUT an industry backing it up. Big corps have used patents as deterrent weapons against their rivals for decades now but the problem here is not a little tech company with the "ONE patent": as long as they produce something, they are probably in violation of dozens of patents belonging to the very ones they want to license to, so they will be forced into a mutual agreement; if the case is between two big corps they have such a big patent arsenal that they again are forced to cooperate or face an assured mutual destruction scenario. But lawyer-based firms don't produce anything so they are immune to the usual patent counterattack which has made the patent system flaws more obvious.
"Let's say I create Startup Inc, and design a new type of lithography. I don't have the money to build a fab or anything, so I show the tech to Intel and offer to let them use it in exchange for royalties."
In order for you to convince Intel you show them a prototype. *Then* you have a working example covering your patent. If you don't have even a prototype then all you have is an idea and ideas shouldn't be subjected to patents.
"Patent trolls suck, and there should be a way to stop them through litigation, but we have to be sure that we don't kill off real innovators in the process."
Two words: Trade Secrets.
"I've seen Debian security releases break things too."
Can you provide an example, please?
"On one hand if you agree to a contract, then it's binding."
It's binding as long at it is legal. You have this even on the USA (as you already stated you cannot contract yourself into slavery): remember all those clauses the kind of "to the extent allowed by local laws" and "this clause being found unforceable doesn't void the rest of the contract". In Europe all these things go into the "abusive clause" field and are unforceable (of course that doesn't mean on party cannot try -specially telecoms are known for it, it only means that if you are prepared for a long years battle to go to the highest courts on the basis of principles for those lame 100 you will win 100% of times).
And then, in order to "agree to a contract" some contract is needed. A contract needs to be clear, legal and based on good faith. Of course what "clear, legal and based on good faith" does exactly mean is up to a judge to decide but using other's Trade Mark and hiding the fact that there are unexpected and up front undeclared costs involved doesn't usually fit on the definiton.
"This story is really about German law allowing all sorts of scammers [...] all sorts of junk in EULAs as "binding contracts""
Well, it's usually said that devil is in the details. On one hand, to the best of my knowledge, German law is about "contracts", not "EULAs"; that makes an interesting point because a "contract" is not whatever one side of the deal says so but quite a complex thingie where both parties must be in a position of good faith information. I wouldn't say that a 6p letter page not linked from anything but the "show me all pages" index and a payment that is not explicitly stated till the good is already on posesion of the buying side has all conditions for a deal to be considered "a contract" (Legal TM).
On the other hand, "OpenOffice.org" is not a generic name last I saw but a protected trade mark. Since these kinds of scams can damage the image of the product I'd say Sun and/or the OpenOffice.org foundation can and probably should approach the scammer company privately asking it for 1000x retaliation if not cease and desist. That should do it with no need of somebody being hurt.
"You may have meant reinventing the wheel."
No, I meant to refer to the "broken window" parable: while it's true that "reinventing the wheel" is perfectly of application to closed source development I meant to focus on those that defend closed source because of the "tens of thousands of IT jobs" that "reinventing the wheel" due to closed source would allow for, as if just "doing things in order for money changing hands" were sufficient for wealth to be magically created, which is exactly the message from the "broken window".
"Oh Jesus Christ. Have you just invented a new derogatory term for closed source"
I'd accept to have invented a new term (without your "derogatory") but it was simply that I'm Spanish and I falled on a "false friend" term. Transalation into Spanish for "closed source" is "código privativo" so my fault.
Now, about the "derogatory" thing. Is it "derogatory" simply not supporting the opinion of the parent post? Or you will kindly point out where the "derogatory" part was?
"as to why Open Source is good?"
While I certainly hold my own opinions, I don't think those were explicitly stated on my post. All I did was expressing that saying "When you write some software [...] Things have a habit of being rewritten completely in relatively short intervals" is not applicable to all software equally but mainly to a subset ot it: that distributed under a closed source license. After that I went on reasoning why I supported such opinion which seems to be a bit over your 'standard practices'.
"When you write some software [...] Things have a habit of being rewritten completely in relatively short intervals."
When you write *privative* software, you meant. Privative software suffers from the "broken glass" problem: for the most part is redo what already was done, both among competing products and between versions of the same product (well, version shifting is more to add featuritis and in cases of dominant products both for vendor lock-in and to maintain third party/competing products at a distance). This is not usually the way with open source software.
"How much of the code from Linux of even 15 years ago is in the current kernel?"
Taking into account Linux is barely 15 y.o. not much, true. But there's indeed quite a lot of code that has been there for long years. And even then, you forget that even shifting code it there to allow third parties to cooperate.
"How much of AutoCAD 1.0 is in the current version?"
Privative software: at the very least one of the major differences among versions is changing file formats for lock-in and disallow competing products to stay at path. Not much benefit on this work for the users.
"The code gets rewritten and forgotten."
It is not. Minix is still used as a learning platform as it is with older versions of *BSDs. I bet that code from ls cp or a lot of basic Unix-related commands haven't changed for ages.
"If we're going to spend unfathomable amounts of MY money, lets have something to show for it that will still be useful in 80 years."
Nobody can forecast the future but, certainly, you will optimize your bets if such a software is open sourced.
"One of the main commandments in agile development is that the requirements cannot change."
Maybe you read the wrong book. In my book requirements don't change *within a sprint*.
"Also, you are supposed to plan and code for a feature to be shippable when it is done."
And you plan it so it can be done within a sprint. So before the sprint you get the client to accept feature "A" (you will show him a list of features so is he, not you, then one that sorts them). After the sprint you offer your client the promised feature "A" (and ideally, you bill your client for the feature).
"But in the office, requirements keep changing as much as they did with waterfall"
And that's exactly why agile exists: because it recognices requirements *will* change. Since they'll change why expend a lot of time on producing a very long list of intermingled requirements, then a long (and costly) development cycle, then after a long time and expenditure show the whole list of asked for requirements done only to find that 25% of the original requirments were not indeed required because the client didn't properly understood them, 25% of them were wanted no more because on such a long time situation changed and 50% new requirements arosen because, again, the long time awaited?
You better agree on a sketchy *cheap* and *fast* gross list of requirements, short them as for the client's percieved value and start producing functionally complete code ASAP. The client is glad because gets to see the advance on the project; your company is glad, because the client is glad, it can suck money faster from it, and due to the constant exchange of ideas is easy to engage on new projects. When agile is possible is a win-win proposition.
"This messes up the schedule."
That clearly means you are not doing agile at all. If you have a long run schedule, you are not doing agile. If you are doing agile, then there's no long run schedule to mess up with. You can have a starting grosstimate at best and the continous feedback with your client will make him easly understand and accept any delays because it will have strong feedback about being him not you the main responsible for the slippage.
"And features only get to the "done enough for now" stage which means that they are good enough to sort of work and build on, but they are not complete or shippable."
Again, you are clearly not doing "agile". Of course bugs can arise but if you do it the proper way there's no way for a feature to be so long running and complex that they can slip too much (they should fit within a single sprint), and since you are doing tests->autodoc->prototype->implementation there's no chance of shipping "done enough" features as is the case when you develop functionality for the easy cases->corner cases->documentation (this too common way is the one that always gets cut up at step one "easy cases" since then it "seems" to work; the first way only seems to work when it indeed works).
"not everyone is going to say no to the boss"
Again, "agile" works on the assumption that in fact nobody can say "no" to the boss producing a framework where you won't need to say "no" to the boss.
"The seminar example was a web app [...] In my office, the software is much more complex"
This seems to be the only sensical assertion you made to this point. Yes it's true: agile is not the solution for every project. While proper practice and experience can help you to find a way to split more and more problems so it can become "agile-tractable" there will definetly be situations where due to the inherent complexity and internal coupling of the problem "agile" is not the way to go. If the seminar guy explicitly told or make the impression that "agile" is a silver bullet for any software project, then that just were a "snake oil vendor seminar", not to say that there are no little numbers of them.
"I think you're suggesting that Microsoft "gained" their monopoly fair and square. As if "apparently people liked [Windows].""
Well, to some extent, they did. Or, to say it better, current outcome would be probably similar even if Microsoft limited itselt to their fair practices disregarding the bad ones.
On the beginning Gates were just lucky and had the eye to take advantage of his luckyness: the first PC for the masses was preloaded with his OS (DOS). Then, by the early days of Windows, Apple tried to be "too clever" trying to get both the hardware and the software market. It didn't work. IBM tried to be "too clever" trying to get the hardware market for them only. It didn't work. The big UNIX names thought that the big money was securely tied on their side and disregarded those "toy" hardware and software new systems. It didn't work.
Then the first days of networking came. Again the UNIX guys didn't see what was coming. Novell thought they could retain their grip on the emerging market not considering their fragility against Microsoft's natural strategy: the OS is Microsoft; main productivity apps are growingly belonging to us... what do you think that will happen as soon as we deliver even a half-assed "network system" (as it were 3.11 for workgroups first and NT after that)? That's right: why having to deal with two companies and two phylosophies when we can get it done with just one and lower costs and complexities?
Of course that doesn't mean I have great sympathy for their "other" practices (backstabbing IBM on the OS/2 issue; making Dr DOS seem buggy when detected; forbiding integrators to deal with other OS vendors like BeOS; changing standards just to break compatibility with other vendors as they tried with J++, early versions of Exchange, the days of the browser wars or currently with Kerberos; changing their own protocols just to break third party compatibility as it happend with Samba...) but that they cleverly knew how to build their advantage on all fields, either ethical or unethical.
"Schools prefer to use Windows because it's what the vast majority of their faculty and staff know, it's what the vast majority of their software runs on, and it's what students will encounter on the vast majority of computers they will use in the real world."
I can accept points one and two but point three, "it's what students will encounter on the vast majority of computers they will use in the real world" is and always has been total utter bullshit. Whatever the students are using now will have only minor correlation to whatever they'll found in "the real world" few years from now. When I were in school it were the days of Microsoft DOS. How much does it resembles Windows Vista to Microsoft DOS except that there's "Microsoft" in the name? Is it really so much similar Windows 98 to Windows Vista than it is to current versions of Gnome or KDE upon Linux?
In fact, the reverse is truer: whatever I learnt about DOS on my school days serves me nothing on current versions of Microsoft OS and apps. On the other hand, what I learnt on my university days about NFS, X Window, DNS, SMTP, Vi... is still serving me now almost word by word about fifteen years later. And this is not per chance: Microsoft, being the principal actor and living out of selling licenses is *forced* to add new features and change the way of doing things just "to stay the same" while others, specially if not competing on selling usage licenses, can maintain whatever is already working just the same for ages.
"It's free, but you get what you pay for."
Yes. You get to be free of viruses.
"Zero mass is infinite mass. It's the same thing."
No, it isn't.
"So it's possible for more than one missile to hit a target."
Yes. But obviously that renders a less than 100% hit ratio for any single missil and "just" (supposedly) 100% kill ratio for multiple missiles. In order to have "100+%" kill ratio you must kill somebody at least twice.
"You say that as if it's a good thing or an unchangeable fact of life."
Of course it's not a good thing but, to an extent yes, is an unchangeable fact of life. You just take the corporation case to the extreme and imagine a single corporation hiring the whole world population, or at least, the whole population of "whatever" (say, Java developers). It's then self-evident that their average-whatever will be *exactly* world's average for such position. This is the limit corporations tend to as they grow their ranks.
"A coder who can't properly handle a daily SCM workflow [...] Anyone who tolerates such people on their team either has no clue"
"Proper" daily SCM workflow for an average coder limits to update and check out; changing his working branch at most. Anything else is probably that the team organization "has no clue". And this three common operations can be managed by a visual app or simple command line aliases at worst so no coder has the chance to screw or slack due to this.
And regarding "tolerating such people on their teams" I just point to this very Slashdot article: just see how *many* people says it's from quite incovenient to intolerable that Git has no proper plug-in for their IDE du jour being that SCM operations are basically independent from their development efforts. In your account most if not all of them enter on the category of those not being worth enough and should be fired. Now ask them if they really consider themselves unfitted for their share of software development and/or ask their managers. The developers will tend to consider themselves "avobe average" on average and their managers will probably consider them "average".
"It's no secret anymore that the difference in productivity between a great coder and a mediocre coder is measured in orders of magnitude."
True. As it has been known for ages that some horses run faster than others. The key is to know in advance *which* horse will run the race faster than the others. An inspection to the horse-racing gambling bussiness, it seems not to be such an easy task.
"Google, Yahoo, Microsoft, Oracle and others are all said to aim for top-notch only."
Looking at their factual results it would seem that well, either "aiming" and "getting" is quite a different bussiness or that there's no such big difference on net results between "top-notch" and "average". On the other hand, that they aim for (and maybe even get) top-notch doesn't mean that their internal management practices are not oriented towards allowing mediocrity to add up productivity and not hurting too much.
"But the idea is to have Einsteins in all critical positions"
Of course yes. But "average team programmer" is not a "critical position". Corporation-wide "critical position" means CxO and related.
"The best thing, IMHO, is that in Git I can make changes that break the build, and check them in anyway."
Then it is the process the one broken, not the central SCM tool. SCM stands for Source Code Management it says nothing about "it must compile". If it makes sense, then the process around the tool should allow you to commit without "breaking" anything.
"Then I keep working, and keep making checkins, until it's ready to go up on the master server"
You are adding unqualified semantics, again, due to poor processes in place. Why are you saying "it's ready to go up to the master server" when you really meant "it's ready to compile", or to go to QA or anyhting to such point?
"I guess I could do something similar on a centralized version control system, if I could work in my own branch"
Exactly! That's a common pattern. Well, it's an antipattern (a branch per developer) but you start to see the light; a brach per bug/feature is better. And applying patches from trunk to a "build branch" maybe by means of a moving tag is even better.
"as long as merging the branch later is really easy"
Quite true: some tools are better on that regard than others (svn for instance has its own nuisances about it, but branching/merge back is cheap and easy, once the process is properly understood -basically just remember at which revision did you started the branch with "svn cp" plus "svn switch" and then "svn merge" plus "svn switch" again when you are finished and even this is becoming easier on new svn versions). And some processes are better suited than others (and the so common "we build out of the head of the trunk, so you don't dare break the build process with your commits" is probably the worse of them and the one that makes DCMS so attractive for developers on a corporate environment where centralized SCM usually makes the most sense).
"I have a better idea: Why don't you just fire the incompetent slacker instead of slowing down the rest of your team?"
Because as the previous poster already stated, it is a corporation environment. You can hope on a short company to have above average developers, but on a big corporation you know your average whatever, (not only developer) will be, well, average, and then the clever thing is to manage for that. And then, that average worker's job is not dealing with the SCM but dealing with his part of code; if he does it well enough then is nothing but proper management practice to get out of his way anything else. Remember corporate burocracy is basically the art of dealing with mediocrity.
"Not sure how you get a "100+%" kill ratio by firing multiple missiles"
It's obvious: they will kill you *twice*.