Motivation of software professionals
in [JavaScript]
|
Prev: When writing html table to div, the data from table is unformatted
Next: multi file download with one click
From: LR on 14 Feb 2010 11:25 Seebs wrote: > On 2010-02-13, Leif Roar Moldskred <leifm(a)huldreheim.homelinux.org> wrote: >> Why? We're not today, and the gears of the open source engine appears fairly >> well greased regardless. > > In practice we are -- you can give stuff away labeled "WITHOUT ANY WARRANTY" > and no one seems to feel this is a problem. > > The proposal that we should legislate that software CANNOT be distributed > without warranty would be destructive. There are also IMO free speech issues. Can a teacher publish code in, eg a text book, without incurring liability? (The tangentially related (IMO free speech) issue of who may teach is also important, although I think some states may claim the right to limit the teaching of engineering to PEs, in Sweezy v. New Hampshire, 354 U.S. 234 (1957) in his concurring opionion Justice Frankfurter quoted: `the four essential freedoms' of a university - to determine for itself on academic grounds who may teach, what may be taught, how it shall be taught, and who may be admitted to study." http://caselaw.lp.findlaw.com/scripts/getcase.pl?court=US&vol=354&invol=234) If code may result in liability what about tools like c2eng that I think resulted from litigation related to DeCSS. http://www.mit.edu/~ocschwar/c2eng.html Is the English form protected speech? Subject to liability? I haven't read through the whole thing but this looks interesting http://www.cs.cmu.edu/~dst/DeCSS/Baccash/thesis.pdf LR
From: Seebs on 14 Feb 2010 11:45 On 2010-02-14, James Kanze <james.kanze(a)gmail.com> wrote: > Really. I've not seen any free software which adopted all of > the best practices. Bespoke software may. But go to a store that sells discs in boxes, and tell me with a straight face that any of those boxes contain software developed through a development operation which adpoted all of the best practices. > In my experience, some of the best > practices require physical presense, with all of the developers > having offices in the same building. (The experiments I've seen > replacing this with email and chat haven't turned out all that > well.) This is far more difficult for a free project to achieve > than for a commercial one. True. That said, I've been on distributed teams pretty much exclusively for the last couple of decades, and I think they certainly *can* work. It depends a lot on building a culture that's suited to it, and probably also on having a few aspies involved. (It is nearly always the case that I am less efficient in face-to-face meetings than I am in pure-text chat.) > First, free software doesn't have the highest quality. When > quality is really, really important (in critical systems), you > won't see any free software. I'm not totally sure of this. Not *much* free software, probably. It'd be interesting to see, though. Last I heard, there's no open source pacemakers, but there are pacemaker programmers which are built on open source platforms, because that's enough less critical. (This is third-hand, so no citations.) > ClearCase uses a different model than any of the other version > management tools I've used. In particular, the model is > designed for large projects in a well run shop---if your > organization isn't up to par, or if your projects are basically > small (just a couple of people, say up to five), ClearCase is > overkill, and probably not appropriate. If you're managing a > project with five or six teams of four or five people each, each > one working on different (but dependent) parts of the project, > and you're managing things correctly, the ClearCase model beats > the others hands down. Hmm. I'm not familiar with its model, but we've used git in that environment and loved it. That said, we can't see the model for the interface, which is pretty weak. > Did you actually try using any free software back in the early > 1990's? I did. NetBSD was for the most part reliable and bulletproof during that time; it ran rings around several commercial Unixes. I had no interest in g++; so far as I could tell, at that time, "a C++ compiler" was intrinsically unusable. But gcc was stable enough to build systems that worked reliably, and the BSD kernel and userspace were pretty livable. > Neither Linux nor g++ were even usable, and emacs (by > far the highest quality free software), it was touch and go, and > depended on the version. Back then, the free software community > was very much a lot of hackers, doing whatever they felt like, > with no control. Whereas all of the successful free software > projects today have some sort of central management, ensuring > certain minimum standards. I have no idea what you're talking about. I cannot point to any point in the history of my exposure to free software (which predates the 1990s) at which any major project had no central management. Linux was pretty flaky early on, but then, in the early 1990s, all it had to do was be more stable than Windows 3.1, which was not a high bar to reach for. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Seebs on 14 Feb 2010 11:50 On 2010-02-14, James Kanze <james.kanze(a)gmail.com> wrote: > On Feb 13, 4:27 pm, Seebs <usenet-nos...(a)seebs.net> wrote: >> It's also often written by particularly good developers, who >> care about their code. > That I don't believe. I've seen a lot of particularly good > developers in industry as well. People who care about their > code---in fact, one of the most important things in creating a > good process is to get people to care about their code. I don't see how that argues against free software being written, in some or many cases, by "particularly good developers, who care about their code." > In a well run development process, such feedback is guaranteed, > not just "expected". That's what code reviews are for. True. But of commercial places I've worked, only a few have been anywhere near as active in code reviews as the free software projects I've worked with. I have not yet seen a free software project which wouldn't reject code purely on the basis that it had poor style or didn't match coding standards. I have seen several commercial projects which didn't. So while good commercial places may be that good, I've seen nothing to suggest that free software places aren't usually that good. > I'm far from sure about the "often", and I have serious doubts > about "hundreds"---you don't want hundreds of cooks spoiling the > broth---but that's more or less the case for the best run > freeware projects. Which is no different from the best run > commercial organizations, with the difference that the > commercial organization has more power to enforce the rules it > sets. And more incentive to cheat around the edges. This is the essential flaw of corporations. > ClearCase is by far the best version management system for > large, well run projects. It's a bit overkill for smaller > things, and it causes no end of problems if the project isn't > correctly managed (but what doesn't), but for any project over > about five or six people, I'd rather use ClearCase than anything > else. Fascinating. Again, not what I've heard -- but to be fair, I've had no call to use it. > That is, of course, a weakness of free software. I don't think it's a weakness in free software; I think it's a weakness in a liability model. The ability to modify code when it doesn't quite suit is a huge advantage. If we were dependent on reporting bugs to vendors and waiting for their fixes for everything we use, it would be a disaster. We put up with it, for one hunk of code, because the cost of maintaining local expertise would be prohibitive. Apart from that, no. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Lew on 14 Feb 2010 11:54 James Kanze wrote: >> Did you actually try using any free software back in the early >> 1990's [sic]? Seebs wrote: > I did. Same here. > NetBSD was for the most part reliable and bulletproof during that time; > it ran rings around several commercial Unixes. I had no interest in g++; > so far as I could tell, at that time, "a C++ compiler" was intrinsically > unusable. But gcc was stable enough to build systems that worked reliably, > and the BSD kernel and userspace were pretty livable. James Kanze wrote: >> Neither Linux nor g++ were even usable, and emacs (by That's pure fantasy. I used a couple of Linux distributions in the early nineties, and they worked better than commercial UNIX variants. I used emacs and knew many who used vi back then. They were solid. I used gcc by the mid-90s and it was rock solid, too. I used free software even as far back as the late 80s that worked beautifully. The facts to back up your assertions are not in evidence. >> far the highest quality free software), it was touch and go, and >> depended on the version. Back then, the free software community >> was very much a lot of hackers, doing whatever they felt like, >> with no control. Whereas all of the successful free software >> projects today have some sort of central management, ensuring >> certain minimum standards. Seebs wrote: > I have no idea what you're talking about. I cannot point to any point > in the history of my exposure to free software (which predates the 1990s) > at which any major project had no central management. Linux was pretty > flaky early on, but then, in the early 1990s, all it had to do was be > more stable than Windows 3.1, which was not a high bar to reach for. -- Lew
From: Seebs on 14 Feb 2010 11:56
On 2010-02-14, James Kanze <james.kanze(a)gmail.com> wrote: > To be really effective, design and code review requires a > physical meeting. Depending on the organization of the project, > such physical meetings are more or less difficult. Nonsense. > Code review is *not* just some other programmer happening to > read your code by chance, and making some random comments on > it. Code review involves discussion. Discussion works best > face to face. IMHO, this is not generally true. Of course, I'm autistic, so I'd naturally think that. But I've been watching a lot of code reviews (our review process has named reviewers, but also has reviews floating about on a list in case anyone else sees something of interest, which occasionally catches stuff). And what I've seen is that a whole lot of review depends on being able to spend an hour or two studying something, or possibly longer, and write detailed analysis -- and that kind of thing is HEAVILY discouraged for most people by a face-to-face meeting, because they can't handle dead air. Certainly, discussion is essential to an effective review. But discussion without the benefit of the ability to spend substantial time structuring and organizing your thoughts will feel more effective but actually be less effective, because you're substituting primate instincts for reasoned analysis. I really don't think that one can be beaten. If what you need for a code review is for someone to spend hours (or possibly days) studying some code and writing up comments, then trying to do it in a face-to-face meeting would be crippling. Once you've got the comments, you could probably do them face-to-face, but again, that denies you the time to think over what you've been told, check it carefully, and so on. You want a medium where words sit there untouched by the vagaries of memory so you can go back over them. But! You do need people who are willing and able to have real discussions via text media. That's a learned skill, and not everyone's learned it. It is not universally true that discussion "works best face to face". Certainly, there are kinds of discussions which benefit heavily from face-to-face exposure. There are other kinds which are harmed greatly by it. Perhaps most importantly, many of the kinds which are harmed greatly by it *FEEL* much better face-to-face, even though they're actually working less well. The curse of being made out of meat is that your body and brain lie to you. Knowing about this is the first step to overcoming the harmful side effects. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! |