Small companies love to believe that they're smarter than big companies but there's really no evidence that they are. The key technnical players in startups are usually chosen based on their relationship with the founder, not on an objective search for the best and brightest. No matter how smart you are, big complex legacy projects are always going to be much harder to do well than a small new project.
"The only way Microsoft has managed to hire so many people has been by lowering their hiring standards significantly."
Leave it to Joel to turn every issue into a hiring standards one. The problem was that too many people were involved in the project, not their quality. Joel likes to stroke his ego and promote his company by claiming he always hires the best people. This issue afforded him another excuse for self-promotion.
There were number of books that covered the same issues as "Reliable Software through Composite Design" and my appreciation of this issue originated from reading them. To certain degree we have a common frame of reference.
I don't agree, however, that Fowler's works are a logical extention of those principles. The fact that Fowler "allows" reversing refactorings doesn't seem like much of a concession. The goal should be to avoid doing additional work that you have to end up undoing later. Since refactoring by definition doesn't change functionality, "constant refactoring" can descend into constant self-indulgence.
I also don't agree that loops, functions, objects, etc were created to avoid "cut-and-paste". For example, loops go back at least as far as 1954 when FORTRAN was created. There was no such thing as "cut-and-paste" in those days, so that can't be the reason for creating looping capability. Also saving program space was at least as important a factor in adding language support of functions as were organizational considerations.
"I think that while pasting a few lines of code is normally harmless, it doesn't follow that a function that replaces a few lines of code, or even a fraction of a line of code, is automatically a bad thing."
I'm against any programming principle that says that anything is "automatically a bad thing". My post was a reaction to the recent movement in software development that tries to substitute absolute rules for good engineering judgement. I consider the "don't repeat yourself" rule to be an example.
I think the argument that the GPL denies people rights is a straw one. Of course the term "rights" gets a bit sticky when sometimes you base it on law and sometimes on personal belief. As a matter of law, the GPL doesn't deny anyone rights in the same sense that software patents don't deny anyone rights. They're both perfectly legal devices (unless a court decides otherwise).
The problem comes when you mix the two. The "free" software movement condemns some legal approaches as immoral while relying on another legal device (copyright) to make the GPL work.
I agree. I've seen startup companies go out of business trying to do things "the right way" when they could have survived by delivering a less internally elegant solution. Designing for extensibility and maintainability is all about paying more today so that you can save even more tommorow, but there has to be a tommorow for it to pay off.
Actually, it's not necessarily a function either. Functions should have a well-defined purpose beyond being just a collection of lines of code. The reason is that when functions aren't well defined they're less likely to be reusable. In addition, when they are created soley to satisfy the "don't repeat yourself" rule they often have to be refactored back to a non-function when the coincidence that caused the duplication of code disappears.
Despite the "constant refactoring" edict, refactoring is really a kind of maintenance optimization and like all optimizations it's problematic if you do it too early.
"even though GUI builders are evil, and one of the very reasons they are evil is they preclude even the simplest refactorings. The bulk of programmers seem to be happy about that."
The whole point of using a tool that generates boilerplate code is that you don't want to mess with it. Refactoring is really a means to enhance maintainability, it doesn't add much value for code you don't intend to modify.
In recent years the well-understood trade-off between gratuitous code repetition and gratuitous function/class creation has become one-sided in favor of the latter. One should avoid unnecessary code repetition but a few lines of code repeated in several places is not necessarily a class waiting to emerge.
"They couldn't find any relationship between innovation and the number of patents a corporation has."
Since IBM has the most patents, it's rather obvious isn't it. But seriously when did "innovation" become a synonym for "invention". Innovation is pretty easy to achieve, invention a lot harder.
Neither copyright law nor the GPL can trump patent law. If, for example, Red Hat were to produce a version of Red Hat Linux that contained offending code they would be in violation of the patent. It doesn't matter who wrote the code or who held the copyright, it's still a violation and Red Hat could be sued ( as well as its users).
I think that if interoperability between Linux and Windows fundamentally violates a MS patent, then there might be a problem, but I think it unlikely that either the MS team or the Novell team will have a lot of knowledge of specific patents as they do their work. So I think the danger would be about the same whether the work was done by Novell with MS's help or done by a third party working independently.
"If you think this is purely an emotional argument, then you have read the publicly released portions of the agreement. Or you haven't analyzed what actions could be taken on the basis of those agreements."
Nothing in the agreement obligates Novell to put patent-violating code in Linux, so what would Novell's motiviation be for doing it? So far I haven't seen anyone answer that question. The arguments seem to be more like "We're pissed at Novell for violating the spirit of the GPL, so we're going to punish them".
"IBM thinks its a good agreement"? This bothers me, and if the arguments presented made sense, then I'd re-think my position. "
Well, I wouldn't take advice from IBM either way, they don't have any idealistic ties to open source and will do whatever benefits them without regard to anyone else. IBM has done an excellent job marketing to the F/OSS community but don't confuse marketing with reality.
Actually, if the GPLv3 tools cut out Novell, Linus does have something to gain from forking the FSF tools. Significant icompatibilities between Novell and Red Hat will slow down Linux's adoption rate.
"Hundred of millions of line of code, with no spec, no design and no access to the original developers."
Eventually all the orginal developers will be dead no matter what license is used. As for having "no spec, no design" that's either already true of the current code or it's not. Is GNU planning on creating more documentation once they convert to GPLv3?
"More importantly, don't be surprised if Free Software projects start rejecting code from Novell engineers out of hand."
Well, if Novell has actually been making significant contributions, this will be a poor decision on the part of the free software projects that take that position unless there's some real reason to believe that Novell is going to deliberately put patent-infringing code in Linux.
Perhaps MS is relying on the F/OSS's communities emotional reaction to this issue to slow down future Linux development by rejecting significant contributions from "impure" companies like Novell.
Of course this could cut both ways. If Linus decided to fork the FSF stuff to keep it GPLv2, what impact would that have on the FSF? If there were incompatibilities between the Linux tools and the FSF tools, would most developers prefer having HURD compatibility or Linux compatibility?
Of course, Novell would be free to look at the GNU notices for the exploit fix, examine the code to determine the solution and write different code that does the same thing all without violating copyright. That's a lot less than "the full maintenance burden" you predict.
In the closed source world, the source for the fix would not be available so it would require significant reverse-engineering to figure out the changes (even if you were legally allowed to modify and redistribute the code). The open source model only protects against a simple "copy-and-paste" operation, it isn't designed to protect against more subtle "theft".
I think you expect behavior on the part of the SEC that is beyond their mission. The SEC isn't going to investigate and analyze what MS patents are or are not in Linux just as they didn't investigate any of the 500 patents that IBM offered to the open source community 2 years ago. That could be seen as exactly the same kind of market manipulation.
"76% percent of the country's electricity generated from safe, clean, and abundant nuclear power."
You put the words "safe" and "nuclear power" in the same sentence. That's an oxymoron.
Re:Your pattern suggests "mechanical thinking"
on
You Call This Agile?
·
· Score: 1
"To tie this in with the parent thread, I'll offer up the additional observation that one trait that good developers and good admins share is the itch to fix a broken system, whether it's a borked XML schema or a misconfigured router."
Good developers don't necessarily have an "itch to fix a broken system" but to design a system that isn't broken.
"You can't seem to make the connection that clearing paper jams is an application of the ability to perform failure analysis. If you can't analyze the failure mode of a fairly simple system, how well are you going to be able to perform a failure analysis on a complex one?"
There are all kinds of systems that can be analyzed: software systems, electrical systems, mechanical systems, biological systems etc. The ability to perform any particular one doesn't increase the probablity of being able to do the others and being unable to do one doesn't preclude being able to do the others. This is a common truth easy to observe in the real world (e.g. the brilliant doctor who can't operate a computer). If you don't believe it, fine.
Re:Your pattern suggests "mechanical thinking"
on
You Call This Agile?
·
· Score: 1
Gotta love that revisionist history:
"Developers who can't figure out how to clear a paper jam probably aren't going to be much help when their code won't deploy properly in production, either"
Remember the discussion wasn't about "important skills for developers", it was about the difference between the role of an Admin and a developer. It was you who first suggested a link between a copier and development skills, which you're now backing away from.
Slashdot Mirror
Small companies love to believe that they're smarter than big companies but there's really no evidence that they are. The key technnical players in startups are usually chosen based on their relationship with the founder, not on an objective search for the best and brightest. No matter how smart you are, big complex legacy projects are always going to be much harder to do well than a small new project.
"The only way Microsoft has managed to hire so many people has been by lowering their hiring standards significantly."
Leave it to Joel to turn every issue into a hiring standards one. The problem was that too many people were involved in the project, not their quality. Joel likes to stroke his ego and promote his company by claiming he always hires the best people. This issue afforded him another excuse for self-promotion.
There were number of books that covered the same issues as "Reliable Software through Composite Design" and my appreciation of this issue originated from reading them. To certain degree we have a common frame of reference.
I don't agree, however, that Fowler's works are a logical extention of those principles. The fact that Fowler "allows" reversing refactorings doesn't seem like much of a concession. The goal should be to avoid doing additional work that you have to end up undoing later. Since refactoring by definition doesn't change functionality, "constant refactoring" can descend into constant self-indulgence.
I also don't agree that loops, functions, objects, etc were created to avoid "cut-and-paste". For example, loops go back at least as far as 1954 when FORTRAN was created. There was no such thing as "cut-and-paste" in those days, so that can't be the reason for creating looping capability. Also saving program space was at least as important a factor in adding language support of functions as were organizational considerations.
"I think that while pasting a few lines of code is normally harmless, it doesn't follow that a function that replaces a few lines of code, or even a fraction of a line of code, is automatically a bad thing."
I'm against any programming principle that says that anything is "automatically a bad thing". My post was a reaction to the recent movement in software development that tries to substitute absolute rules for good engineering judgement. I consider the "don't repeat yourself" rule to be an example.
I think the argument that the GPL denies people rights is a straw one. Of course the term "rights" gets a bit sticky when sometimes you base it on law and sometimes on personal belief. As a matter of law, the GPL doesn't deny anyone rights in the same sense that software patents don't deny anyone rights. They're both perfectly legal devices (unless a court decides otherwise).
The problem comes when you mix the two. The "free" software movement condemns some legal approaches as immoral while relying on another legal device (copyright) to make the GPL work.
I agree. I've seen startup companies go out of business trying to do things "the right way" when they could have survived by delivering a less internally elegant solution. Designing for extensibility and maintainability is all about paying more today so that you can save even more tommorow, but there has to be a tommorow for it to pay off.
Actually, it's not necessarily a function either. Functions should have a well-defined purpose beyond being just a collection of lines of code. The reason is that when functions aren't well defined they're less likely to be reusable. In addition, when they are created soley to satisfy the "don't repeat yourself" rule they often have to be refactored back to a non-function when the coincidence that caused the duplication of code disappears.
Despite the "constant refactoring" edict, refactoring is really a kind of maintenance optimization and like all optimizations it's problematic if you do it too early.
"even though GUI builders are evil, and one of the very reasons they are evil is they preclude even the simplest refactorings. The bulk of programmers seem to be happy about that."
The whole point of using a tool that generates boilerplate code is that you don't want to mess with it. Refactoring is really a means to enhance maintainability, it doesn't add much value for code you don't intend to modify.
In recent years the well-understood trade-off between gratuitous code repetition and gratuitous function/class creation has become one-sided in favor of the latter. One should avoid unnecessary code repetition but a few lines of code repeated in several places is not necessarily a class waiting to emerge.
"They couldn't find any relationship between innovation and the number of patents a corporation has."
Since IBM has the most patents, it's rather obvious isn't it. But seriously when did "innovation" become a synonym for "invention". Innovation is pretty easy to achieve, invention a lot harder.
"But they've just bought insurance that allows them to do so without worrying about getting sued."
No. They've bought insurance against their customers being sued, that's quite different.
Neither copyright law nor the GPL can trump patent law. If, for example, Red Hat were to produce a version of Red Hat Linux that contained offending code they would be in violation of the patent. It doesn't matter who wrote the code or who held the copyright, it's still a violation and Red Hat could be sued ( as well as its users).
I think that if interoperability between Linux and Windows fundamentally violates a MS patent, then there might be a problem, but I think it unlikely that either the MS team or the Novell team will have a lot of knowledge of specific patents as they do their work. So I think the danger would be about the same whether the work was done by Novell with MS's help or done by a third party working independently.
"If you think this is purely an emotional argument, then you have read the publicly released portions of the agreement. Or you haven't analyzed what actions could be taken on the basis of those agreements."
Nothing in the agreement obligates Novell to put patent-violating code in Linux, so what would Novell's motiviation be for doing it? So far I haven't seen anyone answer that question. The arguments seem to be more like "We're pissed at Novell for violating the spirit of the GPL, so we're going to punish them".
"IBM thinks its a good agreement"? This bothers me, and if the arguments presented made sense, then I'd re-think my position. "
Well, I wouldn't take advice from IBM either way, they don't have any idealistic ties to open source and will do whatever benefits them without regard to anyone else. IBM has done an excellent job marketing to the F/OSS community but don't confuse marketing with reality.
Actually, if the GPLv3 tools cut out Novell, Linus does have something to gain from forking the FSF tools. Significant icompatibilities between Novell and Red Hat will slow down Linux's adoption rate.
"Hundred of millions of line of code, with no spec, no design and no access to the original developers."
Eventually all the orginal developers will be dead no matter what license is used. As for having "no spec, no design" that's either already true of the current code or it's not. Is GNU planning on creating more documentation once they convert to GPLv3?
"More importantly, don't be surprised if Free Software projects start rejecting code from Novell engineers out of hand."
Well, if Novell has actually been making significant contributions, this will be a poor decision on the part of the free software projects that take that position unless there's some real reason to believe that Novell is going to deliberately put patent-infringing code in Linux.
Perhaps MS is relying on the F/OSS's communities emotional reaction to this issue to slow down future Linux development by rejecting significant contributions from "impure" companies like Novell.
I guess that's true for applications written by by poor developers who rely on the internal implementation of libraries.
Of course this could cut both ways. If Linus decided to fork the FSF stuff to keep it GPLv2, what impact would that have on the FSF? If there were incompatibilities between the Linux tools and the FSF tools, would most developers prefer having HURD compatibility or Linux compatibility?
Of course, Novell would be free to look at the GNU notices for the exploit fix, examine the code to determine the solution and write different code that does the same thing all without violating copyright. That's a lot less than "the full maintenance burden" you predict.
In the closed source world, the source for the fix would not be available so it would require significant reverse-engineering to figure out the changes (even if you were legally allowed to modify and redistribute the code). The open source model only protects against a simple "copy-and-paste" operation, it isn't designed to protect against more subtle "theft".
The issue is nuclear waste.
I think you expect behavior on the part of the SEC that is beyond their mission. The SEC isn't going to investigate and analyze what MS patents are or are not in Linux just as they didn't investigate any of the 500 patents that IBM offered to the open source community 2 years ago. That could be seen as exactly the same kind of market manipulation.
"76% percent of the country's electricity generated from safe, clean, and abundant nuclear power."
You put the words "safe" and "nuclear power" in the same sentence. That's an oxymoron.
"To tie this in with the parent thread, I'll offer up the additional observation that one trait that good developers and good admins share is the itch to fix a broken system, whether it's a borked XML schema or a misconfigured router."
Good developers don't necessarily have an "itch to fix a broken system" but to design a system that isn't broken.
"You can't seem to make the connection that clearing paper jams is an application of the ability to perform failure analysis. If you can't analyze the failure mode of a fairly simple system, how well are you going to be able to perform a failure analysis on a complex one?"
There are all kinds of systems that can be analyzed: software systems, electrical systems, mechanical systems, biological systems etc. The ability to perform any particular one doesn't increase the probablity of being able to do the others and being unable to do one doesn't preclude being able to do the others. This is a common truth easy to observe in the real world (e.g. the brilliant doctor who can't operate a computer). If you don't believe it, fine.
Gotta love that revisionist history:
"Developers who can't figure out how to clear a paper jam probably aren't going to be much help when their code won't deploy properly in production, either"
Remember the discussion wasn't about "important skills for developers", it was about the difference between the role of an Admin and a developer. It was you who first suggested a link between a copier and development skills, which you're now backing away from.