Planning and review save time and money
on
Software Aesthetics
·
· Score: 5, Insightful
Every extra day that I take to plan, every minute I spend thinking about design, and every extra line of code I write to make my software more pleasing is another line that could add more functionality, another minute wasted not producing something tangible, and another day that I need to be paid.
That is an absolutely absurd statement. Every moment spent in planning, review, consideration of potential problems, creation of general-purpose solutions, and documentation of architecture pays for itself many times over later in the development, validation, release and maintenance cycles. Failure to undertake sensible planning activities early in a project leads to massive schedule delays from forced late-game rearchitectures that would have been headed off by early consideration, review and communication.
Software engineering is the only engineering discipline in which the practitioners are permitted to indulge themselves in work without planning or review, and that's the #1 reason that software sucks.
What I'd really like would be to have a CPU in my arm.
Wouldn't it be better just to have an implanted interface, and have the actual processing unit be linked by wireless? The power requirements of a wireless interface are less demanding than a whole CPU, so you'd have to plug yourself in much less often. It would also be a lot easier to upgrade the CPU if it were external.
That assumes the author of the IDE was thoughful enough to provide that choice.
Well, yeah. It's been standard in every IDE I've worked with on the Mac since the late 1980's, so that doesn't seem like a big leap. It's not fair to compare a great CLI with a crappy GUI. Assuming they're both good examples of their kind, then the GUI wins.
If such a choice isn't there, then what?
Add it through the scripting interface. You did know that good GUI applications are scriptable, right?
The beauty of a CLI is that nobody but the user has to anticipate choices.
The beauty of a well-designed GUI is that 80-90% of the common cases are far easier than they are in a command line environment, and that the rest can be captured through scripting if you really have to. A "Remove Objects" menu item is a lot easier to use for either the novice or expert user than "find . -name '*.o' -exec rm {} \;". Common operations should be built in to the system.
(BTW, I was under the impression the actual way to do this is "make clean"....)
Well, first of all, his rm command was totally wrong, which I figured I wouldn't flame him for
Yep, "rm -r *.o" would not do what he thought it would, which is remove all object files recursively.
It also wouldn't give any kind of clue that it hadn't done it, since he's unlikely to do a recursive "ls" after the operation. (A direct manipulation interface would show the results of the operation.) Having made this error, when he followed up with a "make", it wouldn't rebuild the object files he expected. When he tried to debug, he might easily spend an hour chasing a red herring because he thought he'd done a complete rebuild when he hadn't.
This is one of the biggest counts against command languages. They are error-prone -- not just typing errors, but semantic errors as well, even for experts; and due to the lack of feedback, errors are hard to detect and recover from. These errors are in a sense fun and challenging for the hobbyist or tinkerer, but for everyone else, they are a giant pain in the nether regions.
ooookkkk, in the parent example of recursively deleting all.o files from the current and all child directories, how would you as quickly and easily do this with a file manager?
Hit the "Remove Objects" menu item in your IDE. That's how.
Don't be surprised if systems originally built to be manipulated with a command line are hard to deal with in a GUI. The answer is to revisit assumptions from the ground up rather than just adding a thin GUI veneer to a CLI-based system. That's the worst of both worlds.
Well, they did try "smart menus" that didn't show you commands that you didn't use too often, but IIRC a lot of people thought those were pretty annoying.
That's because the distinctions between basic and advanced that MS uses are arbitrary and don't match any sensible incremental disclosure sequence. Technically this design error is known as a mismatch between the user and system model. In this case, what it leads to is an extra step in searching for options, because the user has no way of knowing what is hidden in the "advanced" functionality.
With a cleaner conceptual break between the initially disclosed and initially undisclosed information, though, it's a great way to manage interface complexity. Usually this means having the undisclosed portion all be strongly conceptually related under a particular category, rather than simply being a miscellany of supposedly advanced features.
Incremental disclosure with sticky adaptation, the single UI principle discussed in the interview, has been well known in the design community since the 1980's.
Just because Microsoft doesn't make good use of the principle doesn't mean that it's a gift from gaming to the rest of the world.
In most other ways, games are UI nightmares. They're difficult by design. Applying their principles to other domains would be a giant step backwards. Non-entertainment systems should be easy by design, rather than conjuring obstacles for the thrill of overcoming them.
Fans of UNIX will, of course, disagree. The popularity of archaic command-line interfaces in the UNIX subculture could perhaps be understood as a consequence of gamer-like behavior among hobbyists and tinkerers.
Much of the moderation here appears to be done based on whether or not the moderator personally agrees with you, regardless of how intelligent or relevent your comments may be. This is a subtle evolution of the "luser who uses Windoze" quote from the NetSlaves author. It's rare that Microsoft does something right, of course, but when it does, it's nice to be able to discuss it rationally.
There is a lot of ideological moderation here, but if you stay reasonable, choose your battles carefully, and back up your points with solid facts, you can get modded up on/. without adhering to the dominant pro-Linux, pro-open-source, anti-user-experience ideology. I've done it, as an old Mac hand who thinks the open source model is fundamentally flawed, and who frequently points out problems with command line interfaces and UNIX. It took a lot of work, and I've had to be a lot more careful in expressing myself than would someone whose views were more in line with local consensus, but it's been effective.
Granted, I also get flamed out the wazoo by hordes of ESR drones, but that's only to be expected when you're taking an antinomian stance. I also sometimes get unfairly modded down, usually by the kinds of people who like to throw "overrated" around to avoid metamod, but that happens less often than you'd think.
So I can't testify from personal experience that all divergent views get modded down here. In any human group critics need to be extra careful, but in many groups, someone taking an oppositional stance like mine would be excluded altogether, rather than being at the karma cap.
people have to switch to root to do a bunch of stuff - and who wants that on a home computer? I suggest (and I'm not kidding now) an "Insecure Linux" flavour, where there is only the root user.
Sounds good on first blush, but the problem is that the root concept is used for two different things. It not only guards "privileged" operations like certain software installs, but also guards dangerous operations by requiring root login for actions that might damage the system. Everyone would like to be able to install software on a personal system without su'ing to root, but if the average user could also destroy their system at any time, that would be a decrease in usability.
It's another example of how basic assumptions made in UNIX are in conflict with user friendliness principles, and how there's no quick fix for pervasively unfriendly assumptions.
Is the validity of open source as a business strategy a valid, debatable hypothesis, or is its validity really just a matter of faith that could never be questioned no matter what ?
From my experiences here, I would say the latter. I've now had several conversations where people cite various companies (Red Hat, Cygnus, VA Linux, Mandrake, etc.) as examples of open source business successes. I then point out that those companies are and were not profitable, and the people I am talking to just fall silent. It doesn't appear that real-world considerations and evidence have anything to do with the religious belief in the profitability of the open source business model.
Linux is free. And yet there are no commercially available dual-boot machines on the market.... There is no other way to explain this phenomenon other than as a repercussion of the confidential Windows License under which every hardware vendor must do business.
No, Linux is not free to the vendor. It requires an extra configurator setting, more system testing, documentation and support cost, installer and boot-time software development, inclusion of CD-ROMs, and a few gigabytes off the hard disk. If there's not customer demand for the feature there's no point in the extra cost for the system vendor.
How does this affect the recent discussions about Moore's law ?
It doesn't affect them much. It's good to have a proof of concept for a nanotube NOT gate, but it leaves open questions of manufacturing and connectivity which would be crucial to creating a real technology from this kind of circuit element. I don't think anyone doubted that nanoscale gates were possible, but what is more questionable is how they can be economically assembled and effectively interconnected.
I was there for the collapse of OpenDoc, and CyberDog was developed within a few meters of my office. It seems to me that the problems were bad technical management and the withdrawal of all the outside technical partners, rather than inadequate spending on R&D. OpenDoc only had a hope given cross-platform support, which failed to materialize despite commitments; and as for technical management at Apple, bear in mind that this was also the time of Copland.
Cyberdog was a poor choice for an initial OpenDoc vehicle. That's not what the kind of application OpenDoc was designed for, and its I/O architecture would have had to be rebuilt to really suit the needs of a browser. Apple is not an application developer, and it would have taken cooperation with Claris and other application developers to build more adequate flagship products. As it is, Apple is usually incapable of internal cooperation between groups and often has a hostile relationship with its application developers such as Adobe.
What any of this really has to do with open source eludes me.
According to this AP story (free registration at NY Times required), that's not really an issue:
The fact that colonies of human embryonic stem cells are grown with the help of mouse cells won't block their eventual use in people as long as scientists meet well-known federal safety rules, regulators said Friday.
Indeed, the Food and Drug Administration has allowed cells from pig fetuses to be implanted experimentally into the brains of Parkinson's disease patients. A Massachusetts company for 10 years has grown burn victims skin grafts using mouse ``feeder'' cells like those at issue with stem cell research.
"We are firmly committed to Open Source development as a methodology for creating better software, faster." [valinux.com] -- Dr. Larry M. Augustin, president and CEO of VA Linux Systems, as quoted in a September 2000 press release.
He stated an even more extreme pro-open source position recently, in the SiliconValley.com Open Source Roundtable. On June 26, he wrote that Microsoft should place all its software under the GPL: "Frankly, I'm surprised Microsoft doesn't adopt the GPL for all of the software it releases to the public."
Now, less than two months later, his company has decided that it's not going to use the GPL for all of its own software. In June, even Microsoft Office should have been GPLed; in August, not even developer tools should be GPLed. It is quite a turnaround.
Red Hat has never made a profit. Citing a money-losing company as an example of the profits to be made from open source does not make a lot of sense to me.
Sure, if people sink lots of money into developing free software, it can sometimes be good, but the question is sustainable profitability.
/. not displaying news about VA Linux might be hypocritical, but it wouldn't make them Censorware. To my knowledge,/. has put their Censorware days behind them.
2001-08-23 22:24:58 VALinux Loses a Quarter Billion (articles,linuxbiz) (rejected)
The model [tuxedo.org] is free the software, but sell the support and the customizations.
That's an inherently non-scalable model. For every dollar you make, you have to pay a significant fraction of a dollar. It's a recipe for a small privately held company where only the founders make any significant money and they must rely on the labors of wage slaves who have no reasonable hope of significant reward through equity.
The non-scalable model does not pay for the large R&D expenditures needed to produce significant software, which is why most open source projects of medium or large size lag far behind their commercial counterparts. This is also why the open source archives contain mostly half-finished toy projects whose year-old "to do" page states simply "I intend to rewrite this from scratch."
The shade of red lipstick you purchased on the Internet and viewed on your LCD monitor will be the exact color red you receive in the mail.
That would appear to be an actionably false claim. Color calibration can only go so far, especially when dealing with aspects of color that are not captured in current displays such as reflectance, and when mapping between different color gamuts.
Calibration also gives incorrect results when mapping between different kinds of color. Monitor color is additive, while real-world colors are usually subtractive.
Finally, color is heavily affected by ambient light conditions, to which monitors and real-world objects respond differently.
Calibration can reduce differences but it comes nowhere close to removing them.
Both your comment and the article you referenced should be dismissed as flamebait. The article, written in a juvenile, profane and offensive style, utterly misses the point that Gibson is careful to make, which is that with Windows XP providing raw socket access, it becomes easier to create malware that runs on Windows. It's not that it's impossible now, but there's this funny thing about people: when something becomes easier, they do it a lot more.
Tim
Re:would you buy a used car from this model?
on
Mob Software
·
· Score: 2
Actually, the biological analogy holds up just fine. The command-and-control mechanisms in a human are awesome - far more sophisticated and reliable than those in a car.
Humans were designed by a "mob" process, one with no command and control mechanism. They break down constantly, require enormous amounts of downtime (often unplanned), can't be upgraded, and are extremely expensive and difficult to repair when something goes wrong -- if repair is possible at all.
That's why a car can't juggle.
You could build a juggling mechine very easily, if there were a use for such a thing.
Again, the nature of a tool is that it solves a restricted problem domain very predictably. That's what computer software is for, not to mention houses, cars, hammers, and so forth. Biological systems have different requirements, to live long enough to reproduce in a variable environment. The design methodologies for the two sets of requirements are different.
Tim
would you buy a used car from this model?
on
Mob Software
·
· Score: 3, Insightful
I can't imagine anyone being willing to buy a house that had been built with no architect, no blueprint and no foreman -- a house built by a bunch of construction workers doing whatever they thought was best that day, and not bothering to write down any of their decisions. That is how "Mob software" projects are run. It's a well-known recipe for bad software. Its results are unreliable, slow, and impossible to maintain. Command and control systems are required for synchronized execution of a coherent plan.
Successful open source projects have command and control systems. They don't just grow on trees.
The biological analogy doesn't hold. No one would buy a car that was as flaky as a body. The point of machines is that they're machines, not organisms. They're highly predictable and apply to a restricted problem domain. That's why they can do things we can't.
Slashdot Mirror
Every extra day that I take to plan, every minute I spend thinking about design, and every extra line of code I write to make my software more pleasing is another line that could add more functionality, another minute wasted not producing something tangible, and another day that I need to be paid.
That is an absolutely absurd statement. Every moment spent in planning, review, consideration of potential problems, creation of general-purpose solutions, and documentation of architecture pays for itself many times over later in the development, validation, release and maintenance cycles. Failure to undertake sensible planning activities early in a project leads to massive schedule delays from forced late-game rearchitectures that would have been headed off by early consideration, review and communication.
Software engineering is the only engineering discipline in which the practitioners are permitted to indulge themselves in work without planning or review, and that's the #1 reason that software sucks.
Tim
What I'd really like would be to have a CPU in my arm.
Wouldn't it be better just to have an implanted interface, and have the actual processing unit be linked by wireless? The power requirements of a wireless interface are less demanding than a whole CPU, so you'd have to plug yourself in much less often. It would also be a lot easier to upgrade the CPU if it were external.
Tim
That assumes the author of the IDE was thoughful enough to provide that choice.
Well, yeah. It's been standard in every IDE I've worked with on the Mac since the late 1980's, so that doesn't seem like a big leap. It's not fair to compare a great CLI with a crappy GUI. Assuming they're both good examples of their kind, then the GUI wins.
If such a choice isn't there, then what?
Add it through the scripting interface. You did know that good GUI applications are scriptable, right?
The beauty of a CLI is that nobody but the user has to anticipate choices.
The beauty of a well-designed GUI is that 80-90% of the common cases are far easier than they are in a command line environment, and that the rest can be captured through scripting if you really have to. A "Remove Objects" menu item is a lot easier to use for either the novice or expert user than "find . -name '*.o' -exec rm {} \;". Common operations should be built in to the system.
(BTW, I was under the impression the actual way to do this is "make clean"....)
Tim
Well, first of all, his rm command was totally wrong, which I figured I wouldn't flame him for
Yep, "rm -r *.o" would not do what he thought it would, which is remove all object files recursively.
It also wouldn't give any kind of clue that it hadn't done it, since he's unlikely to do a recursive "ls" after the operation. (A direct manipulation interface would show the results of the operation.) Having made this error, when he followed up with a "make", it wouldn't rebuild the object files he expected. When he tried to debug, he might easily spend an hour chasing a red herring because he thought he'd done a complete rebuild when he hadn't.
This is one of the biggest counts against command languages. They are error-prone -- not just typing errors, but semantic errors as well, even for experts; and due to the lack of feedback, errors are hard to detect and recover from. These errors are in a sense fun and challenging for the hobbyist or tinkerer, but for everyone else, they are a giant pain in the nether regions.
Tim
ooookkkk, in the parent example of recursively deleting all .o files from the current and all child directories, how would you as quickly and easily do this with a file manager?
Hit the "Remove Objects" menu item in your IDE. That's how.
Don't be surprised if systems originally built to be manipulated with a command line are hard to deal with in a GUI. The answer is to revisit assumptions from the ground up rather than just adding a thin GUI veneer to a CLI-based system. That's the worst of both worlds.
Tim
Well, they did try "smart menus" that didn't show you commands that you didn't use too often, but IIRC a lot of people thought those were pretty annoying.
That's because the distinctions between basic and advanced that MS uses are arbitrary and don't match any sensible incremental disclosure sequence. Technically this design error is known as a mismatch between the user and system model. In this case, what it leads to is an extra step in searching for options, because the user has no way of knowing what is hidden in the "advanced" functionality.
With a cleaner conceptual break between the initially disclosed and initially undisclosed information, though, it's a great way to manage interface complexity. Usually this means having the undisclosed portion all be strongly conceptually related under a particular category, rather than simply being a miscellany of supposedly advanced features.
Tim
Incremental disclosure with sticky adaptation, the single UI principle discussed in the interview, has been well known in the design community since the 1980's.
Just because Microsoft doesn't make good use of the principle doesn't mean that it's a gift from gaming to the rest of the world.
In most other ways, games are UI nightmares. They're difficult by design. Applying their principles to other domains would be a giant step backwards. Non-entertainment systems should be easy by design, rather than conjuring obstacles for the thrill of overcoming them.
Fans of UNIX will, of course, disagree. The popularity of archaic command-line interfaces in the UNIX subculture could perhaps be understood as a consequence of gamer-like behavior among hobbyists and tinkerers.
Tim
No wonder most of the people i encounter in #freebsd on undernet or efnet are such jerks.
After all, most people on IRC are really sweet and kind.
The hostile, immature and flamebait aspects of the free software and open source communities are certainly among their greatest barriers to success.
Tim
Much of the moderation here appears to be done based on whether or not the moderator personally agrees with you, regardless of how intelligent or relevent your comments may be. This is a subtle evolution of the "luser who uses Windoze" quote from the NetSlaves author. It's rare that Microsoft does something right, of course, but when it does, it's nice to be able to discuss it rationally.
/. without adhering to the dominant pro-Linux, pro-open-source, anti-user-experience ideology. I've done it, as an old Mac hand who thinks the open source model is fundamentally flawed, and who frequently points out problems with command line interfaces and UNIX. It took a lot of work, and I've had to be a lot more careful in expressing myself than would someone whose views were more in line with local consensus, but it's been effective.
There is a lot of ideological moderation here, but if you stay reasonable, choose your battles carefully, and back up your points with solid facts, you can get modded up on
Granted, I also get flamed out the wazoo by hordes of ESR drones, but that's only to be expected when you're taking an antinomian stance. I also sometimes get unfairly modded down, usually by the kinds of people who like to throw "overrated" around to avoid metamod, but that happens less often than you'd think.
So I can't testify from personal experience that all divergent views get modded down here. In any human group critics need to be extra careful, but in many groups, someone taking an oppositional stance like mine would be excluded altogether, rather than being at the karma cap.
Tim
people have to switch to root to do a bunch of stuff - and who wants that on a home computer? I suggest (and I'm not kidding now) an "Insecure Linux" flavour, where there is only the root user.
Sounds good on first blush, but the problem is that the root concept is used for two different things. It not only guards "privileged" operations like certain software installs, but also guards dangerous operations by requiring root login for actions that might damage the system. Everyone would like to be able to install software on a personal system without su'ing to root, but if the average user could also destroy their system at any time, that would be a decrease in usability.
It's another example of how basic assumptions made in UNIX are in conflict with user friendliness principles, and how there's no quick fix for pervasively unfriendly assumptions.
Tim
Is the validity of open source as a business strategy a valid, debatable hypothesis, or is its validity really just a matter of faith that could never be questioned no matter what ?
From my experiences here, I would say the latter. I've now had several conversations where people cite various companies (Red Hat, Cygnus, VA Linux, Mandrake, etc.) as examples of open source business successes. I then point out that those companies are and were not profitable, and the people I am talking to just fall silent. It doesn't appear that real-world considerations and evidence have anything to do with the religious belief in the profitability of the open source business model.
Tim
so explain to me why linux is free to all my friends
I listed eight specific costs to a system vendor. Was there something you didn't understand?
Tim
Linux is free. And yet there are no commercially available dual-boot machines on the market.... There is no other way to explain this phenomenon other than as a repercussion of the confidential Windows License under which every hardware vendor must do business.
No, Linux is not free to the vendor. It requires an extra configurator setting, more system testing, documentation and support cost, installer and boot-time software development, inclusion of CD-ROMs, and a few gigabytes off the hard disk. If there's not customer demand for the feature there's no point in the extra cost for the system vendor.
Tim
How does this affect the recent discussions about Moore's law ?
It doesn't affect them much. It's good to have a proof of concept for a nanotube NOT gate, but it leaves open questions of manufacturing and connectivity which would be crucial to creating a real technology from this kind of circuit element. I don't think anyone doubted that nanoscale gates were possible, but what is more questionable is how they can be economically assembled and effectively interconnected.
Tim
I was there for the collapse of OpenDoc, and CyberDog was developed within a few meters of my office. It seems to me that the problems were bad technical management and the withdrawal of all the outside technical partners, rather than inadequate spending on R&D. OpenDoc only had a hope given cross-platform support, which failed to materialize despite commitments; and as for technical management at Apple, bear in mind that this was also the time of Copland.
Cyberdog was a poor choice for an initial OpenDoc vehicle. That's not what the kind of application OpenDoc was designed for, and its I/O architecture would have had to be rebuilt to really suit the needs of a browser. Apple is not an application developer, and it would have taken cooperation with Claris and other application developers to build more adequate flagship products. As it is, Apple is usually incapable of internal cooperation between groups and often has a hostile relationship with its application developers such as Adobe.
What any of this really has to do with open source eludes me.
Tim
Tim
It is not newsworthy.
Yeah, what's newsworthy about a quarterly loss of three times the market cap? Damn sensationalists!
Tim
"We are firmly committed to Open Source development as a methodology for creating better software, faster." [valinux.com] -- Dr. Larry M. Augustin, president and CEO of VA Linux Systems, as quoted in a September 2000 press release.
He stated an even more extreme pro-open source position recently, in the SiliconValley.com Open Source Roundtable. On June 26, he wrote that Microsoft should place all its software under the GPL: "Frankly, I'm surprised Microsoft doesn't adopt the GPL for all of the software it releases to the public."
Now, less than two months later, his company has decided that it's not going to use the GPL for all of its own software. In June, even Microsoft Office should have been GPLed; in August, not even developer tools should be GPLed. It is quite a turnaround.
Tim
what about Red Hat?
Red Hat has never made a profit. Citing a money-losing company as an example of the profits to be made from open source does not make a lot of sense to me.
Sure, if people sink lots of money into developing free software, it can sometimes be good, but the question is sustainable profitability.
Tim
/. not displaying news about VA Linux might be hypocritical, but it wouldn't make them Censorware. To my knowledge, /. has put their Censorware days behind them.
2001-08-23 22:24:58 VALinux Loses a Quarter Billion (articles,linuxbiz) (rejected)
Tim
The model [tuxedo.org] is free the software, but sell the support and the customizations.
That's an inherently non-scalable model. For every dollar you make, you have to pay a significant fraction of a dollar. It's a recipe for a small privately held company where only the founders make any significant money and they must rely on the labors of wage slaves who have no reasonable hope of significant reward through equity.
The non-scalable model does not pay for the large R&D expenditures needed to produce significant software, which is why most open source projects of medium or large size lag far behind their commercial counterparts. This is also why the open source archives contain mostly half-finished toy projects whose year-old "to do" page states simply "I intend to rewrite this from scratch."
Open source is over. Get over it.
Tim
The shade of red lipstick you purchased on the Internet and viewed on your LCD monitor will be the exact color red you receive in the mail.
That would appear to be an actionably false claim. Color calibration can only go so far, especially when dealing with aspects of color that are not captured in current displays such as reflectance, and when mapping between different color gamuts.
Calibration also gives incorrect results when mapping between different kinds of color. Monitor color is additive, while real-world colors are usually subtractive.
Finally, color is heavily affected by ambient light conditions, to which monitors and real-world objects respond differently.
Calibration can reduce differences but it comes nowhere close to removing them.
Tim
Tim
Humans were designed by a "mob" process, one with no command and control mechanism. They break down constantly, require enormous amounts of downtime (often unplanned), can't be upgraded, and are extremely expensive and difficult to repair when something goes wrong -- if repair is possible at all.
That's why a car can't juggle.
You could build a juggling mechine very easily, if there were a use for such a thing.
Again, the nature of a tool is that it solves a restricted problem domain very predictably. That's what computer software is for, not to mention houses, cars, hammers, and so forth. Biological systems have different requirements, to live long enough to reproduce in a variable environment. The design methodologies for the two sets of requirements are different.
Tim
Successful open source projects have command and control systems. They don't just grow on trees.
The biological analogy doesn't hold. No one would buy a car that was as flaky as a body. The point of machines is that they're machines, not organisms. They're highly predictable and apply to a restricted problem domain. That's why they can do things we can't.
Tim