Slashdot Mirror
Why Software Still Sucks
atlantageek writes "The man who brought you (or somebody else) virtual reality speaks to upside about the sorry state of Software." "The Guy" is Jaron Lanier, and the article covers a fair amount of stuff. This isn't a super smart technical article, but its got a lot of interesting comments on subjects ranging from software, Linux, open source, Unix,
DeCSS, and more.
Engineering software assume that designing/building/testing code is difficult. Sorta like building a bridge.
Frankly, proportionally speaking, it's not difficult. What is EXTREMELY difficult is determining end-user requirements. Our problem isn't that we don't know HOW to build the bridge (and make it safe) but rather attempting to figure out that the user wants a bridge in the first place. (As opposed to a ferry, as opposed to a cargo plane, etc.)
Our requirements come to us not as "I want a bridge that'll support a 10 ton truck." Rather, they come to us and I'd like to get from there to there. And it should have wings. And float. And it'll need to support a 10 ton truck.
Until this problem is fixed, software engineering won't be able to 'solve' anything, because the requires are always changing.
The thing about software is that you, dear reader, can create it. We should _expect_ that fact, the fact that anyone can do it, to cause exactly the chaos and prevalence of mediocrity and plain badness that is being complained about here.
...") that we find it hard to resist. And all this time it just all seems so _possible_. In a theoretical sense, it is--but the razorlike reefs are right there under the waves. Even when we are going down we often don't see why we failed.
Consider the huge difference between software "products" and other machine/tool-like things. Suppose you want to make something--say, a can opener. Most of us understand, in principle, how a can opener works. I think most of us can look at any given can opener (they're pretty much open source, after all) and understand its design. But what would it take to create one ourselves? Lots of money, basically. Not-commonly-available tools, parts or the tools to make them, space to put all of that stuff. Who's going to do that in their garage? Maybe some person with a vision of the perfect can opener and dreams of changing the way everyone opens cans? But, of all the people that dream of changing the way everyone opens cans (already a tiny number of people, I would guess), how many of them could even afford it, or could convince someone to fund it?
It's just not likely to happen. So can openers, by and large, are going to be designed only by companies with access to the materials and tools _and_ a bottom line to worry about--meaning that they're not going to do it half-assed.
Now switch your brain to the world of software tools, and instead of a can opener, think of a recipe database. Heck, I wrote one one day, and I thought the other day about web enabling it so my family could share recipes over the web. It doesn't, as has often been observed, mean that I _should_--but I can, I know that I can, and all it's going to take is a little time (but "little" is, of course, _very_ deceptive). The tools are right in front of me--except for the hardware, that you could probably get for almost free, everything is free. All it takes is time. And I have (at least some) time. So I can. So I might. And so, many people do.
Okay, that explains a lot of the crap that's out there, but what about the commercial stuff that's also crap?
A similar thing happens at software companies--although the perception is not correct, they _think_ they can. That same "we have the tools, we just need to write the code" mentality is alive and well at software companies. It's relatively easy for an engineer to say "okay, metal gears of this size and spec will cost this much, but it will be this much if you want plastic. if we eliminate this button we save X dollars and get rid of some possible breakage issues which we rate as an X% probability in normal use". Quick, how much does a javascript function to validate input on a form cost? There's no easy way to answer that, no book to look up the numbers in. Because "all" it takes is for someone to sit down and write those lines out, and because, once those lines are written, producing the next copy of them costs nothing, designers are led down a very deceptive path to a hugely complicated structure that quickly becomes hard to understand, hard to coordinate the interactions of the different parts of, hard to test thoroughly, and hard to deliver on time.
Once you get into that situation, you have to cut corners, slap stuff together, do the absolutely necessary stuff, and suddenly you're plagued with a poor user interface (because that takes time, understanding, and developer buy-in to get right), ugly bugs (because you didn't have time to develop, much less run through, an exhaustive set of test cases), etc, etc. And then is when you come up against the wall, and you find out that, while all this time you were thinking out oculd, because the tools were right there, you actually _can't_, because you _don't_ have enough time.
Basically, the feature sirens are always calling us to the rocks, and the song is so beautiful ("We could make it compatible with
--
Liberty uber alles.
Of course, you really want to be saying to a computer "put that file somewhere around my home directory" or "Format that hard drive, make it about a third of the drive" or "Cad program, make that sewer pipe about this long" (holds hands apart).
Computers are an exact thing, they need to be handled in an exact way. The command line provides that exact way. The number of times I've been using Corel Draw and wished I could just type in "box, 2in x 1in" rather than have to click and fiddle with the mouse, having it jump 0.1" bigger when I release the mouse button. Angles in circles are even worse.
Rich
There are some other reasons why software sucks, tho. Check out this article... talks about how where people go wrong when they try to make software "easy."
Part of the problem lies in the complexity of mapping the software paradigms to the implementation. It's all those exceptions to the rule that give coders a headache, and it isn't any better for the users.
So far software engineering itself is full of guesswork, too. Most software houses don't use SE, and using SE doesn't necessarily always help. I think this is because SE is simply still in its infancy.
byroniverse
And his comments about "humanity" not knowing how to make software, or even what software is, were just plain over-dramatic, hippified philosobabble.
No, I think he has a point.
In 1920, humanity did not know how to make jet engines, whether they would work well, etc. Then
Frank Whittle invented them, and now "humanity" knows how to make them.
The same may be true for software. Over the years, we've developed ideas of abstraction, encapsulation, structured programming, object-oriented programming, BNF, program proving, and so forth. At one time these concepts didn't exist; now they're well-known and fairly well understood. There are no doubt concepts still undiscovered and unexplored that will improve our software development in future.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
Thanks. Now I can rank on Netscape in the same way that I did Sun.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
These decisions are often made primarily by the Sales & Marketing types who have little knowledge of computers and only fuzzy concepts of what the software is supposed to do or what the users want.
It is so easy to place the blame on the sales & marketing types, but have you ever considered the blame may be on the programmer. If a programmer does not stop a moment and form an argument for a better way of doing something, then he is not doing anything to deal with the issue. I don't know, maybe I am blessed with a very understanding marketing department, but whenever I have come across a problem with how they want things done, all I have had to do was come up with a group of different solutions, explain why it wouldn't work the way they want it, and ask them to choose one of my solutions. If it is the case that I have a decent marketing department working with me, then I feel sorry for you guys, but if the case is that programmers don't bother to offer better solutions to these people, then I'm sorry, you deserve all that you get.
Tired of sitting at that karma cap? Start a flame war today! See just how low you can go!
Ever seen OS/2? OS/2 is butt-ugly. It's config.sys makes DOS/Windows look elegant by comparison. But you would never guess this from the UI, which puts all other UIs to shame. How did they do it? They put a powerful layer in between: SOM.
The same sort of thing can be done with Unix, it's just that no one has. Oh wait, someone has: Apple has done it with Aqua. A very different approach than OS/2, but still, the UI is completely divorced from the inner workings. I haven't used Aqua yet, but I know that when I try it, my reaction is not going to be, "This is Unix. I know this."
The open source movement hasn't done anything like this yet, because they are too busy trying to compete with Windows. As long they keep looking to the worst UIs for inspiration (e.g. MS Windows Explorer) and try to infiltrate the corporate world by blending in (e.g. Miguel's mailer that looks just like MS Outlook), that's just how it's going to be. But it doesn't have to be like that. The GNOME/KDE guys have set their sights very low.
Could have? That sounds like present-day OpenBSD and Linux, respectively.
As for my explanation as to why software sucks, I think it's pretty simple: the economy has judged that software that sucks but is cheap, is preferable to software that doesn't suck but is expensive. Quality takes time, and time is money. I write software-that-sucks for a living, and whenever I give a customer a choice between something that sucks for 8 hours or something that sucks less for 16 hours, they almost always take the cheaper choice.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
As far as I'm aware kernel compression is required because the BIOS can only boot files up to a certain size. Someone correct me on this if I'm wrong.
The ambiguity is part of it. A design I had was to have pronouns default to the most recent named direct object, which would make things a lot easier.
And yes, it is a lot different from my plain-english equivalent. Prepositions, lists, adjectives, adverbs, and other parts of speech are what - almost impossible to move over?
How about this:
temporarily delete file_1.txt
quickly execute file_2.exe (upgraded priority!)
print all files older than 1 day
delete any file containing the word "you"
change ownership of any file containing 'kidder' to me
either execute file_3.exe or mail me
Simple aliasing is not going to handle these sort of things. Piping, of course, and judicious use of 'find' will, but I don't want either of those. I want a system that can understand context and ambiguity. I want an NLP shell.
I'm probably being old(new?)-fashioned and definitely inflexible, but no moreso than those who think that the command-line is what God uses.
There is an old saying from classic art: A work of art is not completed when nothing can be added. It is completed when nothing can be taken away. A lot of software would be improved if that thought were taken to heart.
Don't forget these wise words came from "a small cafe just off West Broadway in New York's Tribeca neighborhood" so they must be important!
- Toby
Your example comes off as an argument against your case.
The fact that your computer can't understand "irregular and ambigous" commands and instead forces the user to bang his head against the considerable syntax of 'find' pretty much seals the case that it is not the "most natural" way to communicate. Not that pointing and dragging at things is either.
Thats a really lame putdown. Try a bit harder next time.
-rwxr-xr-x 1 root root 158740 May 1 1999 /usr/bin/pico /usr/bin/joe /usr/bin/jed /usr/bin/vim
-rwxr-xr-x 1 root root 180484 May 1 1999
-rwxr-xr-x 1 root root 256972 May 1 1999
-rwxr-xr-x 1 root root 503832 May 1 1999
Any of those small enough? How about
-rwxr-xr-x 1 root root 47656 Apr 30 1999 /usr/bin/ed
Look at the vast amount of written word published in the last year and ask "How much is quality?" .lib (.dll, etc) to pull from and the correct functions to pull from that .lib. Writting the same thing for a CLI is much easier but who would use it other than ourselves?
:-)
Look at the really vast amount of written word published in the last 50 years and ask "How much is quality?"
All someone needs in order to write a novel is an understanding of their language and a dictionary to sound educated.
Programming software is the same, the only real difference is that we learned how to program after we learned our native language. Add to that the huge amount of words and logic structure that we need to know in order to make a simple word processor run in any GUI. If we want to make it as small as possible we need to know the right
The guy has a point. Software for the most part does suck, but look at all the books out there that suck.
Forgive me if this post is a bit scattered, I've been awake for 48 for no good reason.
"If you're not confused by quantum mechanics, you really don't understand it." - Niels Bohr
Windows can be very finicky when it comes to hardware.
I've seen plain-Jane machines that deterministically crashed when NT4 did its peripheral scanning during installation, baffling the local tech support. This, as it happens, was while working at a certain large software company in Redmond, WA.
Only the dead have seen the end of war.
The problem here is the fact that a weird OS like Linux is effectively bringing the Unix-world back like a plague that won't be exterminated.
*giggle* 'snort' heheI... BAAAAAAAAhahahahahahah 'snof' hehhe.. What, um.. makes you think it ever disapeared?
Dirty Pirate Hooker
Generally I agree with you comments, but I have to pick up up on a couple of pieces.
I have this sneaking suspicion that any abstraction of code -- UML, flowcharts, proofs -- is only that: an abstraction. And that correctness (or, more likely, bugginess) lives in the code, and in the code alone, so that's where you have to weed it out.
The Design and the Code are both abstractions from the problem domain. Therefore they could both (or neither) be faulty. The problem could be design or coding fault.
It is the design 'process' that is useful, it forces the Software Engineer to understand the problem, before they've invested too much time. It improves flexibility and reliability, both of which reduce the mainternace burden (a VGT). In my experience, using Analysis & Design tools such as UML makes a considerable impovement in the 'quality' of the system. They are also a better that code to communicate ideas to fellow Engineers.
I personally think Extreme Programming holds a high amount of promise...
Extreme Programming, is just the latest buzz word for what was RAD, and before that what was simply good practice/procedures, i.e. review, Review, REVIEW! test, Test, TEST!
While it's probably the case that software today is too complex to get all the bugs out, the situation could be vastly better than it currently is. There is a lot of discussion of current software problems and what to do about them in Risks.
It is frequented by many esteemed experts in software architecture, reliability, security as well as just plain folks. The bug anecdotes reported there are often pretty funny but sometimes frightening and sobering too.
I think anyone who works with computers in any substantial way should read Risks.
Michael D. Crawford
GoingWare Inc
-- Could you use my software consulting serv
Most software sucks because they can make one or two hotfixes and add a new function or three and sell it for the same price that they sold the first one, or and upgrade for a little cheaper. Its BS they shouldn't sell you anything unless it's a new product or greatly improves the original. That would be like Norton selling the product and then six months later sell you the same product again for the same price so that you can get the virus database update.
"The secret of success is to know something nobody else knows." -Aristotle Onassis
red --- magenta
blue --- cyan
yellow --- yellow
Really, just grow up. If you don't like our humor, stop reading our posts. If you don't like my comments on patents (only one of us has extensive patent knowledge), then stop reading them. We either try to "lighten the load" or give some insight. You, however seem to do nothing but bitch, complain, and post useless babble.
This will be our last reaction to anything you ever post - we don't care what you have to say - and I doubt anyone else does either.
Hi! This is the Sig, blatantly attached to the end of this comment.
What does it matter? Since when has assembly code been object oriented? OO is was invented to make life easy for people who couldn't really get to grips with procedural programming. IMO anyway.
Heck, I was born here in the USA, and I've been trying to speak English for ~23 years now (some would say that Americans can never learn proper English, but that ain't right ;-) So, it took me (let's say) 10-12 years to master English, but I can "Learn Perl in 21 Days" and "Learn C in 7 Days"... or, if you want to be picky, a good semester course in Models of Computation could have one fairly fluent in C, Lex, Yacc, and a few others in a fairly short time. Programming / scripting lanuages are more direct and precise, since computers aren't very adept at guessing what we really mean if we are ambiguous...
I think I had a point, but I must have forgotten it by now... shoot, it probably just boils down to a "Me Too!" post by now.
--
"It's tough to be bilingual when you get hit in the head."
Meeting at the beginning of the week to determine which new features/bug fixes would get implemented that week.
Three days of programming, followed by a cut to CD-ROM at the end of the third day. This cut could be at any time, once it occurred after midnight.
On Friday test everything to make sure it worked, including 100% components that had not even been touched in the previous month. Ship to customer no matter what was found, but report bugs at the following Monday meeting.
No wonder the software never worked properly. Problems were being introduced due to tired developers. Not enough time was spent squashing some really evil bugs. And one developer was so utterly hopeless he should have been fired.
There's truth to your sig, but at least part of the problem is that the designers are not the (only) ones making the decisions about what features should or should not go into a product. These decisions are often made primarily by the Sales & Marketing types who have little knowledge of computers and only fuzzy concepts of what the software is supposed to do or what the users want. Add to that the one-upmanship that goes on in this industry (XYZ Co. has 128 widgets in their thingamagiggy....we better support 256. Never mind that no user has ever needed more than 10.) and you have a recipe for feature-bloat and scope-creep. Then the product isn't very well tested because the requirements are poorly understood in the first place. And the huge parameter space of most programs coupled with the wide variety of hardware they must run on (and myriad of device drivers, etc.) just further complicates the testing process. And don't even get me started about release dates. I think this reason may be the worst of all: companies have decided that it's better economically to release buggy products sooner rather than better products later. The consumers for some reason tolerate this situation because they don't realize that it doesn't have to be this way. They just accept buggy software as a fact of life. If consumers demanded better software, they'd get better software. Add it all up and it's like elephants fucking: it's not pretty or elegant, but it's a miracle that it works at all.
Admit nothing, deny everything and make counter-accusations.
IMO, the biggest reason for sucky software (and a reason that I haven't seen mentioned yet), is the *lack* of market pressure for quality software. Lets face it, users are at a point of almost expecting their apps to crash. Thanks to the lack of robustness of widespead OSes like Win95, the average user has had to deal with enough crashes/inconsistencies and general oddities, that they don't expect much, so thats what alot of companies deliver.
I realize this is a bit of a Catch22, but if users were exposed to more quality (which I think we're starting to see with the stability of Linux being spread to the desktop), then their expectations will rise, and they will begin to demand better software, at which point the software industy will be forced to provide it.
Try Ctrl-Shift-Escape to obtain the Task Manager. It's worked in every version of Windows I've used. I've found that Windows has a keyboard shortcut for pretty much everything in its GUI, and unlike under Linux GUIs, using a mouse isn't 100% essential.
I don't understand that one. I never want to sit in front of my computer and hope it works this time.
Understandable. Perhaps it's more easily understood another way: How much time, effort, and money are you willing to put into the reliability of this app? Is 99% enough (quick and dirty hack), 99.9 (some actual engineering), 99.99999 (detailed regression analysis of every posable input and verification that the output is correct, multiple redundant everything, years of work and still not 100%).
The answer depends on what the software does. If it maintains your life support it MIGHT be in the many nines category or you might decide it's better to go for 99.9 and provide manual controls (the Mir approach). It might be software to fly a negative stability jet that cannot be controled manually at all. In that case, the 99.9 solution won't work.
If it's just a 1 time need to process some text file, 99% is overkill. Just bang it out in awk, sed, or perl and call it good.
I don't want my browser to ever mis-format anything or crash, but I'm not willing to pay $1000 for that.
I'm surprised to see so few references to UML. What is mostly missing in any software systems these days is good design and the approach that just because you can do it, doesn't mean you have to. So many products these days are busting full of useless features that only undermine the underlying reliability of them.
In these days of 'internet time', people say they don't have time to design their systems properly - and look what happens!!
It's like if a carpenter only could use the screwdriver.
A programmer can never be a real programmer if he doesn't have the experience from at least one other language.
I really believe that good experience in multiple tools make a better programmer.
http://www.millnet.se/ GO/U d- s+:+ a C++ UL++++ P- L+++ E W+++ N+ w++ M-- PE+ t+ X++
I think that should be John Baez.
Exactly. I saw this guy on ZDTV's show "Big Thinkers". He talked almost completely in glittering genaralities about how virtual reality was going to change the world. And the statement that "software sucks" is anything but new. In 1975, a guy named Fred Brooks described a "Software Crisis", and there were many people declaring the same thing before that. In the 90's author Steve McConnell sold millions of books that declared "software sucks". Everything old is new again. Does Jaron Lanier really consider himself a visionary?
What I found most interesting about this article (and I have read the original Edge paper, too) is that Jason Lanier believes that Unix's "Command Line" somehow pervades the whole operating system, forcing a structure and perhaps attitude onto all higher layers of the the operating system. Needless to say, he doesn't like that structure much (although he probably understands the Unix CLI much better than most people here.)
.png files, raw 600-dpi scans that are 100MB each. And then I have another directory of .png files that are all 256 x 256 textures for a 3-D game.
But nonetheless, I think he's wrong. I can give two counterexamples that show that the Unix command line structure does NOT force a "Unix-y" structure in a GUI:
1. OS-X (Macintosh Aqua on BSD).
2. Quake III (Easy to use UI that looks and works the same on Windows, Linux, and Macintosh.)
I think the real straitjacket that UI designers on Linux constantly have to fight against is X Windows, which is my favorite candidate for "What's Worst About Unix". I don't want to rant about that right now. I have a different rant.
I would like to see Linux innovate more, and I agree with Jason Lanier that some real user interface capabilities do depend on the lower level properties of the system. For example, both Windows and Linux both essentially understand the "type" of a file by looking at the last few letters of the file name: ".exe" or ".tar.gz". At least Linux has a separate attribute for "executable", but still, this is a pretty pathetic way to identify files. A step in the right direction would be to store a little extra information in the file system, like the mime-type of the file, and the name of the program that created it. User interfaces could put that information to really good use.
Given a directory full of pictures, some with the extension ".jpg", and some with ".png", at least the user interface can guess that they are all graphics. But what if you put a new file in the directory and mistype the name, calling it "pgn". Well then, it won't show up in dialog boxes that are looking for graphics files, and when you double-click on it in a file manager, who knows what will happen? Mime-types in the file system would fix this.
Another example: Suppose I have one collection of really huge
Right now, if I double-click on these in a file manager the same program will be used to open both of them. But I might want to use different programs to view and edit these files. Having to open the program first and then hit the File,Open,Browse, view another list, select the file, etc. when I was just looking at it in the file manager is stupid.
So that's one example of how Linux could innovate. Of course Macintosh fans are snickering right now. I suppose "Resource Forks" can do this sort of thing. I wonder how those are implemented on the OS-X file system?
So how about we put mime-types and other useful data into one of the new filesystems - ReiserFS, Ext3... Journaling is not the only improvement to file systems worth doing.
Torrey Hoffman (Azog)
Torrey Hoffman (Azog)
"HTML needs a rant tag" - Alan Cox
Ironically, Linux gets an "F" in this regard, or at best a "D", and Windows gets an "A". The API documentation in Linux is effectively absent. I know I'd be a whole lot more productive if I had as good documentation as what Windows programmers take for granted.
--
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
^
In the font that AOL 3 used, it worked out perfectly. However, in AOL 4, they bumped up the font size. Oh well, those were the good old days.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
I'm not so sure the hardware realm is as pure as it seems. I'm far from a hardware designer, but I've perused some of the Linux kernel source and have seen many comments about broken hardware designs. Of course, the obvious examples are probably the various Pentium bugs (FDIV, FOOF, etc.) but I was initially thinking of my (t)rusty Intel etherexpress board.
Maybe it doesn't matter to anyone other than driver writers, since performance is improving.
In other words, bad design or implementation impacts users of the interface that an object provides. So a crappy piece of hardware gives headaches to driver writers, but a buggy word processor gives headaches to end users (and their IT support staff...)
This isn't exactly an apt analogy when applied to the IT field. We're probably always going to need brain surgeons. Tattooing is thousands of years old and shows no signs of slowing down anytime soon. On the other hand, how many applications, programming languages, and other concepts have fallen by the wayside - Some over the course of a month or two? Programmers MUST be generalists, or they're likely to wind up flipping burgers or answering telephones all day long after having the system they've based their careers on become obsolete overnight.
-PARANOIA is fun. D20 is not fun. The Computer says so.
-The Computer
UNIX is not for everyone. UNIX is apparently not for you.
But as for the ease of installation, I too have installed windows many times, and redhat a couple times. Redhat is easier! (I'm talking about the graphical install here).
It autodetects the things it should (including video card settings), then I pick the packages and it installs. Unlike windows where I have to come check on the install and see if it needs to be rebooted yet again.
UNIX may offer you nothing... but to those of us who have studied computer science, it is a really good fit. Windows is dumbed-down so that you don't need to know anything to use it, and that holds you back. With Unix, once you get over the learning curve (and there is a learning curve, even for geeks), the OS actually lets you do what you need to do.
Unix is not an OS for the mainstream, and quite likely never will be, despite redhat, KDE, gnome, etc. But for some people Unix beats any other OS out there hands down.
Lanier say software sucks but does not explain how or why it sucks and never gives any sugestions on how to fix the situation. Instead, he avoids justifying his opinion, by making a new observation that "Maybe we have a language problem," which starts his premise that "software" is too vague a description of what programmers do [I would argue that all doctors practice "medicine" and why is that different from the vagueness of "software"? But I digress]. I must admit this is an interesting premise but he provides no sugestions for improvement. This article has a lot of talk but little substance. It reminds me of talk/complaints around the water cooler/coffee-maker where people get together and talk about how the world should be "fixed" but give little insight to real solutions.
I miss the Karma Whores.
next time don't double-paste your stolen commentary. quite annoying for those of us who actually want to read intelligent conversation.
--
"Don't trolls get tired?"
UNIX is not for everyone. Its not an operating system I would give to my mother. The user interface is a bit harsh to non-computer types. At the same time, I am a software developer. I like UNIX not because it makes me feel cool or for bragging rights. I use it because the OS fits like a glove, for what I do.
There are tons of things UNIX and the various technologies surrounding the UNIX platform do for me in my daily life that make me 150% more productive than if I were on another platform. For those who never experienced it, I like VMS for similar reasons. (and I'm not the guy who's been doing it for the last 20 years, I've only been in the industry for 3 years in my mid-20's)
The problem is that no other modern OS I've used has provided me the tools I need out of the box that I get with Linux or any other variety of UNIX. Then again, I'm on slashdot, so I guess many of you already realize this this...
Oh yeah, one last thought. We had some hardware fail a week or so back resulting in some harsh data corruption. It took a day to bring the stuff back because of the tools and services available in the OS. If this had been a different operating system, we would have probably been dead for a week. And while you can get a lot of UNIX power-tools for your Windows desktop, in a panic situation, you don't want to have to find the software and hope it works.
Gimme a better OS Mr. Lanier if you'd like, but know that mine works fine... I do find it amazing that its still the best thing to come around in 30 years, but then again that speaks to the if its not broken don't fix it philosophy or the fact that it is a very good operating system for some.
-- A computer without COBOL and Fortran is like a piece of chocolate cake without ketchup and mustard
Two points
/usr/local/bin/pico
/usr/bin/elvis
you dont Have to compress the kernel..
its just a make option when compiling.
and there are two levels to compress kernels (zImage and bzImage)
The reason this is done us because intel hardware has to load the boot strap code into a very small chunk of memory from a usually small chunk of HD space. (Unfortunatly i dont know the HD limit off the top of my head)
If it doesnt fit, it gets cut.
It would be More work and much slower to have two parts of the kernel, one a kerel to boot and be small, Yet still know how to read a disk, operate on all known disk io cards, be able to talk to all types of harddrives, and speak a few filesystem formats, just so that it can read a silly 1mb kernel off of the disk someplace whos job its suppost to be to do all of that anyway.
As for the text editor
dont use emacs if its too bloat for you.
Unstripped bins are:
-rwxr-xr-x 1 root root 521016 Mar 4 2000
-rwxr-xr-x 1 root bin 294116 Apr 14 1999
(elvis being a vi clone)
hardly the multi-meg binarys you claim.. and after stripping the symbols im sure they would be smaller yet.
As for complaints on vi's UI, use pico. its more featured than notepad.exe on windows.
vi was designed back when hardware was Very limited, and it did its job overly well. Its only around to day because alot of people that grew up with unix had to learn it, and its just still there.
However id recomend learning vi as much as i would learning mke2fs commandline switches.
(Read: Only if you want or need to know)
[snip - stuff about using point and click instead of command line]
So you tell your roommate: "Get rid of all the old fruit and all the purple fruit."
Surely you've just provided a counter example to your own argument?
to use SQL as a language since it seems most appropriate
DELETE FROM fruit WHERE how_old > 7 and color = 'purple';
To do this with a GUI would be
Select the fruit you wish to delete
Delete the selected fruits.
A more human example, the CLI is you telling your roommate to remove the old purple fruit, the GUI is you telling your roommate to sort the fruit into age order, then pointing out which ones he needs to throw out.
Which is more effcient to you?
[By the way, I think that some things are best done with a GUI, drawing programs for example, it's just you picked one of the worst examples you could to use].
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. (Einstein)
And if it's running windows, you get an extra "Blue-Screened Monitor Paperweight" at no additional charge!
--The space between my ears was intentionally left blank--
Yup! Zork was my inspiration for everything, although any NLP shell should allow for the addition of new predicates, otherwise it's not real advantage, since you're still stuck using a limited form of communication. :)
...why are all those files dated May Day 1999?
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
I was in a position where I was hiring C developers about 3 years ago. As a part of the interview I would ask them to write the library function strcpy(). Out of 10 People claiming to have 5 years of C coding experience about 3 could do this simple problem. I usually asked those 3 people to then do the same using pointer notation. That left about 2 out of 10 C developers who could write strcpy().
With that level of skill out there you have to be lucky to put together a good team.
The other thing that I think is a problem is that some of the slick new development environments allow developers to build things that are way beyond their skill level. So at first things look very good, but then in the end the the cracks start to show in the veneer.
Humans are NOT exact things - computer/human interfaces should be designed to interact with humans, not humans having to be trained to become explicit and precise.
Dear GOD, this is the most insightful and true thing I've ever seen on this topic. And I'm not being sarcastic; I agree completely.
One of the most frequent things I've noticed is that Windows has a thing about not installing networkcards right.
I have on several occations had the standard install put networkcards on IRQ 3, which is supposed to be reserved for COM2. This can cause no end of problems if you attempt to use the card and modem at the same time.
And the worst part is that Windows doesn't recognice it as an error. Even if you study the System menu it claims that "all is just fine". You have to go and edit the actual values by hand to make it work.
Given a directory full of pictures, some with the extension ".jpg", and some with ".png", at least the user interface can guess that they are all graphics. But what if you put a new file in the directory and mistype the name, calling it "pgn". Well then, it won't show up in dialog boxes that are looking for graphics files, and when you double-click on it in a file manager, who knows what will happen? Mime-types in the file system would fix this.
What if you give the file the wrong mime type of image/pgn? huh? Garbage in, garbage out; it doesn't matter if I store the info in the meta data or in the filename.
What meta information should be stored? I don't think we'll come to agreement, so why not store as little as possible and make up for it else where, like the filemanager.
Your difficulty opening files sounds like a filemanager problem, not a filesystem problem. Would the "Open With..." functionality of Win95 explorer satisfy your need to open the same file types in multiple tools? (Notice, that's not a filesystem feature, it's a filemanager feature.)
Joe
Joe Batt Solid Design
So use a Tcl/Tk script that simply execs CLI programs.
You can put a GUI on top of many CLIs; you'll probably lose pipes unless you've got a darn GOOD GUI system, but it'll work. Take user adding/removing, for instance; on many Linux distros, you can use control-panel-type utilities to do this -- but you can still use a text editor or Perl script, because the GUI's merely a front-end.
You generally can't trivally make a CLI out of a GUI if the GUI author didn't give you one.
Only the dead have seen the end of war.
I think that you are right about the design issue. When we are taught computer science, that is stressed very heavily, and you spend most of your time designing software, and working out logic, flow of information, data structures, etc...
But that is not how the software that _people use_ is built. Many companies have discovered that by having a flashy new feature or a higher version number out on the market _faster_ they will attract users like flies to sh*t. The problem is that designing software takes time, and users are antsy and want it now, so they put up with shoddy software (and even hardware) just so they can get the latest feature. I tend to prefer designed programs that i don't have to upgrade every 5 minutes, but then as a programmer i have a skewed view. If i were a normal consumer sort of person, i'd be going ape about the fact that i'm still running a browser that's a version old, and i'm still using a UNIX variant that's built on "30 year old technology". UNIX was designed, people sat down and thought it out before writing it, and that is the only reason it's held up so well; It still solves the problems it was designed to solve. Most people who are constantly cusring UNIX are just not aware that they are asking it to solve problems that would be better solved by some other OS that fits their needs.
That being said, software will get better when the average user demands it. The computing community already knows how to make software that works reliably, stays useful, consistant, and solves the problems it was designed to solve. The problem is that users keep buying software that doesn't work. This may be because they don't know or can't express what problems they really want the computer to solve. The author even states that a lot of his frustration with UNIX (as a good example piece of software) comes from trying to implement VR under UNIX. The trick is that the operating system under a VR rig needs to solve a very different set of problems than the operaying system used for a time-share application server. VR wants realtime, prioritized execution, lots of small asynchronous tasks, wheras UNIX solves the problems it was designed to solve (sharing resources fairly among users, networking, and being a portable base upon which to write software for computational taks). This may be a communication issue between users and developers, or it could be an artifact of agressive marketing and the need to keep users running the upgrade tredmill to keep the bottom line up. In either case, i think that the main problem with software is a human communication issue, from what i've observed.
---
Play Six Pack Man. I
lol. If I had mod points right now, that post would have scored a +1 from me.
It seems to me, hardware is engineered better (or just simply *more*), because the barrier to entry is high. You don't just create a graphics chip by typing at a keyboard. You need a logical design. Written/drawn down, entered through some circuit construction program. You need real physical materials. You need to undergo an expensive process to make those materials into a physical embodiment of your logic. If you screw up, well, back to the drawing board.
Software on the other hand has a very low barrier to entry. Got a compiler? Got an editor? Great. You're now a software "engineer"! Tappity tap. Hello world. Tappity tap. Hello enterprise. Tappity tap. Hello critical infrastructure. It is simply too easy to "just" fix this, or change that. What if every civil engineer decided that they would "just" tweak this or that parameter and see what happens? Or maybe they'd "just" fix the one faulty bolt. It doesn't happen (plus, a major advance of the industrial age was standardized building components, which software still has very little of). Software engineers, managers, and the industry, need to think of the bytes that make up their software as important as an actual constructed, engineered structure, that one shouldn't make whimsical changes or additions to without much consideration and peer review. Because literally, badly designed software ends up costing just as much, or more, than real physical structures.
It's 10 PM. Do you know if you're un-American?
...this guy is a great example.
First, the usual false statements ("Ultimately UNIX is a command line system", "UNIX was so primitive in the 70's compared to other systems...")
"CPUs are so ideal...software is such a lagger" If that's true, go build a corporate web page in one day with nothing but transistors, ass. It's been done with development tools on the market today.
Ahem, many UNIX library calls have no CLI influence whatsoever...they existed BEFORE the shell!
Primitive to what systems? DOS? DOS disn't exist in the seventies...digitals' RTX? Quite like DOS really. The call infrastructure is cleaner under UNIX according to most old timers I've talked to.
Windows2000? I've used the win32 api...golly, many of those system calls look like they were lifted right from Unix. Just what OS is so superior to Unix?
What a bunch of fanboy crap. Here's my official response: "Wannabe dreadlock-hairstyled, artificially-color-enhanced-contact-wearing musicians who hang out in tribeca coffee shops yapping about how much software they didn't write sucks...should be shot for being the asses they are"
Anyone wanna refute that?
Treatment, not tyranny. End the drug war and free our American POWs.
See my user info for links.
Jaron has issues with the fact that most software has problems building upon old source (like when you scan your memory in NT4.0 service pack 5 you find: MS-DOS 5.00...) without improving the source.
His article on the edge addresses software brittleness: were if one part of the software is "Broken" the whole package will not run. Until we have supercomputers that have 3 copies of the same process running at the same time (One 10000 ticks ahead, one running normal, one in standby with backup data) there will be issues with software crashes. One bit off can accumulate exponentially in just a few 100 clock cycles (if it is part of the code- data does not matter (ohh no I got a b instead of a c in my word doc!@!)).
If we had a process (graphics process, etc.) running a couple 1000 ticks ahead, we would know when a command we have executed put the smackdown on our computer, and be able to stop the command or bad bit before it hit. This would be possible if we were running Ole' Skool 8088/8086 XT style processes with an OS that monitored the processes with a couple of processes in predict mode- but people prefer to develop newer glitzier packages with more features to utilize all computing power, than using computing power to have backup processes running, and sacrifice a little glamour.
In 15 years, moores law says we get 1024 X the computing power we have now. If someone sacrifices 4X power from apps to OS backup processes, we still get 256 X speed. Interesting to see if there is a split between people pursuing blind speed/good looks and people pursuing stability in platforms. (Sorta the same old argument everyone always has: Stability vs. Kickassatility? Me want Staykickassatility!).
In the distance you hear an ominous moo.
I think actually the kernel is of very high quality, compared to competing operating systems like the windows kernel or the Mac OS system, but it does take a long time for the kernel to get the kinks worked out.
I realized when I got onto the Linux-Kernel mailing list to report a bug in 2.4.0-test a few months ago that people who were less hardcore developers would probably be put off by the process of reporting bugs to the kernel, and suggested this database to the kernel mailing list. It was generally well received.
In the long run, I'd like all of Free Software to be more rigorously tested for quality. This is just a start - but the database source, and parts of the database itself could be reused for other projects.
If you'd like to participate, please email me at crawford@goingware.com
Michael D. Crawford
GoingWare Inc
-- Could you use my software consulting serv
People suck.
People design computers. So, computers suck.
People create operating systems. Thus, operating systems suck.
If a programmer who sucks starts to program on a computer that sucks with an operating system that sucks using a language that sucks in an office environment that sucks while drinking coffee that sucks while reviewing a requirements document that sucks because the language skills of management sucks, then what is the mostly likely end result of his/her effort?
It's freakin' remarkable when anybody does anything right, let alone well, when the banality of the whole suck-ass world is trying to drag you down.
The only thing that we learn from history is that nobody learns anything from history.
It's the programers triangle. Fast Cheap or Good Pick any two and only two.
The premise of your point is valid IMO, as is your list of questions. The problem in my view is that once development teams find out the answers, they have no guidelines for carrying them out.
Here's what I mean: Suppose I figure out my reliability requirement to be 99.999% or better. What then? How does that affect my design and coding? Does that mean I write a catch for every possible exception? Provide a global "re-initialize and start over" routine? Pre-allocate all my memory at the beginning of the program? All of these?
If I were designing hardware in the same circumstances, I would have some standard tools at my disposal for increasing reliability: use redundancy, use highly-tested (read "old") parts, and so on. I still need knowledge and experience in circuit design, of course, but I have guidelines that can help. In the software world, I don't have a lot of support like that. The software patterns movement is going in the right direction, but still has a ways to go.
Here it is:
First, I would like to remind that all the software doesn't suck: the software which is used in plane, car etc. doesn't suck usually.
Well, there are exceptions as reminded by Ariane V demise, but usually the software here is very very high quality!
So software sucks is an "over-generalisation", I would say.
You could say that "consumer oriented software" sucks but it is still not true: many oven, washing-machine, etc have software but they are rarely recalled because of a software problem..
But you can say that software for Personnal Computers (be it PC,Mac,etc) sucks, this is true IMHO.
Why? Because people always go for the less expensive software and hardware..
But I'm writting you for the following sentence:"You can't just slap any arbitrary user interface onto Unix, because Unix dictates its inner self onto all layers that ride atop it.".
Talk about an embarrassing sentence, one word: MacOSX !
X-Windows doesn't belong to Unix, so you can indeed slap whichever user interface you want ontop of Unix!
Sure it is hard work because developing ANY user interface is hard work, but you CAN.
So here Lanier is making a big, big mistake.
********
IMHO Linux won't suck when you're mother will be able to use it of course it should also stay as powerfull and stable..
So I take it there's more freelance hobbyist programmers out there but zero freelance hobbyist QA people? Darn. Wonder if I could make some money doing freelance testing of other people's open source work.
A script that pages you when you get an e-mail from your girlfriend is probably a lot less mission-critical.
You obviously haven't met my girlfriend...
If you moderate me down I shall become more powerful than you can possibly imagine.
The problem in cases of severe failure has been when quality wasn't enforced top-down from upper management. In other words, when the measure of quality was "did we ship on the planned date" the product suffered.
There seems to be an assumption that once the product is out, a company can cover their mistakes with patches and more releases.
To some extent this is true. The first person to market usually wins. But the catch, as shown by Open Source projects, is that the product has to work first. It doesn't need every flashy feature, it just needs to work. This is how you get an initial install base.
When I'm wearing a development hat, it's frustrating to see a date pushed down from marketing along with a list of requirements. Sadly, I haven't seen development shops asked for their input. After all, they know how long it usually takes to build something.
Tell us when you want it, we'll tell you how long it will take to put in each feature so things that would impede the date can be deferred to the next release. Tell us what you want, and we'll tell you when it should be ready.
Another major error is that organizations don't understand the roll of QA. Management views QA as fixing what's broken from development. QA is a house inspector, not a doctor. Developers look at QA as someone trying to break the product and make them look bad. QA's job is simply to assess the stability, functionality, and usability of the product so that management can evaluate the risk of shipping. Sometimes the right business decision is to let something ship with a flaw in it; other times it isn't.
In cases where management has lacked focus and not enforced a degree of quality, I've seen grass-roots movements establish themselves. Interestingly enough, this never works. Not once. Management holds the reins on schedule and budget, so killing unsanctioned quality-based movements is inevitable. The best scenario is perhaps educating upwards, however getting buy-in at all levels is nearly impossible. This means as an employe, you might want to add management's existing viewpoints into the factor of who you want to work for.
The choice between new-features and more-stability almost always falls on new-features, since that's where sales primarily come from. Those who don't understand the principles of software engineering almost always understand the value of a quick buck.
A small number of places I've been at have allowed for quality improvements. The result is always a happier customer base (who now wants upgrades), happier sales and training people -- since they can demo and have things work, and the big payoff is that due to refactoring and better stability it is possible to add new features in less time.
If there's any lesson to walk away with from all this, it's that you must plan for quality and the drive must come from the top down. It is much easier to design quality in than to sift defects out.
If I remember correctly, JavaScript was developed by Microsoft. Originally, it was called LiveScript, but due to the buzz created when Java when it first came out, they renamed it.
If anyone can confirm for sure that it was Netscape, please correct me.
The ivory tower has never had to reach so h
Excuse me?
Your list of questions applies to *any* engineering field. You need to ask the same questions if you're building a bridge. Does this mean that we should try to keep the field of "engineering" from fragmenting? Sorry; it already has.
"Software engineering" (somewhat of an oxymoron, IMHO) will fragment, just like any other field, as the skill sets needed for the various aspects of programming drift apart. Would you want a pacemaker designed by a video game programmer? Would you want a video game designed to medical implant standards?
BTW, your last question is not really a matter of engineering, software or otherwise. How does a pacemaker "decrease the amount of repetitive work that humans have to do"?
--
Welcome to the Turing Tarpit, where everything is possible but nothing interesting is easy.
Ask emulator authors how complex a processor is. While marketing departments talk up the pipelines and cache aspect, it's not very complex at all. It's just a big state machine. Software implementations of processors are very good. But who wants just a processor?
The point is, hardware is split up into discrete packages. Your CD-ROM drive cannot, no matter how much it wants to, write directly into your processor's cache control bits. You cannot edit the value stored in the 13th pipeline status area. They are protected! In hardware, you cannot break the API. It's pins on a chip, there's no other way in to the silicon!
But in software, you can access everything about the API, and 'hack' it. Bleah. Software, to be as safe as hardware, needs full Java-like encapsulation, where you cannot poke inside the box at all.
Furthermore, there are far more varied software components depending on each other than you would ever find in a hardware device. Imagine a desktop computer running a web browser and word-processor. There are thousands of individual widgets in both programs. One requires a TCP/IP stack and network driver underneath that. Both require user-interface APIs which in turn require graphics APIs and input APIs, which in turn require drivers. Just imagine a hardware device with 500 Pentium 4, 120 StrongARMs, 50 Z80s, 20 6502s, 100 MC68000s, 12 different bus protocols, hundreds of ways to access the hardware devices (forget those ATAPI, IDE and SCSI standards...)
In short, even the simplest looking computer system is a nightmare under the hood. Even if I simplified all _my_ code, I would still have far more code running from _other_ people that I cannot change at all. That's why it sucks. Hardware guys have it easy.
Does my bum look big in this?
Sort of correct -- Netscape owns the tech, Sun owns the name. From the Nutscrape 4.74 about: screen.
Contains JavaScript software technology invented and implemented by Netscape Communications Corporation. Copyright © 1994-2000 Netscape Communications Corporation. The JavaScript name is a trademark or registered trademark of Sun Microsystems, Inc. in the United States and other countries and is used under license.
Which brings up the greater point of how stupid the tradename "JavaScript" is. The whole Java!=JavaScript thing confuses people (AFC?) even here on Slashdot, which is supposedly a nerd site.
I'd be happy if Netscape went back to calling it "LiveScript", Microsoft can keep calling it "JScript", and us supposed nerds started calling it by it's proper name: "ECMAScript".
All good points on the practices we "should be" doing, but what about why we're not practicing them?
Do we lack the skills to be quality software developers? Some of us, probably. But the entire software industry not knowing how to create quality software? I don't think so. Even our average software knowledge distributed across a bell-curve would yield more than enough highly savvy types to create powerful and clean software.
Rather, I think we choose to build our software this way.
Why? Because we've learned our trade in an atmosphere of business. Software has been, and still is, seen as a get-rich-quick technology by the business world. "If you can build this in six weeks before ABC corp does, we can take their market share".
Distilling this down to its base, we come to a simple balancing act. More money and fast competition on one end, and higher quality software on the other. Of course software quality would take a second seat to profits - who wouldn't make that decision?
Open source is growing in part because it's based on our satisfaction lobes. We build our software towards quality - because it's satisfying - which keeps us building better software. That's the feedback loop a lot of us are missing - and our software could use.
Tar files retain the date of what they hold. :}
The distribution he installed from compiled those files on that date, and it would seem he had no need to edit them
Generally I frown on "Oh yeah? Write it yourself!" responses but in this case they're appropriate. You think people are opposed to the idea of a new paradigm that makes life perfect? It's just a lot harder to come up with them than it is to sneer at and berate people for doing things the old way.
And having Joan Baez endorse Jaron Lanier's views on software engineering doesn't make me take him more seriously. On the contrary.
Perhaps, but isn't it better to have people comfortable with the desktop, than nothing at all? Most people don't have the time to devote to learning the command line, even if they did want to. Or should computers be made less accessible, rather than more?
A few hundred years ago, only a few people could read or write, now almost everyone can. Perhaps progress will happen in a similar way with computers.
2. Take e3 http://lrp.c0wz.com/files/e3/. It is only 5K as an executable.
You seem to forget that Windows et al have a whole bunch of .dll files that must be in place, so the exe size alone does not tell you too much.
Use The Source, Luke!
When you have to describe a particular method of doing something, do you A. Draw lots of pictures? B. Use numbered steps with words?
/usr/home/myFolder" when all they want to do is "throw myFolder into the trash." /usr/home/myFolder; ls -la". For a majority of the people, and a majority of the time, if I open a folder, I damn well want to look at what's inside it. Why make me spend the effort to do both?
It's all about abstraction. If I wanted to waste my days programming in assembly (the command line) I could. I may get stuff accomplished, I may not. Or I could spend my day using a higher level language like Java/C++/Perl (the gui). In which language would I get more work accomplished? The one with the higher level of abstraction. That's why we have gui's. Most people don't care to "rm -rf
Similarly, opening a folder in a gui is an abstraction on top of the commands "cd
Command lines do have their uses, as do lower level languages, however, people worshipping CLI's above GUI's are strikingly similar to the idiots who feel smart/clever/genius programmers only code with "mov $a,$b add $c,$f,$g jne $1,$2,$3"
You have obviously NEVER taken any CS classes -- because then you'd know how wrong you are. Furthermore the 'principles' of Extreme Programming are pretty common sense and I would bet that MANY code shops practise them. Where I work, I had to run a SLEW of regression tests when I just removed some debugging symbols.
...I have this sneaking suspicion that any abstraction of code -- UML, flowcharts, proofs -- is only that...
/. everyone comments on things they have no base in. no offense to the poster but this really got to me.
What does this mean ? Yes, you can PROVE (read: TRUTH) the correctness of an algorithm, the correctness lives in the proof.
anyone ever notice how on
"...through this door all my dreams come realities, and all my realities become dreams..."
He's just trying to make sense out of something he heard a few years back.
In 1995, someone in an adjacent cubicle got a new computer, set it up, booted it, and sat down to try to get some work done. Three clicks on, they got a BSOD, and reflexively blurted out -Lanier has been trying to make sense of that event ever since.
--
Sheesh, evil *and* a jerk. -- Jade
Yes, but when I drive my car, do I *TALK* to it? No, I use appropriate controlling devices for the situation: a steering wheel and pedals. Yet my bicycle handles and pedals are very different. As are airplane controls. The point is, there is no one *perfect* interface. CLI is just wrong for some things. As is a particular type of GUI, etc.
It's 10 PM. Do you know if you're un-American?
Both you and your pro-GUI respondents are entirely correct.
When one wishes to converse/command, one talks or writes.
When one wishes to wield a tool, one grabs it and manipulates it.
What is the right way to use a computer? I don't know, but I bet it involves each of them at different times.
"You can't get something for nothing." - my grandfather, on the stock market and Reaganomics.
... is because he is partially correct.
:)
:-(
Most software does suck. (You'll have to forgive me if I tar all software with one brush.) Windows has it's problems, Linux has its problems. Anyone who can't critically analyse the deficiencies in their favorite software is either living in a dream world, a zealot, or blind. (No flames intended.)
The root of the problem is: bloat.
Every time we get faster hardware, we build bigger programs. We're doing so much more with the hardware nowadays -- who was doing speech recognition 20 years ago? Heck, we can partially do it in real-time now ! The latest 3D games are certainly a good example of this. Lots of nice eye-candy. *cough* Alice *cough*
The software we are building, is MANY MANY times more complicated then a 740. And the fact that we don't have off-the-shelf standarized components certainly doesn't help.
Which leads me to my next point:
The software has SO many code paths, there is NO way we can verify and spend enough time on quality assurance. And there will ALWAYS be bugs in the code we write. That sucks just as much as the bugs do.
Lastly, how many programs spend and designate time to develop a good user interface. That's also part of the problem - too many programmers (open source/closed source, doesn't matter) couldn't put together a good gui layout if their life depended on it. How many have taken a UI design course? How many are asking management to allocate time in the schedule for "polish." (As a game developer I'm just as guilty. Beta = fix all the important bugs, and ignore the small ones since we don't have time to correct it. Maybe we'll do a patch, if not. Next game to start developing.)
And I think the greatest tradegy of all, is that people have come to expect computers as being unreliable.
Why can't we apply and have a "process for engineering high quality software" ? Is code that nebulous? Is it because we keep over-complicating the systems?
People aren't perfect, which means code isn't either. But it wouldn't hurt if more people took the time to say "how can I write this code, so it's easier to maintain, and something to be proud of, instead of something that is hacked together, works, and would be an embarrasment to show to your peers."
What are other people's views?
I just had to respond to the Star Trek posit. While I agree with the person who responded that "*duh* it's a story..." I've often wondered about how a starship computer would work.
WARNING: Heavy-duty offtopicness ahead.
As best I can figure, the computer is always listening. (Insert paranoid privacy concerns here.) It has some sort of Natural Language Processor which allows it to guess when it is being addressed or when someone else is being addressed. It is also making the call when Picard stands and says "Cmdr. Data..." and Data comes over the comm system without Picard ever touching his comm badge.
This isn't terribly unrealistic with the right amount of computer programming. The computer simply has to understand language enough to make educated guesses about when it's being addressed. And there's a default: whenever someone says "Computer: " with the right intonation, the computer waits for a command.
Of course, the testing of this would certainly take many years. Remember that Kirk and company had to press on a glorified intercom button to actually address the computer.
<ontopic>
I found the piece rather fluffy myself. There are a few good points here and there, though. But it misses a huge problem. The reason that help desks are necessary is because humans interact with software. By and large, human beings don't touch hardware.
Think of a wrench. There's really only a few things you can do with it. One of the biggest booms in PC sales has come from the model of "pull it out of the box, plug in two or three things and you're ready to go!" The hardware interface has been completely simplified. There's not much you can do outside of it.
Software on the other hand (and this is due as much to feature bloat as other things) requires designers to try to figure out the dumbass things that people are going to do. Wrench makers don't really have to anticipate people using wrenches as hammers, forks or remote controls. But software designers have to deal with the possibility that the user won't do what is supposed to happen, but instead does something illogically or out of order. It hurts to try to think stupidly.
</ontopic>
copy file_1.txt as file_2.txt, print it, and delete it
The problem you have here is that "it" is ambiguous. Which interpretation do you want, copy file_1.txt as file_2.txt, print file_1.txt, and delete file_1.txt, or copy file_1.txt as file2.txt, print file_2.txt, and delete file_2.txt? Frankly, even as a fluent English speaker, I'm not sure which "it" you are referring to!
As a result, you need to tack on the precise file name. Which, as you can see, doesn't result in a command which is drastically different from the UNIX command:
cp file_1.txt file_2.txt; lpr file_1.txt; rm file_1.txt
Put a few alias in (alias copy cp, alias print lpr, alias delete rm), and you can get a command line of:
copy file_1.txt file_2.txt; print file_1.txt; delete file_1.txt
Is it really that much worse than your plain-English equivalent?
--
> What's the average age of a gung-ho Open Source development team? 21? ... I'm not talking about old standbys like Perl and Apache and so on
Are you saying that if you filter out the projects where the average age of the developers is older, you are left with an average age of 21 on the unfiltered projects?
--
Sheesh, evil *and* a jerk. -- Jade
>Armed Forces
The consequences of a mistake may well be higher in these occupations but not the level of accuracy required.
This wasn't a whine, I appreciate that other careers are as hard, or harder than software development, I wouldn't want to be a surgeon for example where the consequences of a mistake could mean someones life. My point (possibly badly made) was that in software development there is no error so small that it's not noticed, you either get code *right or wrong*. Even a surgeon has some slight leeway in where to cut.
Anyway, the point is not to whine, it's to say that I don't think software does suck, I think that the error rate is actually remarkable low considering the difficulty in avoiding errors.
Sig is taking a break!
Unix is nothing more than 32-bit DOS, only MS-DOS is far easier to work with. What good does all this potential that Unix has offer to me if I need to study computer science to make it work?
I read his article in Wired magazine a month or so ago, and my immediate impression was that he is a little bit pedantic, very smart, but somewhat hard to understand (like Katz? maybe). I really felt the urge to hold him to one of his points and have him explain what seem to be feelings on his part more than insightful near-certainties. Which is okay! We are feeling our way through software development, and it is a dark and murky place. I got some benefit out of reading it: I remember getting the same creepy, ominous feeling that I got when I read Bill Joy's GNR (genetics-nanotech-robotics) essay... that things are bad because they are out of control. And this: that our belief in AI has led to that stupid MS paperclip that always wants to help me but instead annoys the crap out of me.
His concept of a hierarchy in software design has great merit, and should be explored further. I recall being able to do all my engineering in DEC VAXes using DCL (Digital Control Language) running FORTRAN. Then they took that platform away faster than they took away vinyl record albums (but not as fast as 8-track tapes). For years I struggled to get a platform on the PC with as much power as DCL. All I got was DOS command files, woefully inadequate to that task. My other alternative was to learn MS VBasic, as we don't use Unix on our PCs. My point? Software development currently is subject to the winds of business logic, and unless his hierarchical, tiered strategy (this concept could use a lot of fleshing out, as do a lot of Lanier's points) shows benefit to a corporate bottom line (which is always short-sighted), it will not be adopted. Some fledgling company might come up with a new OS, a whole new concept of how to use the hardware. But the business world has to allow and provide for that, and right now we got a 300-pound gorilla sitting on top of it all running the show.
SDMI: Finally! Music that won't rip or burn! Brought to you by the fine folks at RIAA.
I unfortunately have to work within a Windoze NT environment and am charged with the task to automate systems, test gear, etc... More often than not, a piece of software for a given piece of test equipment refers itself as automated when it is only automated within its own context!
What this means is that if you open their GUI, and use their scripting system, and press GO, their script will drive a single piece of test gear to assist in analyzing/reporting/recording/testing whatever it is that is being tested. This is their idea of automation. When I talk with the vendors, the whole idea of being able to correlate the Device Under Test (DUT) conditions with their test system is utterly foreign. In some cases, I have been asked (in the case of a bulk call generator) is why nobody else seems to need this functionality? Everything that a person could ever need was within their GUI.
Generally, the GUI idea has abstracted far too many ideas into point and click. This may be fine for people who don't want to know too much, but for me, I'd love to be able to (ignore the DOS prompt)
C:\acquire_data | tee excel -file mytemplate mail -user glebite | error_filter_tool
Or, instead of using a vendor's GUI, to do even the following:
C:\vendor-tool -file myscript > excel -file mytemplate
Yeah - keep the GUI, but please leave us a command line interface to the tool... This abstraction is my firm belief as to why most software sucks...
Thanks...
I donate all spillover Karma to the charity of my choice... Ada was still a babe despite what people may say...
> If anyone can think of another field where a
/one/ mistake in your life and you could wind up on the wrong side of the law. It happened to me. (No, not really. But it could. You see my point?)
> mistake of a single mistake in hundreds or
> thousands of hours work is considered a bad
> record, I'd be suprised.
Surgery
Armed Forces
Even fields like science, anthropology, etc.
And it's not just careers - you make
Don't whine about your lot in life or how nobody understands how difficult your life is. I am tempted to do the same, and so is everybody else.
My other sig is also a
pov-ray creates it's images based on an interpreted language (Yes, it's not a CLI as such but neither would you create an image with a graphical shell so I took your allusion to somewhere sane).
Many times with a technical illustration, I've wished I could create an image with words ("box 0,0,3.5,2;circle 3.5,2,1" would be so much easier than "try and draw a box to the right dimensions with mouse, try and center circle somwhere on the top right corner of the box. Guides are a help but start to fall down with anything complex.
Rich
I've seen solid hardware from several different vendors that almost does exactly what it is supposed to... but even that is usually the third time (or more) that the chip has been put in silicon (whether full A-RITs or just more B-RITs, for those who understand that TLA).
Hardware, especially in a development cycle, is a moving target - granted, the changes don't happen as quickly as a code rebuild, but often the subtleties are a lot harder to notice...
--
"It's tough to be bilingual when you get hit in the head."
So why, if I may ask, does open source projects suffer from the same problems?
No, this is not flamebait. This is for real -- although there are a few open source projects out there that really shine, you've to admit a lot of open source projects are kinda buggy, and seem to suffer from the same problems as proprietary software (although you could argue they are less so because problems are easier to fix when anyone can see the source -- but the problems are still there). And this is for people who are coding because they like it, not because they are under pressure.
I think there's more to software quality than just pressure from upper management, etc.. Like other posters have said, and like the article said, there must be something more fundamental about software that we still don't quite grasp.
Poll Mastah
Baloney. Depending on the complexity of an application, and the cost associated with failure, and the possible causes of that failure, you will require wildly different architectures. Those silly web aps are on one end of the scale, with Air Traffic Control on the other in terms of complexity and potential damage. Not only that, but a web app usually only has to not crash itself, take care of user input (if any) and any web connections it might require. Air Traffic Control has to be concerned with distributed hardware, user interface design, wide area communication, possibly out of date information, possibly wrong information, hardware or communication failures that might or might not be detectable, etc. etc. etc., and if the system responds in the wrong way, people die. You might notice that in the above list, most of the failures were outside the control of the system, but the system is still expected to react gracefully and safely, because the cost of getting it wrong is so high.
Forget pacemakers -- that's easy. Think Air Traffic Control systems -- billions and counting, and it the new one still does not work.
I'll bet there is enough blame to go around, some for the FAA, some for the contractors, some for the managers, some for the programmers.
There's a lot less tolerance of crap in digital design. We all b!tch and moan when Intel has an internal floating-point error, and scream for recalls, but we accept blue screens and core dumps on a daily basis. The evolutionary pressures on hardware have been much more quality-driven than software, where features seem to be the main driver (IMHO).
I love vegetarians - some of my favorite foods are vegetarians.
First of all, "All operating systems" doesn't mean Unix and Win*.
I've considered this point quite a bit over the years. There is no way of a GUI getting entirely away from the command line as long as the base OS is still based on the command line. None!
The other side of the coin is that the command line falls naturally into place with a heirarchal file system. As long as we have the one, we'll have the other.
The Macintosh (of all things!) did it right in many ways. The command line is an extra tool--not the base level of the operating system. The Mac GUI _is_ the OS, to a greater degree than any other system out there.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
Cruising at +1, and on this topic, I'm a little surprised to find that this was the only reference to Ada.
Ada gets a bad rap for it's roots in government, its verbosity, and the rather straitjacket nature of strict typing. But guess what... it wasn't designed for rapid programming, or to make programming easy. Ada was designed for the 20+ year lifetime that code may well have after it's put into use.
The same things that slow the start of coding help the lifetime and maintenance. It takes the willingness to accept some discipline and take a longer-term view.
Think of the people who never thought their code would survive to Y2K.
The living have better things to do than to continue hating the dead.
I know it's bad taste to follow up to one's own post, ...
but has anyone tried eXtreme Programming? (Has it worked? What worked well? What didn't work that good?)
If important software projects used licensed Engineers instead of unaccountable coders, there'd be a lot less important mistakes. Making someone professionally responsable for their team or code is a great way to improve quality. It's common sense and every first year Engineering student is beaten over the head with this fact. Accountability is the best policy.
DataSquid.net, all the UW Computer Engineering you can eat.
DataSquid.net, a little about me.
\rant /.?
Why do liberal arts people read
\\
deleting multiple folders are one of the things that are much easier in UNIX than Windows.
Children use Macintosh because Steve Jobs and Co. decided to stuff these machines decades ago. (smart move, they know that most grade school teachers are simple too lazy to learn new things.)
Can you imagine children are taught command line? For those of us who started using command line early in our childhood, we are the living proof that children are less afraid of command line than adults. they will beat thier teachers in a short period of time. Bussinessmen, however, hate to learn anything; they'd pay, they'd sacrifice productivity in order not to learn new things. which is why GUI's are so popular in bussiness.
I think children are supposed to be taught to use computers in command line; the hard part is to train the teachers.
OK. But a CD player is called on only to do a small number of tasks. Most cd player apps for computers duplicate a similar interface. I think the issue becomes how you handle more complex stuff.
Who is to say that a command line driven cd player wouldn't be better (or a better example, a cd jukebox or mp3 player with lots of storage).
Pushing icons one after another would imho be far more cumbersome than simply typing (or saying)
mp3> play all songs by Nirvana in random order followed by the predefined mix entitled "punk-party mix", then around 2:30 AM switch to the predifined mix entitled "bach-piano-concertos"
The challenge is to devise a command line language that is both intuitive and powerful -- such projects as the latin perl project offer some hope in this regard.
The command line has gotten a very bum rap, primarilly because no thought went into devising a coherent language. Instead cl languages have consisted of a small collection of arbitary commands, akin to the grunts and gestures of our cave dwelling ancesters.
I find it more than a little ironic that, as computers take on more and more capaabilities, the language the users uses to interact with them becomes more and more dumbed down. I suspect we are going down the path where we replace alphabets with pictograms because pictures are easier for an illiterate to grasp, only to discover that, when that same user later wishes to write a novel, they are forced to use something akin to egyption heiroglyphs in order to communicate their ideas: a writing form vastly more complex and difficult to use than the 26 letter alphabet the illiterate in question should have just learned in the first place.
The Future of Human Evolution: Autonomy
But don't forget that if it wasn't for software, all of our boxes would be silicon paperweights. ;)
--The space between my ears was intentionally left blank--
Hear, hear!
I learned programming by reading Niklaus Wirth's classic introduction to programming via Pascal. In that he differentiates between two activities : programming and coding. Programming, as defined by Wirth, is the art / technique of finding a solution to a problem using computers. Coding is the implementation of that solution using a programming language. IMHO, most of the problems with software today stems from too many coders (who think incorrectly that they are programmers) and too few programmers.
Informal hacks do have their place. If I am trying to debug a production problem by sifting through 100's of megabytes of data, I am not going to go through a design, code and review process for any data analysis scripts that I write. This is where languages like PERL shine. Unfortunately, coders have decided that the same (absence of) engineering rigour they use in creating informal hacks can be used when developing entire applications. This is why a lot of applications today look and feel like informal hacks. Sadly, most such developers do arise from the PERL community - but PERL itself is not to blame. If engineered correctly, you can write quality software even in PERL.
People who state loudly that a lack of formal training in CS disciplines matters not in application development, havent understood that the biggest payoff from such an education comes from a sense of engineering instilled into the student. Without that, quality software is a random event.
There is no such thing as luck. Luck is nothing but an absence of bad luck.
Sorry, but this is just a big load of carp. The command line is *not* intuitive for anyone unless they've been immersed in it for so long that they've forgotten what the sun looks like. If I had to tell someone how to build a guitar, I wouldn't give them just words, I would have tons of diagrams to more quickly convey how things should be set up. When I want to move things on my desk, I move them with my hands. I don't think of the equililent lingual syntax for how I want them arranged, I just do it. This is the same way decent GUI's can handle file management - if you want a file moved, drag it from point A to point B. I don't know what world you live in, but if you can describe a process quickly and efficiently with *only* words, it's not that complicated of a process.
There are times where a command line is more *efficient*, but this is not the same thing as natural. The lack of efficiency in most of the GUI's today isn't because a GUI is inherently bad, it's just not flexible enough. Ideally I should be able to hit a key, punch in a perl script, and have the OS run it right there, or at the exact same prompt be able to drag things around and have the OS know what I "mean".
If you've ever tried to fix someone's computer over the phone, or played pictionary, it's clear that only having text, or only having pictures, is not sufficient.
Just look at my sig:
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
"Cars today really suck. I mean, they're basically the same as they were 50 years ago, with four wheels and an engine. They even still have headlights!"
Marcus is famous for his drawings and paintings of various flying cars and personal jetpacks, which he was convinced would be here by now.
"Look at it this way," he says, shifting his massive belly and accidentally knocking over his "King Cobra" bottle into the gutter, "Car factories are so much more advanced now. They have robots and just-in-time parts supplies. The paints they use on cars are more durable and shinier, but with all these resources, no one has managed to build a flying car!"
"I used to draw cars in the 50s with turbofans and micro-atomic generators, but it was hard to do that with 'pencils' and 'paper'. I recently visited the PS Art Department, and you know what I saw them using? Pencils and paper!"
"Here it is, 50 years later and I still haven't got to make it in the back seat of a flying car," Marcus' eyes get a little watery as he turns and looks at the scarlet sunset. I can almost see the swarms of flying atomic cars that he imagines, their fins glistening in the last light of the day.
All kings is mostly rapscallions. -Mark Twain, The Adventures of Huckleberry Finn
I'm betting you'll find just as many closed-source projects that are as bad, if not worse. Open-source is not a magical cure for all your coding woes, but it does help with a lot of things and has many high points. As you pointed out, Perl and Apache are well-engineered, as are the Linux and/or BSD kernels (dependant on opinion, though) and many other standard tools.
Yes, there are bad open-source projects started by people who are 20 or 21, but consider how much they'll probably learn in the course of those projects. Especially if some more experienced programmers get interested and start showing them ways to improve their processes and code.
-RickHunter
It appears he hates Unix, not software as such. But he makes the same error as most other who do, he equates newbie unfriendly with user unfriendly. Which are not the same at all.
To be sure, different parts of software have different needs. If you're designed space shuttle guidance software, go ahead and engineer for five nines (99.999% uptime). A script that pages you when you get an e-mail from your girlfriend is probably a lot less mission-critical.
But the point here is that you want both of them to work. I would argue that from a personal perspective, knowing that your SO e-mailed you is more important than the space shuttle. But, the point is, both should work.
How reliable should the software be?
I don't understand that one. I never want to sit in front of my computer and hope it works this time.
Fragmenting software engineering would have a very poor effect on the development of these base strategies
Fragmenting can't happen until the base strategies are in place. Lanier is arguging that we haven't yet reached the level of having base strategies in place. I would agree with him. The discipline of design has not been hammered into our collective heads yet. The computer makes the leap from thought to code too easy. UML and various OO strategies help to slow down the leap to the computer and give people a chance to think designs over for a bit, which is what is needed. I really view UML as a process of thinking things over rather than software design. It gives you something to do while you think. The end result is a stack of documentation that makes coding easier and has the side benfit of showing that you at least thought about your design long enough to draw some pictures.
then it comes to be that the soothing light at the end of your tunnel is just a freight train coming your way
So, what you're saying is that software sucks.
You should be able to enter 2" by 1" in coreldraw.
You should be able to say to your computer, "format the hard drive - make it 1/3 of available space." Especially if you don't really care exactly how big it is - which most people don't.
The software interfaces do not properly model the way that humans accomplish tasks.
This is probably the biggest growth area I can imagine in software development.
I mean, look at the Easel, KDE and Gnome - Brand new user interface layers, and what are they? More of the same old thing - with different pictures and colors.
Humans are NOT exact things - computer/human interfaces should be designed to interact with humans, not humans having to be trained to become explicit and precise.
Unless you want to maintain a techno-elite, which I think, perhaps, many people here do want to do.
Brushing his trademark dreadlocks off his shoulder, his cobalt blue eyes become a deeper shade of unnatural as a smile finally flickers across his face.
Sounds like a cheap novel or the author may be in love.
> The vast majority of software is a question of implementation, not algorithmic logic. It seems like it's a lot more complicated to prove implementation than algorithms.
Actually, it's rather straightforward for a mechanical prover to read the source code.
> There are currently a very small number of people with both the analytical skills and the severely rational temperment required to do these proofs.
Much of it can be done by machine. Also note that there once was a very small number of people who could write programs, but now millions can. Why not set out on the same path for the methodology of creating formal proofs?
> And that correctness (or, more likely, bugginess) lives in the code, and in the code alone, so that's where you have to weed it out.
Per above, you have proposed a solution to what you thought was the problem.
> It just seems like it'd be no fun.
No one said QA was "fun". The question is, do you take enough pride in your product to make sure it's right? Also, per above, mechanical provers is the way to go.
--
Sheesh, evil *and* a jerk. -- Jade
And if pico isn't powerful enough give nano a try, it's got the same friendly interface with some added features.
I do not have a signature
I think we just need to realize that 100 amateur programmers writing and reviewing code, ad-hoc, is not necessarily better than 10 professional software engineers working closely together, using some semi-formal procedure for specification, requirements, collaberation, and coding.
A lot of the most successful open source projects, were originally created by professional programmers (Unix flavors, including BSD; Apache; Mozilla; GNU utilities in general), and still retain some form of regimentation. Linux would not be were it is if Linus et al. let every single developer add their patches in, or modify code, whenever they wanted. Unfortunately this is exactly what happens in many new open source projects under the banner of "freedom"...which ends up producing remarkably mediocre code.
It's 10 PM. Do you know if you're un-American?
In my dept, we were forced into a "project Managment training" seminar. It was supposed to teach us the wonders of why project management will do wonders for IT, along with the basic skill and concepts of PM.
Two days for intense training, where the Trainer was inundated with typical scenarios in the various sections of our dept, that tried to illustrate to him the inherent problems of PM when upper management doesn't buy into the concepts of the projects.
No problem, most of those in attendance knew exactly what to expect from the training session. Nothing. That is right, nothing! No changes what so ever, mainly because upper management hadn't bought into the concept.
True to form, not even a week later, the Head of the dept, issued a "White Paper" explaining why PM can't work in a "dynamic environment" like IT.
What is the lesson? Even when Managment knows what the problems and solutions are they still hedge all thier bets.
Lack of leadership is the true enemy of any organization.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
If you see what I mean. Everybody can draw a picture of a house. Very few people can paint a masterpiece.
I have read on numerous occasions that the performance of two programmers of equal educational background and experience can vary by as much as 1000%. This is proven in both my own experience and that of another poster who mentioned that only 2 of 10 C programmers he interviewed could code up strcpy().
Software development is a creative discipline, and as such recruitment of programmers should be through auditions, not interviews!
what i got out of this was that Lanier thinks we are stuck in some tech-limbo, one where neither the software nor the laws governing the use of software are very useful. well, that and UNIX is old and ugly. Big deal, people still use it, and that doesn't automatically mean that it sucks.
And his comments about "humanity" not knowing how to make software, or even what software is, were just plain over-dramatic, hippified philosobabble. After all, why is he discussing it then? Is he not a part of humanity? Or, is he better than us mere mortals?
Plenty of people know what software is and how to make it. The focus is to make it more intuitive, faster, and less prone to Bad Design.
sig not found
Hi! This is the Sig, blatantly attached to the end of this comment.
Duh, it's a story, it's *not real* dummy.
If you want some semi-plausible explanation, try that as I recall, they actually address the thing "Computer do this"
And back to your point about instructions in foreign language, you have to remember that the conventions of pictograms are a learned thing as well. There's nothing "natural" about an arrow meaning "this direction" (ask any Floridian) and if you've ever tried to learn something by watching someone do it, if they don't describe what they're doing, it's very easy to get it wrong (e.g. "Insert this rod into this hole but make sure it's the end with the blue mark". If you weren't told, you may not have noticed the blue mark )
There's a reason that Macdonalds cash registers have pictures of food on it while any serious programmer works in words. And that is because words convey more information in a less ambiguous way.
Rich
Well, I think one of the reasons that software sucks is a disparity of ambition and attention span.
I often think of software as a branch of practical philosophy -- at its heart, it is simply applied reasoning. The idea that software engineering is the solution to software quality is as flawed as saying that moral or political reasoning just boils down to plain logic. Logic and software engineering are necessary in their spheres but not sufficent.
A good piece of software is one which is good in many dimensions -- in its data structures, decomposition, architecture and expression, to be sure, but also excellent in other ways:
* Understands the user's characteristics and motivations
* Understnads non-users who are affected by the system.
* Fills a void in the range of available products.
* Peforms well in terms of stroage, speed or latency.
* Utilizes sustainable technology (i.e. is reasonably future proofed with respect to platform and interface issues).
* Has an excellent user interface.
* Has excellent graphical design where appropriate.
* Fulfils any ethical obligations it has (e.g. handling of sensitive private data; protection of human lives).
As an aide, Asimov's Laws of Robotics kind of encapsulate the some of this -- a robot has to follow orders (suitability to task, user interface), a robot may not harm or by inaction allow a person to come to harm (ethical and societal concerns), a robot must protect itself (sustainability and robustness)
Getting back to the issue at hand, the number of dimensions to be optimized is daunting, and requires time and deep thinking -- the kinds of things that go out the window under a deadline or in hierarchical organizations with pressure from superiors with very limited perspectives.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Short of coming up with a new definition, the only hope for improvement is to shove developers' noses in the problem until they finally get the point.
IMHO, neither of these will help.
I've worked with some really brilliant programmers in my time, and those people collarboarted to produce some of the crappiest code you can imagine. All of us knew that what we were doing was going to hurt us in the long run, but we did it anyway--not because we wanted to, but because we were told to.
It's a good developer's natural inclination to take the time to properly design code and not release it until it's ready. Unfortunately, that runs counter to every business and management rule there is.
If you work for pay, your boss is always going to pressure you into taking shortcuts, putting in quick hacks instead of designing real fixes, skimping on documentation, etc. Their main goal is to put out whatever fire is in front of them before their boss gets called in. That situation is repeated at each higher level, and at each level, it's less and less likely that the person making the decisions knows building software from laying bricks. Ultimately, the main direction of your development process is set by people who aren't concerned at all about the quality of the code.
When the process sucks, the code will suck. When the code sucks, the quality will suck. But as long as you keep closing bug reports fast enough, your boss will think you're doing a great job.
IMHO, this is one of the key reasons free (in both senses) software will always drift to a higher quality level than commercial software. Dollars cause bugs. Take the money out of the picture, and the a lot of the incentive to write crap goes away.
That sounds communist, but I don't mean it that way. I simply mean that we should be prepared to accept the inevitable consequences of the way most software is developed today. If you want to change the state of software, either change the incentive, or (since money is an awfully good incentive), change the way that incentive is given.
IMO, the biggest reason for sucky software (and a reason that I haven't seen mentioned yet), is the *lack* of market pressure for quality software. Lets face it, users are at a point of almost expecting their apps to crash.
Should this come as a surprise when software comes with an EULA which disclaims any wartentee, forbids examination, (unapproved) benchmarking, etc?
In the US this position is being bolstered by new laws such as UCITA and DMCA.
Thanks to the lack of robustness of widespead OSes like Win95, the average user has had to deal with enough crashes/inconsistencies and general oddities, that they don't expect much, so thats what alot of companies deliver.
Whilst Windows may or may not be easy to use it is definitly difficult to administer and fault find...
Projects that use the right engineering methods take less time to complete and support, and are therefore cheaper.
It probably is true that the engineers who use these methods are more expensive to hire.
For most people this is how computers should be. They're tools, incredibly complex tools, but the complexity should be hidden behind simple metaphors. It isn't most peoples business to know about how computers do things, only that they do it.
That's true, and false at the same time. I'll go for a car analogy here. Everyone agrees that an automatic transmission is much easier to drive than a manual. Shifting can be made automatic, so why not do so? ABS is another extension of that as well. But one intrinsic law that extends to all facets of life is this: The more options you want, the more complex the device.
Don't believe me? Sure an automatic is easier to drive, but you lose the ability to downshift in bad weather. Sure ABS keeps you from skidding, but for those who've taken defensive driving courses, or want to do trick driving, ABS is just a hinderance. Together, ABS and Automatic Transmission "dumb down" the car, to make it easier. But in doing so, the car can't do as much as before.
Computers are meant to be general purpose tools, to do anything imaginable under software. Try to bulk add/modify 1000 users in an NT environment, I dare you. If you don't have to resort to undocumented features or write your own binary modification routines through MS DLL's, I'll be greatly impressed. Wrappers are just that, they wrap out the harder stuff into nifty little packages. But they also restrict your abilities.
It's simple. So long as computers remain general-purpose do-it-all tools, they'll be hard to use; merely due to the sheer amount of things they're capable of accomplishing. Unless we start phasing computers out, and start introducing very specific tools that do parts of a computer's vast arsinal, that's just the truth. We're already seeing it in digital books (no more downloding text files, and reading them with some software program), email checking hardware (no more chosing an email client, no more pop mail, etc.), and set top boxes for browsing the web.
Seems to me that the future of computers lays in splitting up their abilities among many other devices; that's the only way to simplify. Remember, there are still plenty of people out there who can't even program a VCR. If we just keep making things simpler, we'll be left with one device that does nothing, and has only one large red button. Humans have to pick the slack up somewhere.
--
Shaun Thomas: INN Programmer
Read: Rabbit Rue - Free serial nove
Ada - Lady Ada Byron King... Not the language.
Don't use Ada (the language) at all - but I do have a picture of her and Charles Babbage on my cube wall... And yeah, in the picture - she was a babe...
I donate all spillover Karma to the charity of my choice... Ada was still a babe despite what people may say...
this is bs. at my companies, its the management that gets fired when a project fails, if they could have saved it. the engineers are never blamed for programs failing, unless did things like lie, or acted unethically, or did a crappy job (which does happen).
What was the point of this article? Other than a smattering of buzz words and the general feeling that we got to spend a few moments 'alone' with this fellow, what was the merit? I think it is blatantly obvious that software is in a bad state right now. Why beat a dead horse? I notice that he wasn't offering any solutions, just writing books about how bad it is...
I can't respect that. If he's going to criticize the masses that do their best for their employers and themselves, he should offer some alternative.
Sounds like he's a disgruntled programmer with coders block.
-= Why can't I add 'Anonymous Coward' to my list of Foes? =-
But yes, I think you were right. Magazines are printed in CMYK and have been for a very long time. I was just pointing out that one could mistake Magenta for Red and Cyan for Blue, especially since it's a common, incorrect belief that Red, Yellow, and Blue are the primary colors.
As the author of the article points out, hardware is getting more complex and better. But hardware is designed. It's designed, tested, built upon, etc.
And while we're all taught that we shoudl use proper design for software, few of us take it whole heartedly. Sure, we might do a few object models, flow charts, etc. But how many of us use propositional logic and predicate calculus to prove our software will work as it is intended? And still further, how many of us have unbiased testing of our software?
I think the larger the corporation, the more of these practices might be enforced. But it is still up to the programmer to truly adhere and take these to heart. I don't think we quite have the discrete tools that hardware designers have. Nor do we have the worry that once the circuit is printed, you can't easily "fix" it.
Garbage.
I had to use a W98 machine the other day, and if froze. I'd never used W98, and wanted to kill the task which had disappeared up its own arse.
How do I run the task manager? Or is that "TaskMgr", or "TaskMan", or the other "TaskMan" (NT has 3 executables with that kind of name!).
Right mouse button click on the Task Bar (ooh, "task" bar - may be there's a task manager on it?) failed to offer me a task manager. Crap. Hmm, is there a keyboard method?
In NT it's C-A-Del, but in older Windows that rebooted the system. Dare I press C-A-Del?
Eventually I had to, as there was nothing else I could do. OK it worked, but that was guesssork.
I don't know if it would work on W95, and hope to never find out.
The graphical system - being different in each evolution of Windows, completely failed me.
On a command line Unix system I only need to know 3 things, which have been constant since time immemorial
a) ps b) kill c) if all else fails - man.
Which is easier to learn
"on 3.11 do XYZ, on W98 do ABC with the mouse or PQR with the keyboard, on NT do JKL with the mouse or NMO with the keyboard"
or
"ps then kill"
You've chosen your method. You can have it. I'll chose my own thank you.
(Haha, 32MB video card, and I spend 99% of the time in the text mode consoles, as they are more efficient for me!)
FatPhil
-- Real Men Don't Use Porn. -- Morality In Media Billboards
Also FatPhil on SoylentNews, id 863
I know the reference was to the babe, not the language. But when a thread on software reliability came up, I figured it was a reasonable place to see or say something about Ada - the language. Setting the threshold down (maybe I should have gone to 0) to scan for " ada" I found only the reference to the babe.
Maybe this in itself says something about why software sucks.
The living have better things to do than to continue hating the dead.
When you get home at night, and you MOTAS/roomies ask how your day was, do you
When you have to describe a particular method of doing something, do you
A. Draw lots of pictures?
B. Use numbered steps with words?
I remember a book by an AT&T fellow about data compression and information theory. Two teams had to put together a mechanical device, one team member had the instructions, one had the parts, and they were separated. One team only had an oral link, the other team had video, too. There was no difference in the amount of time needed to build the device, the added video link added nothing.
HDF does Lanier plan to interact with his computers, pretty pictures? Waht ajoke.
> I think we just need to realize that 100 amateur programmers writing and reviewing code, ad-hoc, is not necessarily better than 10 professional software engineers working closely together, using some semi-formal procedure for specification, requirements, collaberation, and coding.
Agreed. But how many of the COTS products loaded onto the average workstation were developed with that degree of professionalism?
--
Sheesh, evil *and* a jerk. -- Jade
Niggly Software
TCP/IP specs, BIND, ipfilter
Jiggly Software
xv,mpeg_play (for viewing pr0n)
Stupid Software
VB, Perl (oh, how the flames roll in...:)
Sexy Software
AI^H^H CD-ROM^H^H^H^H^H^H Web Brows^H^H^H^H^H^H^H^H^H B2C^H^H^H B2B^H^H^H P2P^H^H^H uhh... Gnutella?
Pain in the Ass Software
office integration suites
Soul-sucking, Time-stealing, My-project-will-be-three-months-late Software
Everquest, Quake, Half-Life, Tetris, xboing
Brain-bangingly Tiresome Software
Oracle
Vapor Software
a real GUI for Unix, a command line for Macs, a crash-resistant Windows
Potato chips are a by-yourself food.
Every once and a while I hear/read somebody saying "Unix is 30 years old! Why would anybody want to use something who's design is so old?!" Well, computers themselves havn't really changed all that much in those 30 years either... They still rely on a central CPU with some memory banks, some secondary storage, etc. - just like they did when Unix was created. Of course, they've changed size and shape and general usage, but the computers themselves are still generally the same. So, what's wrong with using an OS that has stayed the same with them?
Posted from the wireless couch.
In my experience, there are only human impediments to successfully creating healthy software. Technologies are sufficiently developed in most languages that most software can be written fairly efficiently using a wealth of frameworks and libraries. So why does software suck?
Combine time-pressures, market pressures, upper-management pressures, and a lack of training and professional standards, and you have a whole class of employee (the project manager) who has only incentives to lie and hedge, and no incentive to be honest about schedule, feature set, state-of-the-project, internal project problems, etc.
Assume a project of 15 people, with a 3 million dollar budget, and a project manager leading four teams. That's pretty complex stuff to manage. Now what if it's business critical, and he's getting letters from board-members and C*O staff imparting the import of the project unto him from on high. Can you say pressure cooker?
Now consider that three developers are fighting, and every teaser this manager has sent up the chain about problems has resulted in a standard "we expect you to solve this on time and on budget" no-help answer.
Now imagine that some contractor or 3rd party vendor that the architect and project manager had made noises about to upper management lied about their capabilities.
Now imagine that his buddy frank was fired three months ago after a fiasco project in their other business line.
Now imagine that he's not vested, but will be vested by the last month of the project.
Now imagine why this person would ever ever ever say there's a slight problem with the project until it's almost over. Or worse, he'll "two week" the project for months over time, over budget, and they'll release buggy, crappy, untested code to the customer in a beta which amounts to an alpha, expecting the customer to catch and report all the bugs.
It's no life at all, and certainly no way to get quality software, but it's a scenario I have seen repeatedly over the last few years.
i - This sig provided by
Software sucks? I've yet to find a driver for my Dyson bagless vacuum cleaner...
-- Soruk
Intelligence is the bottleneck, not age. Anyone can sit down and read Design Patterns, but the temperament must be there.
You're exactly right. We can do both. We can do more than two. We can be as multi-discipline as we damn well please. I am. You are. A lot of people here are.
But there is still a problem.
Most people here will not willingly admit that software design is made up of multiple disciplines. Just because you can make a good web-based app does not mean you can make a good Windows-based app (or vice versa). Just because you're a great kernel hacker doesn't mean you are necesarily a great graphics programmer.
You can be both and more. But software design is not a single discipline. Some people are not good at everything. Some people specialize. And some people should. We should recognize that there are multiple disciplines within the field of software design. That doesn't mean that you and I can't still be multi-disciplinary designers, but treating them as different disciplines could lead us to a better understanding of what we are doing in each of those different disciplines and in software design as a whole.
Particularly the specialization things. Software is too complex and complicated today to learn all of it. While you may be able to learn many fields, none of them well. Specialization will result in higher quality products I think. Another problem is time and deadlines. The industry is moving faster than us developers can keep up with. Resulting in shoddy, untested software. At some point though, it's going to slow down.
-
Actually, most of these questions apply to the design of everything in the world. If I'm building a bridge, a car, a building, a plane, a chair, an adhesive, anything at all, these questions apply. So, by your logic, all design tasks should be subsumed under a single profession: engineering. This whole idea of having "Chemical Engineering" and "Software Engineering" and "Civil Engineering" and "Structural Engineering" just has a poor effect on the base strategies that all engineering tasks share. Right?
The software that runs your pacemaker is not even considered for a moment to be the same sort of entity as the software that you use to write music. ... If your interpretation of software is that it's like a bridge [and] people need to know what they're driving on, then yes, a little peer review could help. If you think of software as literature, if you're somebody like Ted Nelson, say, then what you really want is groups of people who are emboldened to try wild things.
I have a lot of respect for Lanier, and I particularly thought One Half a Manifesto was a useful and badly needed bit of skepticism against what he terms "cybernetic totalism". But I think he's off on this point.
To be sure, different parts of software have different needs. If you're designed space shuttle guidance software, go ahead and engineer for five nines (99.999% uptime). A script that pages you when you get an e-mail from your girlfriend is probably a lot less mission-critical.
But there are certain questions that are useful to the software engineering process, regardless of what code you're writing. To think of a few, off the top of my head:
Every successful software project needs to ask these questions, preferably sooner than later. Fragmenting software engineering would have a very poor effect on the development of these base strategies, so hopefully it'll never happen.
Do domain names matter?
It would be More work and much slower to have two parts of the kernel, one a kerel to boot and be small, Yet still know how to read a disk, operate on all known disk io cards, be able to talk to all types of harddrives, and speak a few filesystem formats, just so that it can read a silly 1mb kernel off of the disk someplace whos job its suppost to be to do all of that anyway.
That's what grub does, it knows filesystems (including reisersfs), will read off partitions > 8M and supports network booting. And it's not slow at all.
And how many of those projects really matter? Do you know how large the software industry is? Do you realize how many commercial products and in-house systems there are that don't follow good development and testing guidelines?
There are two ways you get quality in software: have developers who feel proud about their work and put as much quality in it as time allows, and have developers who are paid to put quality in their software it by management who has enough sense to think beyond a single quarter's expenses.
Right now, the former is a superset of the latter and is probably ten times the size, if not more. In open source projects, the lack of money means everything is by the former, so you end up with really high quality stuff, like Linux and Apache, or crufty stuff that pays a lot of attention to testing, like gcc, perl, and XFree86. It makes perfect sense, since you gotta love what you're doing to work on something for free, or at least, for a fraction of what you could make as a hired gun.
Sure, you also have all the dreck on freshmeat. But since no one was paid to write the dreck, there really is no loss. Most of us are not under the illusion that a weekend project is comparible to production-quality software. Besides, the yung'uns have to start somewhere.
--
Bush's assertion: there ought to be limits to freedom
Yeah, it'll be great when users are exposed to quality stable Linux projects like Netscape. From an end user's perspective, there's no real difference between the operating system being taken out by an application and the X session being taken out by an application. If you're lucky you have another computer in the room so that you can telnet to the locked box and kill X. Otherwise, you have little recourse besides the reset switch when the mouse and keyboard don't respond anymore. Either way you lose any unsaved work in open applications, just like in a Windows crash. When running Linux instead of windows however you run the risk of doing quite a bit of damage to the file system during a reset.
_____________
I don't want free as in beer. I just want free beer.
Not in my experience. Extreme programming is really just a formalized two-person collaboration. If the two programmers want to type different things, then they should probably be at a whiteboard sorting things out.
Veteran, Bermuda Triangle Expeditionary Force, 1992-1951
The requirements for a project don't necessarily stay the same throughout the course of a project. You could be halfway done and all of a sudden be told that you need to add new features or support whatever random thing a client just thought up. Despite the fact that this doesn't fit in at all with the rest of the design. And so the new features or whatever get crammed in.
"Weasling out of work is important to learn; it is what separates humans from animals. Except for weasels."
Yes, it's a lot easier to communicate with your voice than to carry around a dry erase board and play win, lose or draw with whomever it is that you intend to communicate with. You seem to think that extending this to computers is natural, which is far from the truth.
Take a person who has never used a computer (one of the three out there) and plant him in front of a bash. Watch him get frustrated at the command prompt, unable to figure out what to do. Sure, he can type, but HOW IN THE HELL can you expect a complete novice to know enough to type "man bash" ?!
The GUI makes commicating through a computer a lot easier- plunk anyone down in front of one and watch them diddle with the mouse and click on things, pleased at the results. With a GUI you have immediate results- you can keep multiple applications open and visible, mulitple things within your view at any given time- like you would keep the threads of a conversation in your head for future input when your turn comes around.
We talk because it's easy and natural. Unless you're a complete UNIX nut, you're using a GUI, because it's faster to relate your ideas through methods that are easier to figure out. This is why the multilingual lapse into their first language when they're really pissed off- it's the default setting for a Russian to curse in Russian, though they may be in an English speaking situation (and Russian profanity is SO much more flexible, anyway...)
Whatever you were taught first is going to work better and faster- applying interpersonal interaction to computer interaction simply cannot be done given the state of present interfacing technologies.
When I read this article, I get the feeling he hasn't really ever _used_ linux any more than that guy you know on IRC that installed Redhat once and is now a "Linux User" and a "Hacker". He talks like someone who has merely read a few buzzword articles and now has the holy grail of knowledge on terms like "Open Source", "Bazaar", and "Command Line".
Also worth noting was his comment: "It's almost an orthogonal question," he says. "I think you could have open source movements that, through a peer review system, adhere to the strictest, most anal-retentive quality control program as well as open source projects that function in a perpetual state of redesign. Both are entirely doable."
I guess he's never heard of [favorite version]BSD.
Oh well, I guess its time for me to write an article on Quantum Physics... I have afterall read a few Slashdot comments about it.
Tis better to be silent and thought a fool, than to open
Tis better to be silent and thought a fool, than to open your mouth and remove all doubt --Abraham Lincoln
That's a very good point. And I wasn't really trying to shift the blame to the S & M folks, just pointing out that they are often the drivers for new features for no other reason than dick-waving rights.
What I'd like to see is for them to think in terms of problems that the customers are having and let the software designers try to find a way to solve those problems. Instead they tend to think of things in terms of a list of features and if our gizmo is lacking in one, it must be added regardless of how useful it is.
But point well taken, and thanks for your response.
Admit nothing, deny everything and make counter-accusations.
When I was 12, I found a box containing a bunch of old issues of Hustler in a lot behing the local 7-11.
I began to feel sensations I'd never felt before.
Being a scientifically minded young fellow, I immediately ran home and examined one of the low angle money shots through my microscope.
That's when I made the horiffying discovery that women are composed of red, yellow and blue dots.
I've been trying to live with the implications of that discovery for years now, and I haven't been able to care much about code quality.
--Shoeboy
but why is the Linux kernel compressed? Wouldn't that make the loading process longer because it must be uncompressed?
Rotating storage is slow. Executable compression products such as free UPX take advantage of the fact that loading a compressed file and unzipping it on a modern CPU-memory system is often faster than loading the same file, uncompressed, from rotating storage media such as hard drives or {C|DV}D-ROM drives.
Also, I wish that Linux could have a much smaller text editor. Windows Notepad is only 34KB in Windows 95
You could:Tetris on drugs, NES music, and GNOME vs. KDE Bingo.
Will I retire or break 10K?
... and it is Testing! Instead of making deadlines and release dates right before testing, they should be made 15/16th the way through testing. Software is not -nearly- tested well enough. Any QA department will tell you they are always strapped for time. Testing should last longer than the development of the software. Software companies should test like there is no possibility for a patch.
--
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
So how does a company grab the biggest slice of the marketplace pie? They do so by getting to market first. How do they get to market first? By cutting every possible corner imaginable to meet a ridiculous deadline and releasing a product of poor quality.
All other reward systems stem from this one. Imagine the case where a company has two programmers. The first hacks a bunch of code together and makes the ridiculously short deadline. The second programmer misses the deadline but produces a much more stable product. Now once the first programmers code starts to fail, the first programmer has to "save" the company by providing short-term quick fixes to the code, reducing the quality of the code further. Management views this individual as a key individual; key because they can't operate without him. The second individual is hardly noticed, except for delivering late, which is considered aberrant behavior.
So imagine the case where both of these programmers are leaving the company. Which individual do you think the company is going to bend over backwards to keep?
Economics, being the ultimate reward system for business, dictates that software development will never be able to do what hardware engineers have been doing for years, create micro-components. In hardware, you can create an AND gate and package many of these gates into a chip. This chip can be mass-produced and sold at a reasonable price. Every time a circuit is produced with this part, the manufacture make a little money for each part purchased.
In software, we can't make a simple component and standardize on it. If we created a component, e.g. a component that compares two dates to see if something has expired, and tried to sell it, what would people pay for it? Maybe a dollar. Most people would look at this component as so simple, they'd rather develop their own. But even if they did buy it, they can make millions of copies of this component with no additional cost. It would be the analogy of instead of buying an AND gate for 50 cents, you bought the AND gate factory for 50 cents. The hardware industry would have gone out of business years ago under such a system.
Software suffers from the economics constraints more than language problems, management issues, bad programmers, etc. Anyone can buy book after book on proper techniques for managing a team of developers using a myriad of development processes. The reason we see management pay only lip service to process is because the reward system for businesses doesn't reward quality or standards.
This is the real problem to solve (if there is a solution). Would companies pay royalties for components that were used in their products? Highly unlikely. Will people stop paying for new software because it is too buggy? Maybe, but it is usually better to use buggy software than no software at all.
After almost 20 years, I have given up on the software industry. As soon as I can get out, I will. The better you get in software design and development, the harder it is to operate in this environment. I don't blame companies for operating the way they do. They are rewarded for doing so.
So if you want to change behavior then change the reward system. Good luck.
The reason software still sucks, by in large, has been the lack of market competition in this arena. If users could choose between A and B versions of software based on how much less they sucked than the other, then we'd see less suckiness.
Unfortunately, there haven't been enough viable alternatives in the software market. These days, software marketers are pretty much hosed unless they support Win32 because that's what runs on My PC ®. The Mac flash in the pan is effectively gone, and Linux desktop use can no more overcome the inertia of the installed base any more than WinME or Whistler will. There, suckiness has been measured practically by how many problems are encountered installing and using the latest software on a hoary old Win95 box. Backward compatibility is the paramount measure of suckiness. That immediately shows how important standards are in this business.
There is a desperate need for a slowly growing pyramid of standardization, with just a fringe of featuritis that gets encompassed by a growing set of standards. And, if any company locks up the standards and charges a toll to create barriers to market entry, then we can't get the best level of competition based on suckiness, any more than you can get competition in your local electric or phone provider. The higher levels of the pyramid cannot be built best on opaque stones that turn out to have insuffcient strength for an unforeseen future application.
IMHO, the real revolution in less sucky software won't arrive until higher level software components become standardized and free, from the lowest to the penultimate level.
"Provided by the management for your protection."
...speaking as someone who supplied some patches to DeCSS, and writes telecoms network management software for money, I see little reason why people cannot be multi-disciplinary. Very few people nowadays are expert in all fields of software, and no one pretends to be, but we can be masters of many areas rather than just one.
His comments about Linux and Unixes were also off point - he fails to realise that the command line environment is an extremely efficient one for an experienced operator. Point and click environments are great for newbies, but I've yet to meet one that increases productivity for an operator who knows his onions. I do use GUIs and they're great when I'm not too familiar with what I'm doing, but when I know the area inside out its Shell Time.
I came away from this article feeling he just wanted to be inflammatory; if he'd posted this as a Slashdot comment he would've got so many (-1 Troll/Flamebait) mod points that his karma wouldn't have recovered till the fourth millenium!
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
link to One Half Of A Manifesto
Because these same pressures...
Combine time-pressures, market pressures, upper-management pressures, and a lack of training and professional standards, and you have a whole class of employee (the project manager) who has only incentives to lie and hedge, and no incentive to be honest about schedule, feature set, state-of-the-project, internal project problems, etc.
... also apply to the people who write those "sufficiently developed" "wealth of frameworks and libraries." I resent people who say that the tools are good but the work we do with them is shoddy. The tools are merely another level of software which, unfortunately, often has all of the same problems as end-user apps.
Take the apple WebObjects framework, for example. More specifically, the EnterpriseObject backend. Basically this has to do with an OO interface to database transactions; neat stuff. So why was my application crashing every couple of days after eating all the machine's available memory? Because there was an outstanding issue in the framework which failed to deallocate internal database objects. My app crashed and it wasn't my fault, and I'm still trying to find a workaround.
"How I hated Unix back in the '70s -- that devilish accumulator of data trash, obscurer of function, enemy of the user,"
Think he's a little angry? I agree that most software production sucks. always has, and the future isn't looking too bright either. I'ts all because it's writen by people, not machines. People make mistakes. I can't remember the last time I was able to install a program without having to screw around with it in some way. between crashing, unreliability and the anoying habbit of breaking other software on my systems, I usualy spend more time fixing problems with these packages than actualy using them.
Dirty Pirate Hooker
He really doesn't know anything about what is good software.
If he had lived in the Soviet-union he would have been proclaimed as a good thinker. Keep it closed and locked up so nobody can see the errors underneath...
http://www.millnet.se/ GO/U d- s+:+ a C++ UL++++ P- L+++ E W+++ N+ w++ M-- PE+ t+ X++
When user interfaces are designed, which is the better design? The simple pictoral design? (Like thos books for kindergardners), or a powerful and complicated design?
:)
In evolutionary terms, it's the simple design, because it's easier to learn. Unfortunately, this is a flaw, it will forever hobble us from creating the most powerful design.
Do not forget, most people in western civilization have to master an incredibly complicated, unnatural, non-intutive task. This task is INCREDIBLY difficult. Most people spend 10 years mastering literacy.
We force our kids to master a complicated and un-intuitive interface because simpler interface don't offer the power, and flexibility.
I like powerful tools for powerful and difficult tasks. Pictures can express instructions or handle simple tasks, but only words can express abstract relationships. Without words, there can be no mathematics, no algebra, because pictures cannot express the concept of a 'variable'.
If you know of UI research that gets around this, I'd love to hear it. Please give me a counterexample.
The fact of the matter is that the programmers USUALLY have little say in management decisions. You better believe they almost always DO offer better solutions and explanations. They can form arguments until they're blue in the face but more often than not it gets them:
1. blamed for wasting time
2. on bad terms with management
3. fired
Marketing departments like yours only happen in very small, tight-knit companies or by luck.
---
Where can the word be found, where can the word resound? Not here, there is not enough silence.
"Where shall the word be found, where will the word resound? Not here, there is not enough silence." -T.S. Eliot
Thanks for bashing on the VR Hippies. Anyone remember "Mondo 2000" from about 1992?
M2000: So, Todd Rundgren, you like smoking dope and posting on Usenet. What do you think of VR?
TR: Way cool dude!
M2000: Yes, VR and Cybersex is the future, thanks for that insight Todd. Too bad all the software sucks right now.
It's true that machine language code is non-object oriented, but that's not the issue here. The main objective is to build software components that have known behavior in all circumstances. It's not practical to do that with procedure oriented programming. There is ALWAYS some side-effect in a non-trivial program which leads to bugs.
Implementing interfaces with known boundaries using the object paradigm is a rugged, well known way to isolate the effects of a software defect to a single section of code. With procedures and functions free to grab at all the available variables, any line of code can take out the whole works.
It's like using Grade-8 hardware instead of whatever happens to be in the bin at a hardware store. You get a high-strength, durable, part with guaranteed specifications. While it wastes some CPU cycles, it's an acceptable tradeoff for 100% reliablity.
--Mike--
In many cases, software isn't made by programmers, its made by a company. Despite the engineers' wishes and goals, there are other departments in a corporation that have influence over the software's development. Marketing might want feature X by release because its needed for a campaign. Sales wants feature Y because a potential client is requesting it. An executive wants feature Z because... well because he's on a power trip and thinks he knows better than you. Even if features X, Y, and Z are ridiculous features that will reduce the quality of your product in some way, you have to do what the company wants. Quality is certainly not what its necessarily about in the business world. Alot of executives will flat-out tell you this. In part, this guy isn't complaining about crappy software, he's complaining about products developed in Corporate America -- a market heavily dependant on image and tricks. Re: "free software", well... where's the incentive for quality? If I'm making a program in my free time in my basement, I'll make it as good or bad as I want. There's alot of possible scenarios here, of course. I won't elaborate. As for his comments about the commandline... show me an admin who can setup an IIS server faster than I can setup Apache and we'll talk.
see subject
___
___
If you think big enough, you'll never have to do it.
Vim is an _awesome_ vi derivative. Syntax highlighting and a million other cool features blended into a very smooth programming and editing environment. It's pretty small too (~1.8Mb stripped) given all the things it can do. The syntax is pretty easy, in practice (with recent vim versions) all I need is ESC to get to command mode, and i to go into insert (i.e. edit) mode. in command mode :w writes out the file, :q quits, and :wq writes and quits. That's, what, 5 commands? I bet notepad has more menu options than that... :-)
The first thing I do on a new system is install vim and symlink vi to it. The second is usually transitioning to qmail.
--
News for Geeks in Austin, TX
Good point.
I donate all spillover Karma to the charity of my choice... Ada was still a babe despite what people may say...
KDE2 actually does this, if it can't determine the filetype from the name it runs file(1) on it to determine what the proper MIME type should be. I believe that this information should be stored with the file meta-data, it would seem to be too much of a performance penalty to scan the file every time it is accessed. The MIME type could be determined when the file is created and whenever the file is closed after writing.
Just my $0.02
-- Remember: Wherever you go, there you are!
I read the linked article as well as Lanier's very long essay in Wired.
Lanier proposes that someone who writes software for a pacemaker be prohibited from writing software for music composition. He compares such mixing to a brain surgeon running a tattoo parlor on the side. I disagree with this idea. I think the mixed backgrounds of programmers provide valuable cross-fertilization.
The focus of the Wired essay was Lanier's disagreement with 'futurists' who predict techno-utopias or dystopias. He points out correctly that software is far too primitive to power the dreams or nightmares of these writers.
One thing I found irritating in the Wired article is that Lanier is clearly a Windows user and ascribes many of Microsoft's shortcomings to some deep-rooted problem in software development, when they're actually just caprices of the gnomes in Redmond. If you read the essay, you'll see what I mean.
Also, he calls Unix 'that devilish accumulator of data trash'. Jaron, maybe you need to take a look at the man pages for crontab, find and rm.
um... why not hit Ctrl-Alt-backspace and kill your X server yourself? Then you're dropped back to the xdm prompt to login again (right?). Granted, you still lose all the work in progress, but it seems safer than blithely hitting reset.
So?
Isn't that exactly why this kind of forums exist? To facilitate the free exchange of information and opinions where it's OK to be wrong. I don't know about you but I read Slashdot to relax and get a few laughs, not to follow serious job related discussions.
One of the most irritating personal characteristics in engineers (and other highly trained professionals) is the you-don't-know-shit-so-shut-the-fuck-up attitude. Not having a PhD or any other degree in subject X doesn't mean you can't talk about X on general level.
If you feel offended by the inaccurate postings of someone, just correct him/her politely -- if you like.
I think there are more bugs in closed source projects, but they never get publicized. Only the most egregious ones are publicized and fixed, and the customer learns to live with the rest. Have you ever tried to get a company to fix a reproducible bug in their code? It's like pulling teeth. And the non-reproducible ones? Ha ha ha ha ha!
There's been a wealth of knowledge gathered over the years on how to write high quality software. _Writing Solid Code_ and _Code Complete_ are two standard texts that come to mind. This is not a technical problem. It's an organizational problem. I think we're reaching the limits of what the corporate structure will allow us to do, and writing truly good software lies beyond that boundary. Open source represents the first steps beyond that corporate limit.
Problem is that we don't build software like bridges, unfortunately. If you make a dent in one pillar on a bridge, it won't collapse. A tiny buffer overrun in software can take the whole thing down. Almost nobody make "defensive" software that is fault tolerant, eg. they don't check if a sort really sorted the elements, and re-sort with a second algorithm if not.
is this guy a real computer scientist? or just one of those "bits bits and more bits" quazi-philosophical bullshitters?
my buddy Jake and I are already designing an OS. It's in very early stages (the bullshitting stages) but we figure we WILL make it, and it WILL rock. but probably won't be complete for about 4-5 years
________ J. Smith
i dont think lanier brought us
vr but he did bring to us a type of software that still exists today
he was the one who was able to get a computer program to replicate itself, oh yes, a-life, not just a-intel
please correct me if im wrong
back in the day we didnt have no old school
Here is the Manifesto. Interesting reading.
That's exactly the problem, the only thing a BIOS should do is boot the damn thing and that's it! It's the operating system's kernel job to talk to hardware, not the bios'.
Now, now, now, don't take that as a flame. But what's the average age of a Slashdot reader? 20? What's the average age of a gung-ho Open Source development team? 21? Realistically, you don't have much software engineering experience at that age. Heck, how many Open Source projects have regression test suites? Two?
I'm not talking about old standbys like Perl and Apache and so on, but most of the other projects that get started by young coders and garner press simply for being "open source" without code quality ever being an issue. I don't want to name names, but examples are plentiful. Having a relatively simple project with 5 megabytes of *compressed* source code should scare anyone off.
In the article Lanier says
"I mean, everything in Unix is ultimately based on command line interactions. You can try to overcome that, but it's very hard. Unix's whole philosophy on how to do internal management and how to manage timing is based on that set of assumptions, so you have to fight it at a thousand levels."
In a lot of ways this is true for all operating systems. In Windows, you can see the command line present when you are associating an action to a file extension. You will 9 times out of 10 be setting up a command line that launches a program on the file. The other 1 time out of 10, it will support DDE or something.
My feeling is that the command line is a programming language. Often it is handy to use that programming language in a GUI (for example when setting up associations). Because of this, it will always be hard to get entirely away from the command line. Especially when the command line is a large part of our programming languages (ANSI C and Java define main to take parameters from a "command line").
So I don't see how any one operating system has a more "command line feel" than another.
Then again, I've never tried to build a virtual reality interface on top of UNIX.
-no broken link
Visual C++ is NOT object oriented in a nice way, Delphi is much better, but still not there... Everything is still doing function calls with parameters, dangling pointers all over the place, and the number of layers is going up all the time. It's no wonder that the stuff breaks more often instead of less.
--Mike--
No matter how refined computers become, no matter how many orders of magnitude of AI we pile on top of each other, no matter how elegant and compact and all-encompassing thing become, there will always be a need for someone who understands the underlying components. Somebody will have to know what is inside of the black box. There will always be McGiver situations where a more elemental understanding of the technology is necessary.
Obviously, components are the first step, more Lego-ing and less handcrafting of software. But I disagree with anyone who thinks hardware is way out in front of software. If hardware speed were indeed so far out in front, then games would be written in VB or Java or Python or Smalltalk or Modula-2. As it stands today, we're still facing a large performance gradient. Make the gradient go away, i.e., make it so that bulky, overhead-intensive-but-elegant languages fly just as well as tight, super-optimized C or Assembly, relatively speaking, and then you can talk about hardware's arrival.
I believe GNU/Linux is successful mainly due to politics, but partly due to "technological honesty". Sure, the overall user/developer experience of the Unixae is more primitive than, say, Microsoft Windowses, but what sort of progress has MS really brought? Phony, glitzy bells and whistles is not necessarily progress. Besides COM, MS really hasn't much to offer in terms of elegance.
Another aspect of the open source/free revolt is that this is the first time true freedom in the computer world has appeared. Back in the late '70's at my university, if you weren't a 3.5 math major, you didn't get into the CS emphasis, and, hence, you never got your hands on a computer; you were just a peasant. Microsoft Windows changed that with Peztold's tome on Windows 3.1 programming, and now, finally, GNU/Linux has broken the field wide open. We really haven't had much time to flex our muscles yet. The world simply hasn't hit its software development stride yet.
All in all, a few more years of open/free software and true universal hardware speed will turn things around.
--- WWSD? What Would Strider Do?
Just because your car is stupid doesn't mean it must always be so. Wouldn't you prefer a car with a "command line" that you get in and say, "go to work" and be done with it? Work is already quite advanced on the development cars that can drive themselves. So a stupid device and/or a stupid user both benefit from a GUI, where as a smarter device or a smarter user can benefit from a CLI.
Just a question. Does that really work? What if both want to type at the same time, won't they fight?
You may have paid for it, but we want to know WHO you are and WHERE you are. In case, you know, we have an important patch or something.
First off, I wanted to thank you for the Jurassic Park reference, which made my laugh out loud when I heard it for the first time in the theatre.
I also wanted to agree and expand on the idea that software sucks because the market says it's OK for it to suck. In general, the market now thinks it's OK for a LOT of things to be pretty mediocre - cheap plastic merchandise, McDonalds, TV. Software fits right in that group.
On the other hand, because it has been OK for software to suck for so long, I totally agree with the point made in the article that humans, as a group, have not really figured out how to make software. We haven't really needed to. I feel all current ideas on managing software projects are pretty much wrong at the core of things, and until we figure out why there's a lot of floundering to be done.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Lanier said,
"Basically, if you heard your brain surgeon also had a tattoo parlor, you'd probably demur. Right now we think of them as the same thing. We think it's perfectly all right for people to go back and forth. I don't think it is."
This is a fascinating suggestion and I think, aside from the flamebait in the article for Linux lovers, this may be the most important idea expressed in the interview.
That idea is that the people writing software should not only be generalists but software specialists(though I'm sure generalists are needed in software engineering just as in medicine). In this statement he both elevates software engineering to the level of medicine (which it certainly deserves given its importance in so many settings), but also calls for a more systematic approach to the social role held by coders.
Granted, while physicians are not perfect, their professional development model might not be a bad one to follow in the field of software development. Study fundamentals and then actual applications. Work under the tutelage of those more experienced. Increase professional independence. Share new ideas with peers and undergo peer review.
I think that a shift of this nature would definitely help propel software development leaps and bounds. And though it may be a good idea, what can be done to push things this way?
food for thought anyway...
In the beginning there was nothing, and then all of a sudden there was a big explosion and nothing became time and space. Twelve to twenty billion years later a bunch of creatures that use their two limbs to stand straight and the other two to masturbate and click on the NEXT button of their pr0n site are arguing about quality of something as abstract as software development process.
Things have most certainly changed.
Before the 1995 hundreds of software writers breathed, ate and shitted with Assembler and C. The only few clear moments in their lives worth remembering were the times when they found solutions to some obscure computer problems at the lowest level - at the hardware level - these were the junkies who coded bit by bit, only caring about performance; computers were slow.
Today armies of so called IT professionals are really trying to make guesses, as well educated as they possibly can, about scalability of multitiered web and wireless based systems, that must serve millions of customers, mostly in real time (rarely with back bone batch processes.) These are different breed of people, they don't need to know too much about the Assembler behind their Java and VB virtual machines.
Obviously it is hard to design software that works like Star Treck's does but it does not mean that software today sucks, it only means that this software is the proto software, it is the evolution that uses simple patterns with countless iterations to produce complex systems that at some point in time will most certainly be integrated together into one huge breathing software monster. There will be no question about AI anymore, the software will live its own life all around us. Be prepared.
You can't handle the truth.
Indeed, I've been burned so many times by using commercial-off-the-shelf (COTS) stuff professionally, that my first thought these days is to build it myself unless I can get the source, or it is really well known and stable. If I am *forced* use COTS, I write insulation layers so I can replace that junk later on. Even with that level of paranoia, I still get the shaft from time to time with a no-work-around situation.
I clearly remember Jaron telling me that we (while I was at NPS) should model our software after the unix shell tools. He gave examples of how composable they are. That you could just pipe the output of one command to the next, so that you could create the exact tool you needed. He wanted me and my colleagues to create VR software that could work that well. The fact that he now craps on UNIX is simply a contradiction.
The solution is to analyze the contents of the objects. Like the Unix "file" command, which runs rules that examine the starting bytes of a file to determine what it is. The advantage here is that when the file is copied somewhere, it's "type" is preserved, because it is part of the data.
What is missing is a file system where accessing the first 100 or so bytes of a file is as quick as reading that file's name, so that we could display the type as quickly as the current filename or attribute based hacks. Does ReiserFS or anything do this?
There should be a command line program to do exactly what "open" does in Explorer, or clicking a file in KDE, and we should require GUI's to exec this program so that all the GUI's agree on this system.
He might as well have bitched over the binary nature of computers. Like so:
I mean, everything in computers is ultimately based on binary interactions. You can try to overcome that, but it's very hard. The whole philosophy on how to do internal management and how to manage timing is based on that set of assumptions, so you have to fight it at a thousand levels.
Friends don't help friends install M$ junk.
Listen. Ok, wait, you're still not listening. Ok, now listen.
I can't believe that I haven't read one post that actually got what Lanier is saying. Folks, he's saying this: with computer hardware running millions of times faster and more efficiently than ever before, NOBODY is writing software to take advantage of it.
He's not saying that the piece of shit proggie you wrote in PERL or C++ isn't a quality piece of shit, he's just saying that it's unimaginative and especially not written in any way that would actually take advantage of your computer hardware in any real way.
Maybe more than your proggie though, he's addressing visionary software -- or the lack thereof. What are we going to do with these super-computers? Is our goal simply to get the smoothest, cleanest, fastest game of Q3 ever? He's saying that we don't even have any idea of what we can or should do with these new technologies because we can't think outside of the boxes that we've simultaneously fallen into and yet made for ourselves by our language and ideology.
The Englishman Who Came to a Concert
All I can think of as I read the article was Neal Stephenson's "In the beginning was the command line." It seems the perfect response, even though it predates the article by over a year.
I don't get it. How am I supposed to write "much better" software with a faster computer. Did anyone ever believe that "quality of products" and "horsepower" are related?
All humans are mortal. Socrates is a human. Socrates is dead.
I think the most important quote in the article was right at the beginning:
"Maybe we have a language problem," he says. "Instead of talking about software, we should be talking about different entities. Just like we have language, but then we also have poetry, drama and rhetoric. Maybe what we really need is just different categories of software that are handled in such utterly different ways that we don't even use the same word to describe them."
I've been looking into various evening/part-time, professional master's degree programs and my biggest problem when I check out the catalogs is what classes to limit myself to. I could focus on network programming, web-based programming, database programming, higher-level "software engineering", AI, GUI, etc., etc., etc.. Of course there are overlaps, but I guess the main point is: I wouldn't ask my cardiologist to diagnose this fungus on my feet.
I don't have an answer, but a lot of very different tasks are thrown in under the amorphous term software development.
Waltz, nymph, for quick jigs vex Bud.
I have always thought of creating a program like making a samurai sword. I know it sounds weird, but here's why. A sword is supposed to be an elegant and simple tool or weapon that really has many uses. Software, likewise should be the same way. You wouldn't want a sword that was mostly handle would you? what would be the point of that? In the same respect you wouldn't want a web browser that was all buttons and had a small windows for looking at a web page. And you wouldn't want a heavy sword, that's dull and breaks all the time would you? (think netscape 6). This is how I would break down some of the software that I use, using the sword analogy.
1. Windows - Large sword, somewhat dull, extra protrusions that make it only fit in their custom sheath. Dullness makes it harder to cut yourself, so it is more for those who don't want to develop enough skill to use a sharper sword, don't think they need one, or are scared or cutting themselves.
2. Linux - balanced different, awkward at first, but better once you get used to it. Really sharp, really durable, doesn't break, cuts through most problems easily. Not for the uninitiated. Blades everywhere, flexible but complex. Not just one knife, but lots of specialty knives designed for cutting through anything, each one for something different.
3. Winamp - a sharp, solid dagger, lightwieght, customizable with different blades, different designs for the handle.
4. IE - seemingly small handle, large blade, elegant but very fragile.
5. AIM - cuts through most of what it needs to, but is getting kind of heavy (bloated) not as bad as ICQ I think.
6. Gimp - Solid, sharp small handle, long blade, even comes with tools for sharpening. (think script-fu)
This Wiki Feeds You TV and Anime - vidwiki.org
Enough research and experimentation has gone on in software development that it is perfectly feasible to write very good software indeed. Just use the right methods.
The problem is IMO that very few projects actually enforce the use of good development methods, and that a large number of the people (including programmers!) in the projects are unaware of them.
I do not think the problem can be solved just by improving terminology as the article suggests but it is a start. For example a company that makes hardware should not recruit 'C programmers' but 'Device Driver engineers', excluding from the recruitment process a lot of people that do not have the necessary skills.
But there is more to all this. Users should demand higher quality software (with their wallets). Project leaders/companies should do more than pay lip-service to their development process. Developers should demand that proper development methods are used, rising above the all too common amateuristic ways of working.
Strange as it may seem, the most difficult part seems to be to get users to actually demand and recognise quality.
For starters, let's say that I've a lot of respect for what Mr. Lanier achieved in the early 90s with VR, and understand that whole pop-semiotics/Mondo 2000/Boing Boing/Modern Primitive/Cyber-everything vibe he's coming from.
But allow me to reiterate that HARDWARE has a DEFINED FUNCTION. Bits go in, other bits go out. Key gets turned, engine starts. I buy a car and a plane and a boat - I don't expect to buy one vehicle that can fly, swim and roll on dry land. His problems with modern software stem from his paradoxical and contrary wishes for software engineering.
Lanier seems to have a scattergun theory as to why software sucks. It's either "the engineering isn't there" (definition A) , and/or "what it does for the customer doesn't empower him" (definition B).
To the first part I say software is considered by its mercurial nature not only something that CAN'T be engineered, but MUSTN'T be engineered. Cause if you make plans and stick to them, then marketing can't decide at the 11th hour to retool everything to include holographic agents and a Star Trek like voice input (after a night of cocaine and "brainstorming"). To whichever jackass points me to "if programmers built buildings a woodpecker could destroy civilisation" I say "make up your goddamn mind whether you want a condo or a three storey house BEFORE we pour the concrete, and we'll talk." No other form of engineering comes up with the ludicrous idea that plans are mere suggestions and subject to change at any time, to produce a product with no real set function (is Word a word processor, a typesetting program, or an HTML editor? MAKE UP YOUR MINDS). However, coming up with small, ruthlessly efficient software entities sounds like UNIX, which he says sucks by definition B of his rant.
As for his ideas that programming languages and interfaces should be humancentric, let me put it this way - computers process DISCRETE SYMBOLIC pieces of information, humans process PATTERNS and CONVOLUTIONS. I don't expect my shovel to shovel my walk for me, why should I expect my computer to respond to me drawing out what I want with magical icons and lines and all other forms of strange ideas when it comes to PROGRAMMING? (Visual Language?) Any machine that can accomplish such a feat would have so much software bloat by definition it sucks by definition A. A computer is a tool, not a mystical genie that's going to solve my problems for me. If I want a secure Internet connection, it behooves me to either learn how TCP/IP works, or hire someone who does. The answer is not to have a big red button that says "secure my system" cause I can assure you, on a system like that, someone's working on a big GREEN button that says "hack this system."
Most software sucks because people don't want to take the time to figure out what it should do or who wants it. Marketing seems to think that rather than research what a product should do and who to sell it to, it's just there to listen to every potential customer ("I want a minivan". "I want a sports car." "I want a quarter ton pickup") and spit back every ludicrous request ("We've got to come up with a sports quarter ton minivan!"). Management seems to think that rather than getting specific specs by a specific deadline and then staffing the needs of the project, giving the engineers and testers the tools, and then getting the hell out of the way, it's all about constant "meetings" and Microsoft Project bar charts.
--- Jump!! Fire!! Bullet time!! - Lego version of the Matrix
Its a sad commentary for the industry but certainly a good one for a quickly-growing economy. If you take the time to carefully plan, stick to the guidelines initially laid out, and test thoroughly enough that you are 99.44% bug free -- guess what -- you release and fail. Why? Because 3 or 4 other companies released months ago and dominate the market. No matter how good your product is, youre going to have an extremely difficult time getting people to switch if they are used to another product.
Now with the Internet, it is even more important than ever to be the first. That is the reason so many companies are willing to take huge losses their first couple years as they build up to a "critical mass of users", the point after which, they should, in theory, start to receive increasing economic returns to scale. (Yes, many are failing, but if you look closely, they are the me-too companies. Even amazon got caught up in this, and they should do better having pared their toys and other depts they added because they just could.)
Unfortunately, the reality of the times dictates that the only good choice is to develop a pretty good app, release it, and hopefully gain the name recognition and market share. Once you have market saturation, you can concentrate on making your product the best and upgrade to make your customers really happy, and then beat the other 2 or 3 companies out there doing the same thing.
The ivory tower has never had to reach so h
DISCLAIMER: Java(TM), JavaScript(TM), and JavaZealots(TM) are trademarks of Sun Microsystems, Inc., LLC, CRAP, etc.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
"Why Software Sucks" isn't saying that the "software" out there isn't/can never be quality... He's saying that we're going about it all wrong, that we have a misconception of what "software" is/should be and we perpetuate that misconception by the very way we talk about "software".
Talking about the quality of current software is a good example of this misconception and why it's so hard to see out of it.
The Englishman Who Came to a Concert
Hardware is so much amazingly more simple than software. The tasks it accomplishes are much more specific, much more defined.
Software is more of an open book. Many applications/OSes/etc do MANY things, and the overall number of states the application can be in is millions of times more than the states a CPU can be in, for example.
Just my thoughts..
-Justin
Yup. I've seen too much of it, too. Don't forget that the programmers (the guys on the bottom) get blamed for anything that goes wrong. The managers (at all levels) have their Teflon suits on.
Now go back and assume your project is a bridge instead of a program. Nobody within hollering distance of their right mind would put up with this kind of crap. Build a bridge that way, and it will collapse. Very publicly.
What's the difference? Only about 4000 years of experience. People in the management chain have a feel for what is needed for a bridge to "work", and know that they can't interfere in the process without risking disaster.
Software is newer and much harder to quantify. A bridge either falls down or it doesn't. A computer system has zillions of "degraded" modes that it can get into and still sorta work. It can be really hard to tell if a program is meeting its goals.
Because of this, managers can get away with all manner of crap. Software engineering will not be a real engineering field until a typical "software engineer" can say something to his manager like "Testing is going to take six weeks, period. I don't care if you miss Comdex, it doesn't get released until it goes through Test, and that will take six weeks." *AND HAVE IT STICK*.
I'm not holding my breath.
--
Welcome to the Turing Tarpit, where everything is possible but nothing interesting is easy.
OK, so you've got this computer that triggers on your saying "computer" in a commanding voice. Now you're on the phone with tech support. Whenever you try to turn on the lights, the computer is launching one of the lifeboats. ... Computer??"
"I said, um, you know, turn on the lights!"
"Sir, you need to say computer! turn on the lights."
"I DID say computer! turn on the lights! Oh no!"
Or how about,
"Computer! tell the hull repair robot, 'Computer: tell the tailfin computer, "Computer: shutdown now!" ' "
"Computer
How do you handle escaping issues?
If you looked hard enough, I think you'd find a bridge carrying ductbanks across a creek that was stamped by an EE at the power utility.
Generally, they are called SDKs, or software development kits. You are right about one thing: people won't pay for uber-simple stuff. But people WILL pay for complex stuff, or stuff they might not be able to do themselves. To use your metaphors, people will pay for ICs (integrated circuits).
SSL Certificate
This post explains exactly the problem. Managers who act in such a manner that their software is of poor quality have the only hopes of becoming wildly successful in the software business. They are lauded as geniuses and heroes. Meanwhile, people who do things in a manner that takes account of good engineering principles have their code trivially emulated or their formats trivially embraced, and end up making no monopoly rents. Usually they go out of business, despite the geek crowd looking back fondly on their work as visionary.
Sound familiar to anybody? Mark the previous post up to 5 please.
"We will compete with anybody."
- Michael Risse, general manager at a company that complains that all antitrust complaints are instigated by competitors
You can if you use the Prograph programming language. It lets you build real Mac applications using the Classic Toolbox by dragging and dropping icons to construct dataflow diagrams.
It's been recently ported to Windows from its origins on the Mac, and I encourage programmers who like learning different languages to download the demo and try it out. It's literally unlike any other programming language I've used.
On the other hand, the problem with keeping the "file type" data (or any other data) in the filesystem as I suggested is that then you have to update dozens of programs to deal with it properly - at least tar, gzip, bzip, cp, mv, etc, etc. And as soon as you ever put one of those files on a filesystem that didn't support it, you would lose all that data.
But if you bit the bullet and started putting that stuff in the file system, there's a lot of other data that would be nice to track. The mime-type is just one. My argument is basically: We already track a lot of this stuff in the file system, so why not track more? Ext2 and every other Unix I know tracks the following:
- File owned by (user id, group id)
- File last modified on (some date)
- File size
- File name
- File permissions (read,write,execute for user,group,all, and suid)
It would be great if file systems also tracked the following data:- File created by user (real user id) acting as (effective user id) using program (X)
- File last modified by (real user id) acting as (effective user id) using program (X)
- Mime-type (X)
I'm sure there's lots more. Unfortunately, this may be a case where backwards compatibility with the existing installed base of Unix systems will doom us to the limited capabilities that were designed into the BSD filesystem twenty years ago or more.Torrey Hoffman (Azog)
Torrey Hoffman (Azog)
"HTML needs a rant tag" - Alan Cox
A. Draw pictures and icons of how your day went. B. Tell them in words how it went.
You do both.
You draw a picture of the events in your head, and sequence along as you go. And then you describe the pictures of each step in that sequence in words. If your friend doesn't get it, you back up and use other words, until finally the message has made it across space and time to the other side. Sometimes, you might even fall back to drawing a picture - certainly, this is how most linguists worked when encountering foreign members of other races, and it's an effective process of achieving communication, when needed.
Words function as a means of communicating significances and concepts. Pictures also function as a means of communicating significances and concepts.
They are not mutually exclusive of each other, and usually the better computer science types, and thus the better programmers, producing quality software, can function with either communications methodologies just fine.
It's the guys that get stuck on one method, and one method only, that produce crap software...
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
Quote from back in the day: "Want a copy of Mondo2000 ? Lift any garbage can lid in the East Bay". I never considered it worth so much as a 'nice try'.
Veteran, Bermuda Triangle Expeditionary Force, 1992-1951
But if a programmer gets a single line out of millions wrong it can prevent the whole program for working. There may be thousands of faults in big software systems, but they are by far the most complex things we build, and have by far the least tolerence for mistakes of any field of human activity I can think of.
I think that considering how difficult a task it is we do damn well and should feel proud that we do.
Of course none of this means that we shouldn't do everything in our power to make software even more reliable and free of mistakes. Software is tens or hundreds of times as complex as it was ten years ago. Modern techniques and the right disciplin help, but I don't believe that software development in general has a bad record at all.
If anyone can think of another field where a mistake of a single mistake in hundreds or thousands of hours work is considered a bad record, I'd be suprised.
</rant>
Sig is taking a break!
Money... Companies want to make money more than they want to spend it... even if spending money will likely make more money in the long run.
The have a market, they need a product.
Noone has ever sold a %100 finished product
when it comes to software. The market tolerates
%70 and thats what it gets. %100 finished means you missed the boat.
'sapientia potestas est'
In summary, Windows can still corrupt a filesystem, does a pretty poor job of keeping it consistent even when it's running, and doesn't offer the caching and lazy writes of ext2. How is that a good thing?
I remeber going through this back when I worked at a place that used Roque Wave libraries. The nice thing is that we had the source and keep all of the Rogue Wave source in Clearcase and appied our own fixes as well fixes supplied by Rogue Wave. I do agree it's not a pleasent situation to be in when your using COTS and don't have the source code to patch it yourself when you get burned by a bug that's not your fault.
From what I understand his viewpoint he doesn't say that software programmers are doing a bad job but rather the entire software industry's model is currently inefficient. I think that he longs for days when we will be able to use eclectic object oriented languages and visual programming to magically piece together programs using advanced building blocks. In the land of make believe (i.e. Star Trek) programs are put together simply by moving building (or function blocks) around. No messing with actual code (or so it seems).
Problem is current level of hardware also limits this level of complexity too. In order to make software efficient some software must be written in assembly. An example of this is the Linux kernel. Another example is MFC. A Win32 program is far more efficient and elegant but harder to write for newbies.
I can prove my point in this too! Look at freshmeat.net or sourceforge and look at all the bad open source projects people try to do and either figure it out they they do not have the talent to complete the projects or they put something out there that doesn't even work. Don't get me wrong, I still believe in Open Source, I just think you need to pass the mental exam before you can hop on the band wagon. Yes, people do make mistakes, but if some people put a little thought into their projects and read a few white papers and howtos, there would be a huge improvement! Imagine if everyone used their brain... wow.
Oh, those groupings allready exist! At least there are names for the persons creating different type of "software":
:)
Webslave - Person creating HTML, JavaScript and PERL CGIs and perheaps some database bindings. "Software" with high user-expressive (I won't use the term expressive power as the author, since IMHO, even a sorting algorithm contains a lot of such) content.
Sysadmin - high-level programs merely interconnecting big entities. Not so high user-expressive-power, not so high engineering-power neither. This is more like the person planning where to bild the bridge, what islands to connect with bridges, etc.
Script-kiddie - like sysadmin, but with different big buildingblocks, and different intentions...
KDE-hacker - programmer creating everything in one place, low-level low-user-expressive and themes and widgets all in one place.
Forgot someone?
Yes, this is meant to be a troll, but a funny one, at least
--The knowledge that you are an idiot, is what distinguishes you from one.
Good coding, development, and management practices are known. Know how to use them and apply them, and your project has a good chance of meeting its requirements.
Good developers are 5-10 times more productive than poor developers; good teams are 2-5 times more productive than poor teams. What makes such a great difference? It's not "native intelligence" or "talent" or "luck". It's knowing how to work effectively. Training.
The trouble is we're still in the dark ages of software development. Ignorance is the norm, and there seems to be an underlying assumption that we're stuck with death marches, cost/schedule overruns, and poor quality; and the idea that using good techniques and best practices is somehow more expensive. Until these assumptions are removed, software will continue to suck.
I cant figure out it its a bad article or he has nothing really interesting to say.
He says software sucks, but I'm not sure if he's addresses the quality (bug wise) or the quality (user interface wise). I'm inclined to think he's addressing the suckyness of user interface since he's into VR.
Now, anybody who is complaining about the ability of humans to design user interface should not be even mentioning unix. If your going to complain about user interface complain about the best interfaces developed, MacOS, BeOS, etc, not the worst (in terms of the general user)
If he's complaining about the quality of the user interface of unix (shell, X, etc) then I think he is making the wrong point. Can I complain about the quality of a BMW or Lexus because it doesnt fly? It does what it does, and it does it quite well. As far as I can tell, being an administrator for a web site mentioned in my sig, linux/unix does what it does perfectly.
Now, if he's complaining about the quality of software in terms of bugs as compared to hardware, I dont think this is a fair comparison. Although I'm not an expert of hardware/chips/etc I'm pretty sure that the "paths" that execution can take through hardware is much smaller than through software. Hardware is a low level sub set of the way to execute logic, software is above this and necessarly has more complexity and variablity. Software is also often cranked out a lot faster, and can be patched a lot easier, and microsoft doesnt make chips
Sneakemail is to spam filters what an ounce of prevention is to a pound of cure.
...it takes way too long to develop and it is prone to bugs. This is such a big problem that, just a couple of days ago, NASA and Carnegie Mellon University announced a consortium to find a solution to the problem, even though pundits like Frederick Brooks and Jeff Voas assure us that there is no silver bullet.
/ docs/bug121200.htm
http://www0.mercurycenter.com/svtech/news/indepth
IMO, the problem has nothing to do with designers or programmers. It has to do with the linguistic tools that we use to build software. We use languages to create sequential algorithms. The problem with algorithms is that their sequential nature makes it hard to predict the timing of events. It is the unforseen event that causes the nasty crashes.
Software will not come of age until we realize that computer science is really a subset of communication science. It can all be done with sensors and effectors and other objects sending signals and messages to each other. In hardware it's easy to to time events because of the parallelism. This is why hardware is so reliable: events arrive at their proper time. Not so with software. We need to emulate this parallelism in our software. We need to think in terms of *signals* and parallel objects.
MOBE2001
So Lanier thinks that "Humanity" in general doesn't know how to write software. He believes that it will be 50 years before any good laws are passed regulating software development. If intelligent machines are a foregone conclusion within the next 20-30 years, who says the machines will be letting humans write any code at all in 50 years?
All of the comments about engineering are generally well put, but the biggest problem is in the user and business community. Until engineering software is rewarded and hacking software (I mean just getting it running so it can go to market) is NOT rewarded, software will continue to suck. Rewarding good programming will only happen when the people who buy software stop accepting crappy software and rewarding businesses that market crap with money.
It doesn't take a rat long to realize that stepping onto an electrified plate is an unrewarding behavior. Even business and marketing types (they may have more brains than rats) will stop creating and selling crappy software if it doesn't make money. Competition in the hardware arena forces good engineering behavior by compensating those that produce good product. Who would buy a new CPU that crashes after 56 hrs or that requires you to pull it from the socket and re-insert it after any periferal chip changes? Even a relatively obscure bug in the floating point circuitry can cause a massive recall.
As long as users are willing to pay for crappy software, there will be no improvement in software quality.
d4,...,Nf3, or maybe I should use a Ratfaced Mcdougal?
The problem is that this introduces all kinds of back-compatability problems in that any file format that cannot have an arbitrary-length comment imbedded within the first 4 characters or so would have no attributes or name (it could be opened by using the correct index into the directory).
There are also obvious security problems with a system where anybody can change the owner and permissions of a file. Permissions would have to be an "and" of those in the file and of all parent directories leading to it.
I think the ResierFS has talked about things like this. The problem they are having with their "many tiny files" design is that the required file attributes is far larger than the size of the files themselves.
An intermediate form is to have such a system, but have all "back compatable" files be directories. Inside this directory is a "name", "data", "permission", "date", etc.
On the other hand, OSS's main benefit is huge amounts of code review. In my years of software engineering experience, I've never even seen ONE closed-source company that has a regime of code review even half as developed as Mozilla's, for example. And that's just one example. Almost all OS projects have code reviewed by SOMEONE. At most development houses, you're lucky if your design is reviewed. Code is assumed to be well-written.
So, yes, Open Source Software has flaws as a development model. No regression testing is just one of them. But that doesn't mean it's making software worse.
-marick
p.s. yes, I know there are closed source companies that have code review! There are plenty of others that do not, and it is those that I am referring to!
At a car parts company in japan, a worker forgets to turn on the electrode system that initiates a chemical reaction that makes a protective coating for gasoline tanks in cars. The tanks are then shipped overseas, exposed to salty air, resulting in slight unnoticable corrosion. Cars are built, sold with the gas tanks. Time goes by, corrosion continues. One car gets in a wreck. Corroded tank spills gas, catches on fire, burning occupants alive. Senators then declare that all car parts from japan are unsafe, put tariffs on it. Japan gets pissed, trade war, real war happens.
Check out the book Debt of Honor by Tom Clancy, as this is exactly what happens.
So yes, one mistake can indeed be disasterous.
-
As for Microsoft, they just created their own clone, and called it JScript.
Software sucks because you make more money with the first software to market than with the ideal product. It's a proven business strategy to come out with the first thing, and throw quality to the wind. Operating systems suck because computer scientists don't design the operating systems... companies with $$ invested in a couple different directions do. Companies are not in the business of making software. They're in the business of making money. Microsoft is a good example of this. They're an excellent company. They make lousy software. A good operating system could be made, they could play well with others, fantastic new standards and protocols could be developed, open to all, and beautiful software could be built that makes us all proud to have CS degrees. But if the money's in keeping the OSs the way they are and shipping software that breaks, but shipping it before anybody else and making buckets of money, well, that's what's going to happen. And although I'd like decent software, I don't know that I could blame them for picking the $$$ being that I've never had to make that choice. Whee. But since I posted this late, two people will read it.. hmm.. oh, well. I feel better anyway.
Lanier has managed to stay active in the technology game, working on such cutting-edge projects as the Tele-Immersion Initiative and Internet 2, an experimental, high-bandwidth successor to the current Internet.
... anonymous.. uhh.. (I dunno i'm dumb) BIGGER BANNER ADS AND SMALLER...... shit i'm in the same position I couldn't get out of 5 minutes ago..
How many people are working on seperate replacesments for the internet? I don't think I want to use an internet2. I have a feeling it will be more commercial and less anonymous. Bigger tits and smaller
My point is this: I will not stand by and watch this bullshit errupt. I'm gonna close my browser and open xchat. Goodday sir.
Does my bum look big in this?
One great point he made was that software should be more fragmented by who develops it. Everybody shouldn't try to develop everything. As a database developer, I see this every day. C++ hacks or web people try to develop database apps that are an absolute mess. All software is NOT the same. Just because you can write device drivers does NOT necessarily mean that you can also design a database, or produce a decent web page, or write a good game. Developers need to realize this. The world of 'software' is much too huge for everybody to be trying to do everything. Do you go to one doctor for everything? Heck no! Would any self respecting podiatrist accept a job as a heart surgeon? Heck no! Why are software developers still trying to do this, and in turn, make a total mess when developing outside of their specialties? And, I'm not advocating sticking to a language, but at least one type of software, along the lines of the ones I've already mentioned: device drivers, games, databases, web pages, embedded devices, client-server apps, OS, etc.
They are annoying, time destroying, silicon paperweights.
Much, MUCH better.
When presented with the option to select two items from the list
cheap
fast
good
Guess what you end up with.
You have to admit, he has some certainly good points.
He wasn't ripping on Unix except to comment on the inherent complexity of trying to get anything NON-unix done on it. That's like saying I am having a bitch of a time getting my toaster to do the dishes. It's the best damned toaster I could find, I read all the manuals forward and backwards, but I want to get my dishes done.
And you have to admit, for a 30+ year old interface, it's not only held ground, it's advanced considerably. Funny how english is like that.
What I can wholeheartedly agree with is his comments on software sucking. It does. Duh. How many pieces of software have you used that a) do exactly what you want b) never crash or even participate in the cascade crashes any OS is susceptible to and c) costs what you like it to cost AND d) is available when you want it. I've worked for several software companies and everyone knows what goes on behind the scenes.
But, he's not taking into account the fact that software designers are all working on limited resources and limited budgets and time crunches. Hardware is cool. (Generally) it either works or it doesn't. It's not, "Hmm, I wonder what happens if a user jacks this into 220? Ooooo. Smoke. Let's build a safety into this. I wonder what happens if they throw the toaster into the house that's on fire? Will their toast be ok?" There's so much common sense in hardware. If you plug it in in the bathtub, be prepared for a shock. Everyone knows that. What people don't understand are the intangibles that software designers take (and are sometimes FORCED to take) for granted. If you are running 17 instances of Oracle on a 16 meg machine, don't expect your data to have any integrity. If your OS goes tits up, don't expect your letter to your grandson to still be there when you get back.
I guess I'm rambling. I mean, in short, that there are too many intangibles and too much that is hard to control in the software industry. We're trying to sell something epheremal to people who don't understand the basic concepts. You can't explain what ipchains is to someone and have them be satisfied with it unless they understand ALL of these other things - about IP about networking about NAT about firewalls about ruls about... But with a car, it's simple. You grow up with it. It's there. It goes. It stops. It guzzles fuel. No fancy crap and you don't expect anything more of it because you know the limits. But with software... ok, now I'm getting a headache.
--The statistical likelihood of your existence is so small as to render you impossible.
Any sufficiently well-organized Government is indistinguishable from bullshit.
Is easier to swallow.
I mean, like anything else, after marketing, and rushing out the door, don't most commercial products suck just a little bit?
I don't see how anyone say that a 6 month or 2 year labor of love "sucks", but then, that isn't what we are usually doing at work, is it?
I liked his point about needing to differentiate different types of software, but i'm sick of people bashing linux or M$ or anything else without also suggesting a viable alternative. Any one can bitch, but it takes thought to try to solve problems.
#bitchmodeOFF#
semantics are everything!
Its obvious that he has never used FreeBSD. That might change his views on UNIX in general.
I believe you are thinking about the Virtuality system from W Industries, Ltd. Lanier had nothing to do with this system directly (ie, he didn't develop it - he probably only inspired the developers). On another note, W Industries became Virtuality, Inc (or Ltd?), they are now known as CyberMind, Ltd.
Lanier developed high-end VR systems (ie, the VPL dataglove was a very expensive piece, on the order of $8000 US - they were also instrumentive in the design of the Mattel Powerglove for the Nintendo), with gloves, bodysuits, HMDs, and software, running on SGI workstations (IIRC - someone correct me if I am wrong). High res, high speed (for the time), and highly immersive.
Jaron Lanier is far from an idiot - though his latest views have me a little stumped. Why he doesn't like *nix and such - he kinda clears it up in this article, but I still get the feeling he hasn't really played with it much. Back when he was doing his VR stuff, there wasn't any form of real-time *nix (real-time OS's are nearly mandatory for immersive VR work), now there are several available, many free.
I don't think we should discount everything he has to say just yet - it might just be a case of "throwing the baby out with the bathwater"...
Worldcom - Generation Duh!
Reason is the Path to God - Anon
Since you know someone is watching you code, you cannot fool yourself that some lame hack will be OK because the other person will (presumably) call you on it! ;)
cpeterso
I don't think JL had much of anything to do with a-life - besides, much of a-life can trace its origins back to John Conway's LIFE "game" (a ruleset based primitive a-life).
Did JL bring us VR? Well, he wasn't the inventor of it - like many "inventions", VR was developed by a long series of independant inventors and inventions - ranging way back to the Victorian-era stereoscopes and panopticons, possibly even further, as people tried to bring and recreate an artificial or real world, via an external interface.
Prior to JL, was Sutherland and his "Sword of Damocles" (sp?), years later NASA and thier pilot training and simulation HMDs (big ugly things, but all off the shelf). JL saw this, and thought that he could do it too, and became the first to popularize and market HMDs, Datagloves, and Virtual Reality in general. In the end, his venture failed, and most (or all?) of the patents were bought up by Thompson - and sat on. Someday (actually, it should be someday soon - maybe in 10 years), those patents will expire, and alternate interfaces may take off then (VPL, JL's company - had patents that virtually blocked off all alternate implementations of the glove interface, at least the ones that were most flexible, easiest to use, and easiest to wear and adjust)...
Worldcom - Generation Duh!
Reason is the Path to God - Anon
Actually, he was right in blaming *nix, at the time - since there wasn't any good form of a real time *nix available then (mid-late 80's).
I agree with your sentiment that he should get off his butt and do something - but his VR ideas are not terminally flawed - immersive VR is a different interface for a computer, one no better or worse than, say, a CLI - both have their purposes and applications.
Q3A could easily be imagined as a desktop-based VE (virtual environment) - where the principle use is to run around, have fun shooting at others, and maybe - between frags - talk to another player. Wrap an HMD on your head, allow the software to detect you looking around and aiming your gun with the 6DOF tracked wand - think about it now...
Worldcom - Generation Duh!
Reason is the Path to God - Anon
Mr. Lanier might want to take a look at methodologies such as Extreme Programming, or object oriented analysis, design, and programming, before he judges the human race as being too stupid to develop quality software. He might also might want to take a look at the SEI's Capability Maturity Model (CMM). Or maybe he's never really built any software bigger than a couple hundred lines, or maybe he just craves attention by making brave but baseless claims.
I have yet to meet an average/above average computer user that expects software to work properly or consistantly. Its quite normal for the average office/home user to have their OS and/or applications crash because they have never experienced anything different.
One thing that really scares me is that when I see science fiction things (Runaway comes to mind), it really freaks me out how "junky" (ie, buggy) all of the cool electronic toys, robots, etc are.
In summary, I completly blame the consumer for the state of software suckiness. I would guess that it is due to ignorance of how software is supposed to behave, and their willingness to sacrefice consistancy and reliability for "ease of use" by applications "thinking for them". Most computer users feel pretty powerless over software and just take what they get. These same people would leave their car on the side of the road if their car behaved like their OS/applications.
Lanier's paper, One Half of a Manifesto, is actually several months old. The article referenced at Slashdot is a fluffy interview with the author which includes out-of-context fragments of the original paper. Please read the full paper rather than posting about how shallow the article is.
I agree that this was the most important single statement in the article. However, who is/are "we"? Perhaps I'm kidding myself, but I think that practitioners of the technology appreciate the differences quite well. Sure, I sysadmin my own few Linux boxes... badly. I have a lot of respect for professional sysadmins, who don't really aspire to coding apps (or much else for that matter), but they sure manage a heterogenous network...
Thisn't isn't to say that someone can't be multitalented as an individual, either. (For instance, just try to categorize Larry Wall. :-) ) But the disciplines within IT are certainly very identifiable.
Maybe the "rest of the world" has a tougher time figuring out that software-based IT is multi-faceted. Sure, we all know that doctors and lawyers and engineers each have specialties, and as soon as you need something else done, you have to go to a different one. So why isn't this realization out there in the publics' mind with IT as well? Maybe it's because the public doesn't deal directly with software people -- it deals directly with their software, but not with the people who create it. On the other hand, people do deal directly with lawyers and doctors. So there's a lack of opportunity for education in that sense.
Another possibility is that the legal structures that have built up around the other professions (assuming you can call software a profession) virtually mandate specialization, so that risks can be controlled and liability assigned: you're just not allowed to ask an electrical engineer to build a bridge. Until legal needs enforce structure upon software producers and their profession, software producers won't admit that there are professional categories that need to be maintained... at least, not when such an admission can lock you out of that next juicy contract or product you're aiming for...
Yet another possibility might have to do with the general nature of the people involved in software production: they're young, and likely introverted. They don't handle human-human confrontation well. So, when your boss cows you into being X for a day, then you try to be X, even when you're really Y. The bosses of the world, as all us Dilbert readers know, are thick as bricks and therefore a) come up with dumb requests, and b) don't know any better from their own personal experience. If the "software guy" can't point out the error in their thinking, then why should anyone expect them to figure it out on their own?
Cheers,
Richard
Regardless of the approach, however, Lanier says his purpose in writing essays such as the "One Half of a Manifesto" is to force engineers in both the proprietary and open source development camps to recognize that the issue of software quality has taken a back seat during the past decade. Whether this is due to sheer laziness on the part of programmers in response to faster and cheaper hardware systems or simply a fundamental blind spot in the software design community, Lanier isn't sure.
I say that the problem is all three combined.
One problem I did have with the article is the part about software being expression. Stop this nonsense. Software is a tool, a means to get something else done. Sure, there are some cases (such as the Perl Poetry) that are truly expressions but for the most part the software is written, not for the sake of writing software, but to get something else done. When we realize that the point is not writing the software but getting the work done, efficiently and without problem, then we will be so much closer to where we need to be that we will stop seeing articles like this.
Look at Bob vs. Windows 3.11 vs. DOS 6.22. All are interfaces to the same thing (DOS OS services). They interact with the user in totally different ways. The user cannot possibly judge the real OS inside because he never sees it.
If someone built OpenBob for Linux with click and go for various major apps (WP, spreadsheet, draw prog, etc.), that people like the author would hail it as great.
And while Linux is often slammed for its difficult installation process, who, among those complaining, actually installed windows on their PC? It came pre installed fer crying out loud? You're comparing pre-installed WinOS to the Linux installation process? That's clueless.
I'm not going to disagree with you that FAT is a really bad filesystem, but it is a little more tolerant of improper unmounting than ext2. The obvious solution is to use ReiserFS. It seems to be quite good at recovering from improper unmounting and resumes normal operation very quickly upon reboot. I had the opportunity to try this out last week when I accidently pulled the wrong cord out behind my desk.
_____________
I don't want free as in beer. I just want free beer.
...I just have to ask this question... What do you guys do with all this "open software". Doesn't it suck just as much, if not more than commercial offerings? I understand the hacker appeal, and the appeal of tinkering with the software your machine is running. And I understand the appeal of the underdog, and getting free stuff. But seriously, what good is it? What do you do with it? I guess that has always been an issue for me -- the hacker that I am -- just what good are these computers anyway? I like using them to play on the internet, and to play games, and occasional intellectual pursuits (ie, playing with Fractint), and I get paid for hacking at work, but what advantage does some "open source" solution have over, say, Microsoft's? You'd have to be a total idiot, vision clouded by "open source" narcotics, to not agree Microsoft's OS work fine. You complain about crashes? Well, show me something open sourced, with same functionality, that doesn't crash, or that even exists? Can't do that, can you? In my mind the only enticing open source think would be the Linux/Apache combination... a good server on a good OS, good track record. But seriously, why would I want Linux on my desktop? I make a living as a Windows developer; the complexity of windows attracts me as a hacker, and the complexity will ensure my employment for a long time. But, again, no one in their right mind would claim Unix/Linux/BSD are "simpler" than Windows. You've got to be kidding -- Unix puts the complexity up-front and just doesn't have a much crap as Windows. Windows hides the complexity and probably has more crap than you need. Caving into corporate interests isn't cool, either, but if what you build isn't useful, then why bother. Don't get me wrong - I use and love open source code like expat, zlib, and blowfish.
i know i do.
There is no such thing as unbiased testing.
Let engineering test a product, and they make sure that it has no serious functional flaws.
Let Support test a product, and they make sure that there are no issues that could generate a phone call (personally, they have the best stake, but I'm a support person).
Let marketing test a product, and they'll make sure that all the splash screens and icons look pretty.
Let customers test a product, and they'll make sure it gets the job done.
NONE of these groups is qualified to fully test and debug a piece of software to what you'd consider traditional "engineering" standards. The closest you can come is if you get them all together to design a standard suite of tests to run a product through. With all of these subgroups having a stake in software design, all pulling in different directions, it's no wonder everything's coming apart at the seams.
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
This may be true if most designers WERE approaching software issuses with a real a plan. For the most part software is produced just to "scratch an itch". While this is a great way of getting more programs and programmers, it doesn't improve the quality of what is out there.
Bottomline, when it reaches some sort of Uber Utopian Ideal(tm), where there is no learning curve, when there is no effort needed to use it, when it does it all for you and anticipates your every need (including *those* needs too), then maybe software will not suck.
this sortof goes against the main premise of what it means to be a geeks or something.
It is a road to laziness and slavery of the mind due to incredible mental limpness. (We will do all of your thinking for you, etc.)
But it seem that this is something that certain Large Software Companies(tm) are aiming for.
"It is a greater offense to steal men's labor, than their clothes"
It's funny that the author wants to somehow modify the concept of software so that not all current programs or utilities are considered software, and yet he keeps on comparing hardware to software, two COMPLETELY different things.
Hardware HAS to be re-analyzed and re-engineered because hardware exists in a very real world of electron migration, clock skew, and timing delays as parasitic resistors and capacitors hold back electrons from flying through pathways we construct using circuits, and these electrons occasionally jump out of the circuit because we think of the entire circuit as behaving in a linear fashion when it really behaves in a quantum fashion. Talk about poor engineering! (Note: this is sarcasm. I'm merely pointing out that hardware isn't as fail-proof as we all think). Also, hardware implements only the most basic of functionality. In the time it takes a coder to make an implementation of the RSA algorithm, a hardware engineer might only be able to make a very primitive implementation of a 32-bit Arithmetic Logic Unit that can now add or apply logical operations to numbers. That takes a long time to do a lot less, and is far easier to test. Some things need to be developed quickly, and are complicated nature.
A lot of the stuff in hardware can be logically proven correct, and a lot of software simply cannot. Even then, hardware still runs in to unforseen failures. I can't remember if it was a poster or the author, but someone stated that hardware engineers are less prone to mistakes because they know that once their circuit is printed, it's all over. That's not entirely true. Many complex microprocessors and other pieces of hardware include BIOS functionality that can be updated via flashing. Who knows if Intel could have ever gotten the Pentium 3 to perform with as few errors as it has without microcode updates.
Sorry, but the author just doesn't convince me about anything here. I believe both the quality of hardware and software have greatly improved. Nowadays, we have a Microsoft operating system that doesn't crash all that much (Win2K), an accessible UNIX (Linux with KDE or GNOME), applications I can teach my mother how to use easily (Microsoft Hotmail, Microsoft Word, Solitaire), and development tools that are far superior to what we had in the 1970's that allow us to make more error-free code. Sounds like progress to be, and it doesn't sound like "suckage". NSParadox
Unless mankind redesigns itself
(Open Source Operating Systems).
:).
He seemed to have something against open source programmings lack of standards. I believe Lanier would like a specific programming language standard set, so that all code could be created in a uniform manner (All code being written in C++ for example). His desire seems to be for an overlanguage that sums up the abilities of all of the other languages out there (java/C++/Fortran/HTML...) in an artistic poetic way(he did say literature
Another thing I noticed about the writing on the Edge (http://www.edge.org I think) was a focus on the evolutionary aspect of software/ the global consciousness (internet connectivity)/ hardware. This lead me to believe he also desires people to specialize into certain fields of software design such as: graphics driver specialist, OS directory structure specialist, cool easter egg in excel that looks like spy hunter specialist....
We are supposed to break up software R&D the same way Science branched out into different areas (physics/chemistry-genetics/ biology).
Software could branch eventually - every branch of every field of thought becomes more specialized as time goes on.
In the distance you hear an ominous moo.
I've read a lot of similar rants by a lot of similar VR Hippies in the past and I get the feeling that they want the computer to magically do all their work for them. No matter how advanced this field becomes, I can't ever see that happening, so the VR Whiners will continue to whine about how much software sucks, no matter how much the development process and the designes themselves improve.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Software engineering is not going downhill. It is true that many many open source projects do not undergo sufficient testing, but the biggest ones do. But this is not the point I think he has completely off base..
His statement that 30-year old technology has no place in modern software engineering is a really stupid generalization. Akin to saying that wheels are stupid because they have been around so long with little different about them.
Linux/FreeBSD/Solaris demonstrate that the market is quite willing to work with UNIX systems, and with projects like GNOME and KDE, more and more of what he considers obscure and user unfriendly are hidden from view. That is not to say that it is to the point of hiding things as much as windows, but it is rapidly getting there.
For now, a clear niche for UNIX systems is for people who want more power and flexibility with their systems and know what they are doing. Windows UI does make things easier for the typical user, but it also restricts in many ways power users who want to do some really interesting stuff. NT/2000 go a way to correct this, but if you are UNIX savy, it is hard to give up that power and flexibility, and it is because of this that UNIX is still around today, it is a proven technology.
XML is like violence. If it doesn't solve the problem, use more.