removing features from your roadmap and shipping betas isn't how you "complete" a piece of software
You are right. This is how a release gets completed.
To be honest, I've never known any software to become complete.
The reasons for paring down a release are many, varied, often controversial and equally often necessary. Releasing without "everything" means that customers who are waiting for the things that are done can get them. It also means that there is a new round of revenue that can be realized.
nothing we have ever done at Fog Creek has increased our revenue more than releasing a new version with more features
To be able to release a version with new features means not "completing" the software for the current release.
There is a grey area between making good software engineering (and business) decisions vs. purposely manipulating the market in order to yield extract extra revenue. In the first case, you expect to keep a solid and viable company alive, keeping most customers happy while absorbing the criticism of those you have not been able to service completely with the current release. In the latter case, hopefully market forces (and human nature) will bring the rogue software vendor inline or put them out of business (unless they happen to have billions in the bank and a name that no one gets fired for purchasing products of...).
they expected you to spend TWO HOURS working for them without compensation
I don't think that writing a "directory listing tool" is exactly "working for them". It isn't like they were going places with my code (though I guess they could have...I didn't make them sign an NDA or anything). If a company can truly take off because of the two hours I spent at a keyboard...I wouldn't want any part of them.
But in all honesty, now that I'm interviewing 2 hours is a minimum amount expected for people we're looking to hire full time. We're a smallish company (new startup) and cannot afford to bring on people who either lack skills or who can't play nicely with others. I've moved away from coding tests to a generic pseudo-code written test (some coding questions, some problem-solving questions). That test takes anywhere from 1.5 hours to 4 hours to complete.
I don't think that having someone show that they can do some work during an interview, compensation-less, is a problem. If they aren't willing to show that they have the capabilities and desire...why exactly would I want to hire them.
On the flip side, if they didn't see the kinds of things we're thinking about and asking about, how would they know whether or not to take the chance on us?
There's no way that a prospective employer can reasonably expect to be able to look at your current production code
I agree about the "production code" aspect, but I've asked to see what code someone has done on their own, no matter what it is, just to see that they are interested in code outside of 9 - 5. Heck, most of us have some kind of pet project kicking around...even a home website in PHP or something. It may not be "production", but if the person is a professional coder I'd expect it to at least be somewhat cleanly done.
If they submit your typical "hello world" or nothing at all, then I've got some insight to their engrossment to the art/science...or at least I've got a talking point.
One of the better interviews I've had was for a Unix coding job. They sat me at an X terminal logged into a "guest" account and told me to write a simple directory listing program and that they'd be back in two hours.
That was it. No other direction, no manuals. Ah, yes, there was "man"...but the $MANPATH was bare-bones and the guest account had extremely limited access to anything besides/usr/* and/home/guest. On top of that, the only editor that worked was "ed" (vi couldn't handle the term I was running in) and "cc test.c" threw a whack of errors [though I could fix it by tweaking $INCLUDE]
After 5 minutes of mucking around, I left the interview room to track down my interviewer to ask for some tweaked permissions. That was win #1; apparently only 20% of interviewees came foreward before trying some type of coding, and even then most didn't know what exactly to ask for in terms of help.
Once I was able to "man opendir", they left me alone for another 45 minutes then cut me off because they'd seen enough (watching the files from another account).
Now, mind you, this was for a junior position so they weren't looking for much in the way of overall code structure, etc. They were more after whether the interviewer knew what Unix was about and if they would take the initiative to overcome some obstacles.
Today, it seems that "archiving [sic] goals by lowering expectations" is the norm among application developers... dumping down languages to avoid features that might burn developers.
When you say "today", what are you comparing it to? When was the glorious time that software projects were simple enough, and well enough defined at the outset, that all targets were all met consistently and successfully?
Have you been watching Lou Dobbs too much of late? The nature of the world is not significantly different today from "the good old days". Crime is not on a dramatic rise, immigration has been steady, corporations are just as money focused as always, politicians equally so.
In the vast majority of software products, applications developers do not have the say when it comes to "lowering expectations". That is the role of the product manager. And even then, it is more often than not a miscalculation on the part of the product manager that causes features to slip (improperly defined features, changing timelines, scope creep, changing priorities, etc...).
Languages are nothing but tools. The right tool for the right job. A language is not an excuse for bad software development practices. And Java, as a language, is a great tool for many, many jobs. It isn't used by people so they can "lower expectations", so that they can under-deliver, so that they can avoid responsibility...in fact, just the opposite.
Destroying them does not magically bring that money back; in fact, it only costs more!
But likely nowhere near as much as the potential lawsuits from vehicle owners a few years down the road (class-action at that!).
Or the potential of the immeasurable bad reputation they could get if these cars started exploding or driving off on their own or whatever ("Pinto", "Pacer", "Nova",...).
Yes, there was a measurable cost in destroying those cars, but I bet that lawyers and accountants would have argued that the potential liability of letting them stay on the road greatly outweighed the cost of a few days rental of a crusher.
But many people prefer the tinfoil hat view, and I don't completely dismiss it either. I just don't believe that any corporation would give up the opportunity of taking vasts sums money from anywhere unless they saw the potential cost of taking that money as being too high.
What I'm suggesting is that constantly dipping into the resource of open-source goodwill without returning anything at all will eventually deplete the pool.
You are confusing a few concepts w.r.t. the EV1. It's discontinuation was precisely because of lack of consumer demand. The fact that they destroyed the few vehicles that were already created does not change the fact that there was next-to-no demand for them.
And I have seen the movie...very convincing for a one-sided argument...however it could be argued that GM's destruction of those vehicles was a sound business move. Maybe they felt that the technology was decent but they as a company couldn't figure out how to effectively market and sell the machines; they would be concerned that someone else could figure it out.
There's also the angle (GM's "official" stance), that as the EV1's deteriorated over time, without replacement parts (remember, there was no demand for making the machines, so there'd be no market for replacement parts) then the EV1's could become a serious liability.
On top of all of this, the lack of need for servicing (assuming the EV1's really were as good as the movie claims) takes away a serious revenue source from GM (service and maintenance), so killing the EV1 again could be considered a sound business move...if consumers really wanted the machines, they'd have been willing to pay the real price.
But what consumers want is cheap, low-cost, best deal; Wal-mart, McD's, Ford/GM/Chrysler, third-world production facilities give them exactly that. A few hundred (or a few thousand) individuals do not comprise "consumers". For any of these large corporations, thousands of consumers is not worth the effort of developing a pilot product, much less bring an entire product to market.
Obligation does not need to be a legal entity. There is the whole concept of community participation.
Let's say there was a resource that was available in HUGE amounts, was free, and no one was obliged to conserve, reduce or become more efficient in use of that resource. If all of the large users of that resource continued to use this "free" resource, eventually it will begin to deplete or become of poorer quality or possibly become something where only for-purchase alternatives are desirable....err...wait a sec....
Lessee, GM's on the list (see "Who Killed the Electic Car") along with the obvious Microsoft, SCO, Walmart, etc
So you are against companies that give consumers exactly what they want?
That kill products that aren't selling?
Boards that do what (they believe) their investor base is demanding?
Don't get me wrong, I'm not a big fan of those on your list...however they are big targets exactly because consumers support them (or don't, in the case of layoffs and the "electric car").
slamming on Oracle seems a little silly. Its software, there will be problems.
I agree with the first sentence, I completely disagree with the second.
Focusing just on one vendor does seem sort of school-yard-teasing childish. It would be nice if they had a better description than "they are the #1 star."
But the fact that software has problems does not mean that those issues shouldn't be addressed. And if public embarrassment is required to force a vendor's hand, so be it (though I'm not saying that it is the case with this vendor...but I wouldn't be overly surprised...).
What's wrong with going round to someone's house and asking if someone can out to play, as I did when I was a kid?
Just suppose for a minute that you had had a webcam as a kid (and associated high-speed connectivity, etc...). D'you think you'd have used them?
I encourage my children to take advantage of the technologies we have. I want them to be as advanced as they want to become. But, as with everything we expose them to, we do it in moderation.
O'Reilly's an idiot. At best, his argument is "if you do something too much, you live your life out of balance". That's ingenious...such insight!
Since the GPL forces everybody to publish the source code to their improvements under the same GPL
The GPL talks about distribute, not publish. Forks may exist if the users of the derived works does not decide to redistribute the resultant themselves.
And forks will still have their place. If there is a change that someone wants to introduce (e.g. pointers) that the rest of the community does not agree with, then that fork's mods will not get integrated. Eventually you have two separate products, most likely competing. It is then up to the user/developer community to decide which one(s) survive.
if the forker abides by the GPL he has to publish his code for the forks
This is incorrect.
The forker only needs to make their code available to whomever they distributes the resultant. There is no requirement for "publishing", no requirement to make changes available to anyone other than the recipient of the derivative work.
...and, as others have pointed out, how we can tell that what is downloaded is really from BBV? The linked domain blackbox1.org is not the same as blackboxvoting.org.
Uh...I think that Novell has been here a few times before...and they are still around.
I'm sure that Novell has a bit of a clue as to what they are doing. I'm sure they recognize the flame with which they play...
I'm not implying that they can't get burned, but I suspect they realize that they can get burned. They obviously see potential benefit here that (they believe) justifies the risks.
Though I agree that it may make some IT folks grumble, grumble a bit...I can't help but think that Visa (et al.) management (and marketing) would be thrilled that their system is being used as a hook into having people spend more money online.
If their system was used for registration of, say, a Slashdot account where there was no financial benefit to them, I could see them being upset. But anyone with a modicum of business savvy should recognize this system as having huge potential. In fact, it might be worth them spending a bit of effort to help build support for just this kind of activity.
At least, that's the way I'd view it. But I also think that many "good netizen" approaches make good business sense...
Slashdot Mirror
To be honest, I've never known any software to become complete.
The reasons for paring down a release are many, varied, often controversial and equally often necessary. Releasing without "everything" means that customers who are waiting for the things that are done can get them. It also means that there is a new round of revenue that can be realized.
To quote Joel On Software:
To be able to release a version with new features means not "completing" the software for the current release.
There is a grey area between making good software engineering (and business) decisions vs. purposely manipulating the market in order to yield extract extra revenue. In the first case, you expect to keep a solid and viable company alive, keeping most customers happy while absorbing the criticism of those you have not been able to service completely with the current release. In the latter case, hopefully market forces (and human nature) will bring the rogue software vendor inline or put them out of business (unless they happen to have billions in the bank and a name that no one gets fired for purchasing products of...).
But in all honesty, now that I'm interviewing 2 hours is a minimum amount expected for people we're looking to hire full time. We're a smallish company (new startup) and cannot afford to bring on people who either lack skills or who can't play nicely with others. I've moved away from coding tests to a generic pseudo-code written test (some coding questions, some problem-solving questions). That test takes anywhere from 1.5 hours to 4 hours to complete.
I don't think that having someone show that they can do some work during an interview, compensation-less, is a problem. If they aren't willing to show that they have the capabilities and desire...why exactly would I want to hire them.
On the flip side, if they didn't see the kinds of things we're thinking about and asking about, how would they know whether or not to take the chance on us?
If they submit your typical "hello world" or nothing at all, then I've got some insight to their engrossment to the art/science...or at least I've got a talking point.
That was it. No other direction, no manuals. Ah, yes, there was "man"...but the $MANPATH was bare-bones and the guest account had extremely limited access to anything besides /usr/* and /home/guest. On top of that, the only editor that worked was "ed" (vi couldn't handle the term I was running in) and "cc test.c" threw a whack of errors [though I could fix it by tweaking $INCLUDE]
After 5 minutes of mucking around, I left the interview room to track down my interviewer to ask for some tweaked permissions. That was win #1; apparently only 20% of interviewees came foreward before trying some type of coding, and even then most didn't know what exactly to ask for in terms of help.
Once I was able to "man opendir", they left me alone for another 45 minutes then cut me off because they'd seen enough (watching the files from another account).
Now, mind you, this was for a junior position so they weren't looking for much in the way of overall code structure, etc. They were more after whether the interviewer knew what Unix was about and if they would take the initiative to overcome some obstacles.
Yes, I truly wish that the U.S.ians would get with the programme.
Have you been watching Lou Dobbs too much of late? The nature of the world is not significantly different today from "the good old days". Crime is not on a dramatic rise, immigration has been steady, corporations are just as money focused as always, politicians equally so.
In the vast majority of software products, applications developers do not have the say when it comes to "lowering expectations". That is the role of the product manager. And even then, it is more often than not a miscalculation on the part of the product manager that causes features to slip (improperly defined features, changing timelines, scope creep, changing priorities, etc...).
Languages are nothing but tools. The right tool for the right job. A language is not an excuse for bad software development practices. And Java, as a language, is a great tool for many, many jobs. It isn't used by people so they can "lower expectations", so that they can under-deliver, so that they can avoid responsibility...in fact, just the opposite.
But likely nowhere near as much as the potential lawsuits from vehicle owners a few years down the road (class-action at that!).
Or the potential of the immeasurable bad reputation they could get if these cars started exploding or driving off on their own or whatever ("Pinto", "Pacer", "Nova", ...).
Yes, there was a measurable cost in destroying those cars, but I bet that lawyers and accountants would have argued that the potential liability of letting them stay on the road greatly outweighed the cost of a few days rental of a crusher.
But many people prefer the tinfoil hat view, and I don't completely dismiss it either. I just don't believe that any corporation would give up the opportunity of taking vasts sums money from anywhere unless they saw the potential cost of taking that money as being too high.
What I'm suggesting is that constantly dipping into the resource of open-source goodwill without returning anything at all will eventually deplete the pool.
And I have seen the movie...very convincing for a one-sided argument...however it could be argued that GM's destruction of those vehicles was a sound business move. Maybe they felt that the technology was decent but they as a company couldn't figure out how to effectively market and sell the machines; they would be concerned that someone else could figure it out.
There's also the angle (GM's "official" stance), that as the EV1's deteriorated over time, without replacement parts (remember, there was no demand for making the machines, so there'd be no market for replacement parts) then the EV1's could become a serious liability.
On top of all of this, the lack of need for servicing (assuming the EV1's really were as good as the movie claims) takes away a serious revenue source from GM (service and maintenance), so killing the EV1 again could be considered a sound business move...if consumers really wanted the machines, they'd have been willing to pay the real price.
But what consumers want is cheap, low-cost, best deal; Wal-mart, McD's, Ford/GM/Chrysler, third-world production facilities give them exactly that. A few hundred (or a few thousand) individuals do not comprise "consumers". For any of these large corporations, thousands of consumers is not worth the effort of developing a pilot product, much less bring an entire product to market.
Let's say there was a resource that was available in HUGE amounts, was free, and no one was obliged to conserve, reduce or become more efficient in use of that resource. If all of the large users of that resource continued to use this "free" resource, eventually it will begin to deplete or become of poorer quality or possibly become something where only for-purchase alternatives are desirable....err...wait a sec....
That kill products that aren't selling?
Boards that do what (they believe) their investor base is demanding?
Don't get me wrong, I'm not a big fan of those on your list...however they are big targets exactly because consumers support them (or don't, in the case of layoffs and the "electric car").
And thus the advent of tripwire. At best the hacker could disable tripwire, but then the (savvy) admin would notice the lack of tripwire reports.
Focusing just on one vendor does seem sort of school-yard-teasing childish. It would be nice if they had a better description than "they are the #1 star."
But the fact that software has problems does not mean that those issues shouldn't be addressed. And if public embarrassment is required to force a vendor's hand, so be it (though I'm not saying that it is the case with this vendor...but I wouldn't be overly surprised...).
I encourage my children to take advantage of the technologies we have. I want them to be as advanced as they want to become. But, as with everything we expose them to, we do it in moderation.
O'Reilly's an idiot. At best, his argument is "if you do something too much, you live your life out of balance". That's ingenious...such insight!
Uh...isn't the point to moving to XML that it be interoperable...easier to get access to the data and do good things? Standard text file and all that?
Oh, wait...MS-Standard Text File...
The GPL talks about distribute, not publish. Forks may exist if the users of the derived works does not decide to redistribute the resultant themselves.
And forks will still have their place. If there is a change that someone wants to introduce (e.g. pointers) that the rest of the community does not agree with, then that fork's mods will not get integrated. Eventually you have two separate products, most likely competing. It is then up to the user/developer community to decide which one(s) survive.
This is incorrect.
The forker only needs to make their code available to whomever they distributes the resultant. There is no requirement for "publishing", no requirement to make changes available to anyone other than the recipient of the derivative work.
...and, as others have pointed out, how we can tell that what is downloaded is really from BBV? The linked domain blackbox1.org is not the same as blackboxvoting.org .
I'm sure that Novell has a bit of a clue as to what they are doing. I'm sure they recognize the flame with which they play...
I'm not implying that they can't get burned, but I suspect they realize that they can get burned. They obviously see potential benefit here that (they believe) justifies the risks.
If their system was used for registration of, say, a Slashdot account where there was no financial benefit to them, I could see them being upset. But anyone with a modicum of business savvy should recognize this system as having huge potential. In fact, it might be worth them spending a bit of effort to help build support for just this kind of activity.
At least, that's the way I'd view it. But I also think that many "good netizen" approaches make good business sense...