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: James Kanze on 14 Feb 2010 07:46 On Feb 13, 3:09 pm, Lew <l...(a)lewscanon.com> wrote: > James Kanze wrote: > > Logically, I think that most of the techniques necessary for > > making really high quality software would be difficult to > > apply in the context of a free development. And at least up > > to a > Nonsense. Free software has a much higher rate of adoption of > best practices for high quality than for-pay software does. Really. I've not seen any free software which adopted 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. > You say so, too. What I said is that apparently, many commercial shops don't take advantage of their advantages. For example, one of the key factors in developing high quality software is communication. And communication is, or should be, easier when everyone works in the same plant. Never the less, one continually hears stories about lack of communication in such cases; about internal competition even leading to misinformation. The potential in a commercial organization is higher, but it's clear that many such organizations aren't using it (and that a few free projects are using everything they can). > It's the "logically" with which I take issue. That free > software uses the best techniques and has the highest quality > in the marketplace is entirely logical, in addition to being > an observed fact. You just have to avoid false assumptions > and fallacies in reasoning. 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 certain that no free software project is certified at SEI level 5, and from what I've seen, very few reach SEI level 2. Some commercial organizations (one or two) are certified at SEI level 5, and I've worked for some that were around level 3. Most of the ones selling the software we usually use (e.g. Microsoft, Sun, etc.) are still at level 1, however. > > point, they actually reduce the cost of development. So > > theoretically, the quality of commercial software should be > > considerably higher than that of free software. Practically, > > when I actually check things out... g++ is one of the better C++ > > compilers available, better than Sun CC or VC++, for example. > > Valgrind is at least as good as any of the commercial memory > > checkers under Linux. And Subversion is at least as good as any > > of the version management tools, excepted ClearCase (and the two > > really address different models of development). > ClearCase is an unwieldy pig. You hold that up as an example of high > quality? 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. My statement wasn't really clear, however: it's the ClearCase model which makes it the best choice in such cases, not the quality of the software. I've no reason to belive that ClearCase is developed using a better methodology than anything else. > Admittedly, it's better than a lot of other version-control > products, but not nearly as good as the free ones. As one of the free ones, in terms of quality, perhaps. The model is different, so it's very difficult to compare. In cases where the ClearCase model is preferrable, ClearCase is stable enough that you're better off using it than something supporting a different model. > > There used to be a lot less free stuff available, and it was > > worse. (It doesn't make sense to me, either, but those are > > the facts.) > No, they're not the facts. Since the beginning of free > software, much of it has been very high quality. I doubt very > much that the ratios have changed much, or if they have, > perhaps you could substantiate your "facts". Did you actually try using any free software back in the early 1990's? 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 don't dispute that there used to be a lot less free > software, insofar as there used to be a lot less software of > any description. It's your undefined use of "worse" without > evidence that I dispute. I was there. For the most part, free software was a joke. > > I think that part of the problem is that a mistake in a > > program will affect every instance of the program. Most > > recalls for cars, on the other hand, only affect a small > > subset of the total production. > A mistake in a car model enough to effect a recall affects > every instance of that model. Bugs in software, OTOH, affect > only a small subset of the total production of software. I'll admit that that paragraph is just speculation on my part. And it's speculation with regards to the motivation for not providing guarantees: the real issues are far more complex. > You haven't been paying much attention to the news lately, > have you? The percentage of Toyota's production which is affected is considerably smaller than what would happen if Microsoft were required to recall Windows. On the other hand, of course, software allows user installable patches (what Microsoft does when there is a critical bug), where as with a car, you generally have to bring it into the shop, at much greater cost to the manufacturer (and to you). -- James Kanze
From: Malcolm McLean on 14 Feb 2010 07:48 On Feb 14, 2:17 pm, James Kanze <james.ka...(a)gmail.com> wrote: > >The problem isn't the competence of >the practitioners (which is the problem certification >addresses), but the organizations in which they work. > Also the problem itself. It is impossible to test MiniBasic on all possible different paths all possible scripts could take it through, for example. (I wrote little test scripts to test each statement individually when developing it). On the other hand a game like "Defender" has a very limited set of user inputs.
From: James Kanze on 14 Feb 2010 07:54 On Feb 14, 12:23 am, Öö Tiib <oot...(a)hot.ee> wrote: > On Feb 13, 5:09 pm, Lew <l...(a)lewscanon.com> wrote: > > James Kanze wrote: > > > Logically, I think that most of the techniques necessary > > > for making really high quality software would be difficult > > > to apply in the context of a free development. And at > > > least up to a > > Nonsense. Free software has a much higher rate of adoption > > of best practices for high quality than for-pay software > > does. > > You say so, too. It's the "logically" with which I take > > issue. That free software uses the best techniques and has > > the highest quality in the marketplace is entirely logical, > > in addition to being an observed fact. You just have to > > avoid false assumptions and fallacies in reasoning. > Not sure what you mean. There are no such logical binary > connection. Opposite is as easy to observe. > Just download few C++ code-bases at random from places like > sourceforge.net and review them. I'm not sure that that's significant. It's less expensive to publish free software, so you get a lot of idiots doing it. But these are mostly products that no one is interested in. And there are actually quite a few start-up companies which do exactly the same thing. The difference is that the start-up company will go out of business, and disappear, where as the code on SourceForge just sits there. If you're talking about successful projects, there are some good free ones. > One produced by using good techniques is really hard to find > there. Most code there has quality so low that it would be > unthinkable in professional software house to pass QA peer > review with it. I've had the chance of working mostly in well run shops, but I've seen places where there was no peer review. Not all commercial shops are better. > It is easy to logically explain since most of it is hobby of > non-professionals who find software development amusing or > professionals of other language who learn C++ as hobby. > Results are slightly better with larger and more popular open > source products but that is often thanks to huge tester and > developer base and not good techniques used. At least some of the larger open source projects have a steering committee, and do practice at least some sort of code review and regression testing. > In best shape are open source projects that are popular and > where commercial companies are actively participating since > they need these for building or supporting their commercial > products. Again it is easy to see how the companies are > actually enforcing the techniques and quality there and it is > likely that the companies use even higher standards in-house. > Worst what i have seen is the code written by in-house > software department of some smaller non-software companies but > that is again easy to explain by workers of that department > obfuscating their work to gain job security. > So all things have logical explanations and there are no silly > binary connections like free = quality and commercial = lack > of quality. Quality is largely determined by the development process. Some of the better processes probably can't be applied to a free project, at least not easily. But a lot of commercial projects aren't applying even a minimum, and some of the better freeware projects have applied some of the easier and more obvious techniques. In the end, if you want quality, you have to consider the process used to develop the software, independently of the costs. -- James Kanze
From: James Kanze on 14 Feb 2010 08:03 On Feb 13, 4:27 pm, Seebs <usenet-nos...(a)seebs.net> wrote: > On 2010-02-13, James Kanze <james.ka...(a)gmail.com> wrote: > > Logically, I think that most of the techniques necessary for > > making really high quality software would be difficult to > > apply in the context of a free development. > They might be hard to apply, but consider that a great deal of > free software is written without idiots saying "you need to > get this done sooner so we can book revenue this quarter to > please shareholders". If your point is that some (most?) commercial vendors don't have a good development process, I already pointed that out. > 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. > It is also probably an influence that free software writers > expect the code itself to get feedback, not just the behavior > of the application. I have submitted bug reports about > poorly-expressed code, not just about code which didn't work. In a well run development process, such feedback is guaranteed, not just "expected". That's what code reviews are for. > > And at least up to a point, they actually reduce the cost of > > development. So theoretically, the quality of commercial > > software should be considerably higher than that of free > > software. > Again, I don't think there's actually any force driving that. > The benefits of well-written software are significant enough > that it is likely worth it to some people to improve software > they have access to, and if it's worth it to them to do that, > it costs them virtually nothing to release the improvements. > Free software often ends up with the best efforts of hundreds > of skilled programmers, with active filtering in place to keep > badly-written code from sneaking in. 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 Subversion is at least as good as any of the version > > management tools, excepted ClearCase (and the two really > > address different models of development). > If you are implying that CC is actually usable to you, that > marks a first in my experience. No one else I've known has > ever found it preferable to any of the open source tools, of > which git is probably currently the most elegant. 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. > > I think that part of the problem is that a mistake in a > > program will affect every instance of the program. Most > > recalls for cars, on the other hand, only affect a small > > subset of the total production. > Another issue is that, if you give away open source software, > people can modify it. If you modify my code, and your > modification is not itself buggy, and my code is not itself > buggy, but your modification causes some part of my code not > to work as expected, whose fault is that? This kind of thing > is a lot more complicated with code than it is with physical > objects. You don't have a million people using a bridge, and > a couple hundred thousand of them are using the bridge > recompiled for sports cars, and another couple hundred > thousand are running it with a third-party tollbooth > extension. That is, of course, a weakness of free software. A company using it, however, should be able to manage this (although I once worked for a company where one employee would slip modifications into the g++ we were trying to use for production code, without telling anyone). -- James Kanze
From: James Kanze on 14 Feb 2010 08:26
On Feb 13, 5:42 pm, Brian <c...(a)mailvault.com> wrote: > On Feb 13, 6:19 am, James Kanze <james.ka...(a)gmail.com> wrote: > > On 12 Feb, 22:37, Arved Sandstrom <dces...(a)hotmail.com> wrote: > > Logically, I think that most of the techniques necessary for > > making really high quality software would be difficult to apply > > in the context of a free development. And at least up to a > > point, they actually reduce the cost of development. [I really shouldn't have said "most" in the above. "Some" would be more appropriate, because there are a lot of techniques which can be applied to free development.] > I'm not sure what you are referring to, but one thing we > agree is important to software quality is code reviewing. > That can be done in a small company and I'm sometimes > given feedback on code in newsgroups and email. 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. 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. (I've often wondered if you couldn't get similar results using teleconferencing and emacs's make-frame-on-display function, so that people at the remote site can edit with you. But I've never seen it even tried. And I note that where I work, we develop at two main sites, one in the US, and one in London, we make extensive use of teleconferencing, and the company still spends a fortune sending people from one site to the other, because even teleconferencing isn't as good as face to face.) > > So theoretically, the quality of commercial software should > > be considerably higher than that of free software. > > Practically, when I actually check things out... g++ is one > > of the better C++ compilers available, better than Sun CC or > > VC++, for example. > Maybe now that Sun CC and VC++ are free they'll improve. :) I doubt it. Making something free doesn't change your development process. (On the other hand, if it increases the number of users, and thus your user feedback, it may help. But I don't think any quality problems with VC++ can be attributed to a lack of users.) > I'm not sure about Sun CC, but guess that it is free with > Open Solaris. Still I'm not comfortable with g++'s foundation. > I would like to think that VC++, written mostly in C++, is at > least able to produce a draw when up against g++. There are a lot of factors which affect quality, but the basic development process is by far the most important one. And from what I've seen, I'd guess that Microsoft doesn't have a particularly good process. Note that it's a lot easier to have a good process when relatively few people are involved. Which works against Microsoft, and also to a degree against g++. And may contribute to explaining why the EDG front-end is so good (along with the fact that it's probably easier to find four exceptional people than to find 400). [...] > That may be a reason why an on line approach makes sense. > Since you haven't shipped out instances of the program, > just make sure the instances that exist on your servers > are corrected. The other way, a court in a distant country > might hold you liable if some customers didn't receive a > message that they should update their copy. Who knows what a court in a distant country may decide. (Note that Microsoft now uses the push model for patches---by default, automatic upgrading is activated, and you get all of the latest patches for Windows, whether you asked for them or not.) -- James Kanze |