Slashdot Mirror
Why Programming Still Stinks
Andrew Leonard writes "Scott Rosenberg has a column on Salon today about a conference held in honor of the twentieth anniversary of the publishing of 'Programmers at Work.' Among the panelists saying interesting things about the state of programing today are Andy Hertzfeld, Charles Simonyi, Jaron Lanier, and Jef Raskin."
Please keep in mind that being only nearly 20, the depth of my personal experience is not that of say, someone who was around when UNIX was first rolled out. However, I have been in my day an avid C and BSD (mostly FreeBSD, but some NetBSD) user.
Honestly, from where I sit (you may agree or not), programming and computer stuff in general has become a lot less like a science or craft, and more like a factory job. In the early days programmers who physicists, engineers, and mathamaticians. Today programmers are just programmers. More and more computer science departments are teaching using Java. Why? because it helps people to understand how the computer works? no. Simply, because it's what the industry is using.
I had 4 technicians from Cox over at my house yesturday because my parents couldn't figure out what was wrong with the cable modem. They were the most filthy, disgusting bunch I have ever seen and were dressed more like gas station attendants than professionals. Why? because that sort of work has become blue-collar and low-rent.
Programmers are no longer expected to be educated beyond their field. they are being educated to produce software, not to be COMPUTER SCIENTISTS. How many graduates of say, ITT Tech would actually understand Knuth, even if they have ever heard of him? Likely, not many. That is why software sucks. That is why the programming "trade" sucks. and that is why companies can send the jobs abroad to people who work for peanuts. Programming is just like stamping "Ford" on the grill in a Detroit assembly plant these days and nothing more.
It's such a simple concept. The more of anything we have, the more the mediocre stands out. With millions of writers, we get self help books, assorted garbage, and several really excellent works.
Programming has an artisitic side, the creativity, vision, and insanity required to apply oneself to a project is much like the authoring of a book. Many have the skills, know the principles, but even then, few have the internal extra to create.
I may know language and syntax, but I'm nowhere near the league of Shakespear, Tolkien, Asimov, or Clancey. Fortunately for me, they are nowhere near my league when it comes to putting code together.
We have millions of coders - 60 percent will have average skills, 20 percent will be below average (or plain suck), and 20 percent will be above average, including that rare 2 percent of the absolutely insane, don't let them out on weekends, make sure they get fed, check they haven't peed themselves brand of genius.
Sorry, I don't think any of those people have much credibility left: they have been in the business for decades, they have had enormous name recognition. We have seen the kind of software they produce. If they knew how to do better, they have had more opportunities than anybody else to fix it. I think it's time to listen to someone else.
I admittedly haven't read the article (yet), but I'd like to include a few reasons of my own that programming stinks. As you might guess, I am a programmer.
My friends and I compare a lot of computer things to car things. Most likely, we do that because we are enthusiasts of both. Fast cars and fast software are very similar in many respects.
A little background information on cars is necessary to gain the full effect of my argument about programming. Although the next three paragraphs may seem unnecessary at first glance, I assure you that I am a careful writer and that you should read them.
Car enthusiasts fall into quite a few categories. For example, people who restore classic Mopar or Chevy cars enjoy making everything look like "mint" condition. Usually, every part of the car is so spotless and beautiful that you could eat off the engine. On the other end of the classic car spectrum, there are those who will tub out the entire car and concentrate only on performance features. These cars may not look like much, but they'll break your neck if you push the gas too hard. And of course, there is an entire spectrum of prefenences between these two ideals.
In most of these categories, the hard core enthusiasts like to do the ENTIRE job themselves. They won't let anyone else touch their cars. The wanna be's will usually contract out nearly everything, because they want the glamor of showing up at car shows and showing off their machine, but can't hold a screwdriver and don't know the difference between a 6-point wrench and an Allen wrench. And of course, there is an entire spectrum of car knowledge, experience, and do-it-yourself levels in between these two extremes.
Somewhere in the middle of the two extremes are people like my friends and I. We do a lot of work ourselves, but when it's a complex or high-risk job, or if we don't feel like doing it because it's boring and time consuming, we'll have a professional do it. There are auto mechanics who do pretty much any job. And there are mechanics who specialize in a specific area. For example, I have my radiator guy, my transmission guy, my engine rebuilding guy, my chrome plating guy, my carpet guy, my headliner guy, and the list goes on and on. I use each specific person for the job he excels at because I understand thoroughly what I am about to explain.
Programmers are a lot like the car enthusiasts that I am and whom I describe above. Some prefer to do EVERYTHING, like that guy who wrote 386BSD and wouldn't insert other peoples' code improvements. (The project got forked and now you've got the *BSDs, and that guy is no longer involved as far as I know.) Some prefer to concentrate only on a specific area of software, such as graphics, numerical algorithms, kernel schedulers, assembly optimizations, databases, text processing, and the list goes on and on forever. Even an area such as graphics can break down into a plethora of categories, such as charting software, user interfaces, etc.
The biggest reason that software sucks, in my opinion, is the very same reason that the automotive repair industry sucks. I wouldn't be surprised if programmers are just as hated as car mechanics. The programmer's boss is just like the old lady who takes her car to the mechanic. Neither knows anything about the job at hand. The only thing they know is that it costs them big and the results suck.
For the programmer's boss, the software contains bugs, is difficult and confusing for the customer to use, and takes much too long to develop, so the market window closes, the project goes over budget, and maybe higher management cancels the project altogether.
For the little old lady, the car broke down. The mechanic wants to fix it properly. But doing so will take weeks (believe me). The symptoms are caused by one or more problems, which require several new parts and quite a lot of labor to repair. The parts may be hard to find. The old ones may need to be rebuilt. And generally, people don't like renting a car for t
That sounds like most IT jobs. I've found that IT is different from research and academia. Where I work, at an insurance company, I started referring to what I do as shoveling data. Because my entire job can be summed in one flow chart. Begin, open file, read file, process data, end of file? no. read file. end of file? yes. close file. end of program.
It's mindless. The problem with programming today is that yes, it has become a commodity. Something that people expect you to be able to sit for 8 hours a day and do continuously, without thinking or having any input of your own whether WHAT your doing is really worth it.
There is no creativity in the corporate world, I think thats why so many people choose to work on open source software.
http://github.com/gbook/nidb
"One is, designing the artifact we're trying to implement. The other is the sheer software engineering to make that artifact come into being. I believe these are two separate roles -- the subject matter expert and the software engineer."
Funny chap talking about how design and implementation should be separate. Seems a bit ironic considering he was the one who create Word docs where the layout and content are all packed into one file. Most decent solutions separate the layout from the content (eg: Latex, HTML/CSS). If Simoyi was a web programmer he'd be laying out his html with tables.
> I don't think we are even a little bit closer to that dream today than we were 24 years ago.
The problem, IMO, is that providing a specification that is detailed enough and correct enough to generate a correct program from is just as hard as writing the correct program in the first place.
OK, maybe only as hard as writing it in a slightly higher-level language, but if so, just huse the HLL.
Sheesh, evil *and* a jerk. -- Jade
From your post, it sounds to me like you are doing win32 programming. It also sounds like you are trying to use a bunch of those calls that Microsoft has that end in "ex".
You're right. Those damn calls have so many goddamned parameters and complicated structures to fill out, it feels like you're going on a snipe hunt every time you want to make a system call.
Try Qt. Its not quite as efficient as win32, but for GUIs, it generally doesn't matter. For other things, the key is to make as few system calls as possible and instead rely on the C/C++ standard libraries.
I'm lucky. I get to write commercial software for MacOS X using Cocoa. Still, the bugs I have are mostly due to having to make system calls. When I'm writing code to hold and manipulate data using the STL, I have very few bugs. Where I run into trouble is when I want to use something like Quicktime or other system APIs where I don't really know what the calls are doing and there are a lot of undocumented gotchas.
Avoid Missing Ball for High Score
This is coming from a game programming point of view, but I think it applies to all facets of software development. Programming sucks these days because of the communities it has created.
I'm not going to be a Yancy and specify where these points aren't applicable. Take what you read here with a grain of salt, but I guarantee you can apply one of these to an experience you've had.
- Zealot Trolls.Answering someone's question with a code solution that contains even the pettiest OO fault, even if it has nothing to do with OOP, will get you nothing but a bunch of OOP zealots on your ass, saying 'WRONG! That shouldn't be public' or 'WRONG. The destructor should be virtual' or 'WRONG. Should pass by reference'. You get the point. There are more and more trolls on boards these days looking to stroke their ego by posting extremely minor corrections to mostly correct solutions.
- Wheel Engineers. Stop making 3D engines. Stop making WinSock networking wrappers. Stop making ray-tracers. Stop making things that have been done 1000x before unless a)It's for fun/educational purposes. b) You're going to do something someone else hasn't. Even if there's _one_ thing in your coding project that someone hasn't done before, it's definitly worth it to create. Red-Faction was the last game IMO that added anything new to the world of 3D engines, other than 'taking advantage of x graphics card feature'. Physics is another area to inovate with game engines. Please Stop Re-Inveting The Wheel and giving it some cheezy name.
- Meatless Code. Anyone who has worked with the 3DS Max SDK knows what I'm talking about. Important data is fragmented everywhere, and accessed in 10 different ways. You spend more time reading the API docs than you do programming. I was reading through some ASP.net code the other day, and it took 45 lines to update a table with an SQL command. I read through it, and it could be done with 5 narrow lines of perl code. With C++, you could probably spend a solid two weeks writting generic 'manager' code that does absolutely nothing. Programmers need to learn to draw the line between 'productive' code and 'silly' code. Having a DataObjectFactoryCreatorManager class for 'ping' program, is a bit silly.
If I could do the world a favour, it would be to send all coders a letter that simply said "You are not the best. Live with it.". If I read another reply to a simple question with some dork awkwardly throwing in that he's "A 20 year C programmer who wrote a compiler on a TSK-110ZaxonBeta when I was 11". No one cares about your background unless they ask, or it's relevant.
Other than that, programming is fine. Except for Java.
- Mr.Oreo
Ignoring your snide attack on the previous guy's knowledge - do you really think anybody on /. doesn't know who Raskin is? - I agree with the previous guy that it's unfair to blame open-source coders for producing "more of the same". Let's look at the comments:
They say that "Windows" (meaning WIMP) on top of "UNIX" is a bad idea. Why? It's exactly what Raskin's former employer is currently doing. And Windows is essentially WIMP on top of VMS. Where is the innovation coming out of the leading two desktop OSs? They too are just rehashed versions of decades old ideas.
I don't think it's the open-source community's responsibility to be free R&D for the entire computer industry. Isn't it enough that they are producing free software? Do they have to research it as well? What an onerous task! R&D should be in the domain of researchers and academics. It took 40 years for WIMP to progress this far. Does Raskin think open-source can turn that around over night? If so, then he has more unrealistic expectations about open-source than all the /. cheerleaders combined.
To put it bluntly, I don't think it's fair for Raskin and Lanier to demand such a high standard from the money-poor open-source community when the ultra-rich closed source companies aren't doing any better. Microsoft pumped how many billions into their R&D department and what they did get? A ripoff of J2EE and a ripoff of MacOS X. Apple pumped billions into their own R&D and they've produced Display Postscript... I mean Display PDF... only 20 years after Adobe did it. Colour me unimpressed.
But still, I do not see any suggestions for a fundamentally better model or even any concrete problems with the existing one.
Its the editor!
No, not the IDE, its the model we use.
I've coded almost daily for over 25 years, so ponder this!
We're working the parse tree once removed and are forced into prose by the ancient conventions and a pathetic need to print.
We lack a model in which we work the parse trees symbolically/pictorially using the keyboard. One where we can zoom structurally, rotate and slice our model by patterns, flows and data-access regardless of instance and without regard for 'files'.
From the 'forest for the trees' department.
Cheers!
The problem of near infinite time investment... of time and work versus finite amount of resources for small customer payoffs / results. It takes massive investments of time to get the computer to do some of the most basic interface and problem solving tasks so that humans can do and perform some simple tasks, even today. Tools and compiler/language development needs to get better. Right now many programs are too fragile, very hard for the end users to modify (without recompilation), and they are far from robust. Think of it this way, in an ideal world any program should be able to run on any platform without having to be recompiled and any necessary hardware/software dependencies would be automagically emulated (assuming you have the CPU power). Computer scientists have yet to create decent "building blocks" and tools that don't require a thorough understanding of how the tool itself was made. i.e. you don't expect a construction worker to know the workings of how his tool(s) was made or came to be manufactured or how it works internally, he can use it to perform all tasks from the intended "purpose" without ever having to understand how it was made or works internally from a single domain of functionality. Too many times programmers have to have cross disciplinary knowledge of their tools/etc that should not be required to get the job done. Weak analytic/development tools to help other programmers and new programmers demystify what is going on without having to write lengthly comments to tell other programmers what sections of code mean. This should tip you off right there that if you have to comment and explain something that should be as obvious as reading plain english sentences that mean the same thing you've got severe weakness on multiple person projects that shouldn't be there. No one ever gets confused about- "Today I went to the supermarket and bought some food." with "Today I picked up some food at the supermarket." If you look at computer programming languages today, its like learning a foriegn language because you're forced to "learn the rules", syntax of how the language works AND how it parses and a million other little "gotchas" when it interprets your code. Right now programming tools to create things are simply in the dark age. How many lines of code does it take to create buttons, lists, input boxes, programmer and user friendly functionality from scratch? It takes a massive investment of time and energy today just to create the meaningful building blocks let alone full programs.