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."
here is the link to the ppl on the panel, and talks about their backround
Someone with a @salon.com address submits a story to slashdot linking to a Salon article. That article costs money to read. Slashdot posts the story anyway.
Could an AC please post the full text?
Gates' Law: Every 18 months, the speed of software halves.
It is entirely possible to survive in many companies as a bad programmer who nonetheless manages to be productive and produce seemingly non-buggy code. They may even appear to be especially hardworking and motivated because of the poor design that they have to spend extra time working around as they add features.
The forces that allow this phenomenon to self-perpetuate are:
=Lack of people who know how to manage engineers properly, know how to recognize good ones and bad ones and how to motivate the ones you have to be productive.
=Lack of good project management skills that inevitably leads to crunched schedules and poor quality code, also lack of perception on the part of management as to why software is having problems with performance, bugs or schedule to complete
=Lack of desire to retain good engineers or cultivate improvement in the junior ones
=Lack of communication between engineering and whomever is giving them work, especially regarding desired features and schedule
=Lack of quality control, lack of oversight, lack of checkpoints in project progress
It doesnt help that the concept of "good engineering" is so hard to measure- a few things are "obviously bad" but most things are not. Even if someone is being completely wrong headed about one particular concept, it is entirely possible that they are exceptionally strong in many other areas within that field. It eventually boils down to "the proof being in the pudding" with the pudding being exceptionally complex to make and subject to the whims of the royal pudding tasters when done.
Moore's Law is one reason why software still stinks. Instead of perfecting systems within the confines of a limited amount of resources, its too easy to just assume more MHz, MB, amd Mbps.
With exponentially increasing resources, nothing ever stabilizes and everyone knows it. If people design software with the assumption that it will be totally obsolete and replaced in 18 months, they create software that is so badly designed that it must be replaced in 18 months.
Until hardware performance plateaus and people get off the upgrade-go-round, programming will be sloppy and ugly.
Two wrongs don't make a right, but three lefts do.
It's difficult to believe that Simonyi could be ignorant of the many many years of development of CASE tools and AI projects that have promised to build software systems from specifications.
In 1980, a Professor told a lecture hall of Sophomore Computer Science students, myself included, that almost none of them would have jobs in programming, because in just a few years we would have AI systems that would build software systems from specifications that subject specialists could input.
I don't think we are even a little bit closer to that dream today than we were 24 years ago.
Maybe I'm confusing things here, though. Specifications aren't exactly the same as design. I know that I've sat through some CASE tool presentations where they implied that the work was all done when the design was done, but they were doing some pretty fast hand waving. I believe that those tools did not live up to the promises of their marketing.
Am I off-base here? Has Simonyi cracked this problem with something entirely new?
As a student at a major Big Ten University (tm) I can easily tell that your perception is a bit skewed. The old cliche "you get what you put into it" applies to many things in life, and computer science is no different.
My school's core computer science curriculum is in Java. Language of instruction is a moot point to a rather great extent. You can learn as much from a data structures class taugh in Java as you can from one taught in $language_of_choice. The idea is to learn how things work fundamentally, and then apply those ideas practically. A linked list in Java works the same as a linked list in C. Its not about Java being the "industry standard" as you call it, its about Java being a perfectly modern and capable programming language. The idea
Your next analogy of the cable repairmen almost prompted me to moderate your post as +1 Funny, but when I found out you were not joking I decided to write this reply instead. To even equate a cable repair person with a computer scientist is pure madness. Even if they were programmers, how is getting the cable modem working a good metric of "computer stuff in general" being "a lot less like a science or craft and more like a factory job", or even relevant to the discussion of computer programmers vs. computer scientists at all?
None of your points even remotely explain what you consider the fundamental problem: "why software sucks...why the programming "trade" sucks...why companies can send the jobs abroad to work for peanuts" The fact is not all software sucks, many people love their jobs in the industry, and these people are getting paid well to do their jobs. Most of the computer scientists you speak of don't work in the private sector, you can find them at government research institutions.
To say that these type of people don't currently exist, and that current CS curriculums can't produce scientists of this caliber is nothing short of ignorant.
just remove all+the+search+terms
The same link here with extra words highlighted.
Saying Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders.
Quoting the article: "Giving the [software architects] tools to shape software will transform the landscape, according to Simonyi. Otherwise, you're stuck in the unsatisfactory present, where the people who know the most about what the software is supposed to accomplish can't directly shape the software itself: All they can do is 'make a humble request to the programmer.'"
As a programmer who recently stopped working for a very very very large computer firm that sells both hardware and software, let me say that Simonyi's point makes zero sense. Tools already exist to "shape software," and they are known as programming languages like Visual Basic, C, C++, C#, Java, Perl, PHP, Python, etc...
I'm frankly sick of architects (that's the term for people who say they design software but don't actually design software) who bemoan the gap between their glorious visions and the real products their teams end up producing. These people need to click "Close" on their UML models and go get their hands dirty by writing parts of the production code. Then they'll understand the real-world constraints that their codeless design didn't account for, like internationalization, performance bottlenecks, user authentication, heterogenous networked environments, and ACID transaction support (to name the first few).
Oh yeah, and the reason open-source developers wrote a Unix-like operating system (Linux) and put a Windows-like interface on top of it (X11 + GNOME/KDE) is because these are both very reasonable and mature solutions for a variety of computing needs. If any of you architects out there want something besides Linux that conveniently abstracts away 99.9% of the hardware interaction yet also provides an easy-to-learn interface for general users, you are more than welcome to write it yourself. Or you can model it in UML, click some buttons, and hope it compiles.
Why do I think software sucks? Because market droids and architects who forgot how to program get together and promise their customers AI in only six months.
I hate programming now. I loathe the thought of it. Not because I hate the act of programming, but the systems I have to work with.
Sure, in the nice old days, the C64 and IBM PC were fairly easy to code for, but they also gave you very little bang for the buck. The nice thing was a couple hours of programming could get something nice out.
Now, it can take me a couple hours to do even a simple notepad application from scratch. I'm forever spending lines of code to fill in structures or respond to all the events an API wants.
The computers got more powerful, and the APIs also got more powerful, but now I spend so much time filling out basic structures that I don't need. I'd rather a lot of that stuff was user configurable or stored in an XML file somewhere. I don't want to have to know about allocating & positioning fonts! I just want to dump it in a nice scrolling box.
It's like a bureacratic nightmare writing code now. Sure, there's MFC, etc., but that's like the "easy" tax form. The moment you want to do just one thing different, you're back to square one. And the learning curve, sheesh!
That's why I like projects like XUL. We've made the APIs so programmer centric, that I can't breathe anymore. I just want to code the important stuff then let someone else make the GUI pretty.
The bitter lessons of a veteran coder: http://bitterprogrammer.blogspot.com
The first thing you have to realize is that software is being written at a much higher rate now than it was back in the days when programmers were physicists and mathematicians. That's because it no longer takes a rocket scientist to write a program, and that is a Good Thing (TM). If the programming learning curve hadn't come down, we wouldn't be living in the wonderful information society that we are today, because there simply aren't enough rocket scientists to hammer out every PHP script and database app one might desire. The technical aptitude of the people working on the foundations of computing is certainly not degrading as programming becomes more democratized, because those people's talent and skills are not forged in some intro programming class. Every hacker knows he learned his art outside the classroom. So it's not exactly logical to assume that colleges could turn out a crop of brilliant innovators if only they used Haskell, read Knuth, and taught all their CS students physics and numerical analysis on the side. Clearly, what would actually happen if one simply cut the lowly Java-bred programmers out of the programming craft is that a lot less bad software would be written, a little less good software would be written, and all of it would cost more. That's not exactly an improvement.
None of this is to say that there are not pervasive (and addressable) problems in modern software engineering. Those problems are simply much more endemic to the state of the art of programming than they are to any particular group of people. As many have pointed out, software today is brittle. It is frequently opaque, offering users and programmers alike only the most rudimentary means of debugging. The bread and butter software used by everyone everyday is often monolithic, designed for one purpose and impossible to customize without intensive study. Think about it for a moment, and you'll realize that much of the functionality of a typical document-editing application is duplicated in any other. In principle, such functionality could be factored out. But I can't digress too far into that here - let me continue with the list of reasons why software sucks. Integrated development environments give programmers a view of a project that scares poorly with complexity, software is incredibly difficult to build from source (unless you use Java--heaven forbid that should find its way into the bubble of intellectual purity you inhabit), and perhaps worst of all, the design decisions and architecture of software are usually not expressed clearly anywhere except in source code, where they are obscured by all manner of syntactic complexities, compiler optimizations, and details that aren't significant to the overall intent of the code. These things--all the things that make software complex, which make it difficult for groups to work together on large software projects (as you would understand if you'd ever worked on one)-- are some of the real hurdles to be overcome in software engineering. ITT Tech and outsourcing to India are NOT the problem.
I haven't said much about how to solve any of these problems. But I've said a lot, so I'm going to stop now. I highly encourage you to get some more experience and perspective before you make sweeping and arrogant generalizations. College-aged know-it-alls with overblown rhetoric are a dime a dozen. Real problem solvers are rare.
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
Another problem is that if you change types, you have to change the names, too. Or if you don't, you end up with a completely misleading code.