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.

Comments

My feeling

[Trinition]

I have a feeling softwrae sucks because it is not engineered properly.

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.

Re:My feeling

[fhwang]

I agree with most of what your saying, but allow me to take issue with the idea of logical proofs in software. Not that I've done it much, but there are a few reasons I'd rather not rely on this:

• 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.
• There are currently a very small number of people with both the analytical skills and the severely rational temperment required to do these proofs. So relying on that for QA seems like it would put a really nasty bottleneck on the process.
• 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.
• It just seems like it'd be no fun. Don't get me wrong; I try to make my code clean and maintainable and all that. But if I had to run it all through some tortuous logic to prove to myself that it works, I don't think I'd ever want to code at all.

I personally think Extreme Programming holds a high amount of promise. At times it seems like dogma, but in general its principles make a lot of sense to me. Keep those feedback loops tight. Fixed requirements are a myth, so don't ever design for fixed requirements. Well-maintained test cases are as important as coding.

(Of course, I work in a web shop, and the definition of QA in our industry is "Those colors look right in that Photoshop mockup", so it's not like I really know from experience. Just some random thoughts.)

Dammit, the command line is natural

[typical geek]

Lanier pisses me off when he talks about how unnatural UNIX/Linux is with it's focus on the command line. The command line is the most natural way humans communicate.

When you get home at night, and you MOTAS/roomies ask how your day was, do you

• A. Draw pictures and icons of how your day went.
  
• B. Tell them in words how it went.
  

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.

Re:Dammit, the command line is natural

[eXtro]

The command line is the least natural way to communicate, though that doesn't mean its always the least efficient. When you get home at night, and you MOTAS/roomies ask how your day was, do you

A. Draw pictures and icons of how your day went. B. Tell them in words how it went.

You tell them in words, but this is completely different than interacting with a device. Many of the words you use are iconic as well, i.e. figures of speech or metaphors. Consider that Lanier "pisses you off", its a metaphoric way of saying that his point of view is incompatible with yours. We understand what you mean even though "pisses you off" doesn't translate directly to "point of view is incompatible with mine". Body language can be purely non-verbal yet every bit as expressive as verbal communication.

Consider an interface to a common device, a home entertainment system. It's almost purely iconic in nature. You press the on button on your remote control, which may be labelled as "ON" or with "1/0" or just green. This is an icon that is seperating you from the real physical hardware and masking the complexity from you. You don't think in terms of "I'll insert a conductor into the circuit, thus completing it and allowing the flow of electrons". You think "I'm going to turn on the television". The interface to your VCR or DVD player is the same. There's a little triangle pointing to the right, you know that it means play, it doesn't say play and you don't command the player to "spin up the motor, focus the laser and detector assembly for optimal signal/noise ratio and start reading", you push the play button.

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. Programmers need to know the how, and they have languages that allow them to control it via a command line environment. Of course PERL, C++ and CSH are all metaphors. In reality you're controlling the flow of electrons through some 10's of millions of transistors. Oh, wait, the transistor is a metaphor too. If you want to be really accurate you're controlling the doping of semiconductors. But wait, there's more, thats a metaphore too, on the atomic level you're... Wash, rinse, repeat. The complexity never ends.

If only project management was an honourable art..

[israfil_kamana]

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.

Software's not that different

[fhwang]

One of Lanier's points is that he thinks software should be fragmented in practice, since it's currently used in so many ways. To quote:

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:

• Who are the users? What are their needs?
• How quickly are the needs likely to change in the future?
• How long should the software stay out of obsolescence?
• How reliable should the software be?
• How can you decrease the amount of repetitive work that humans have to do?

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.

Change behavior by changing the reward system

[cscalfani]

If you want to change the quality of software, you must first determine why the quality is so bad. Economics is the biggest reason for quality being poor. The reward system in place is one that rewards the company who grabs the biggest market share. Once a product has a stronghold on the marketplace, it is extremely difficult to replace it. Software becomes a de facto standard, e.g. Microsoft WORD.

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.