Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Making Software Suck Less

timothy posted more than 12 years ago | from the like-frank-lloyd-wright dept.

Programming 315

That much software sucks -- perhaps most of it -- is hard to dispute. Except for the simplest programs, it seems like the price of complexity is a tendency to failure. Commands don't work, user interfaces are neglected to the point of ruin, and components of even the same piece of software often clash with each other. And once you start combining them and try to use more than one application at once, sometimes the best you can hope for is an operating system that neatly segregates the problems so that your word processor doesn't take down your web browser, your IDE or your e-mail client. At least those are desktop applications for individual users, though -- the trouble compounds briskly when the common faults of software manifest in multiuser environments, where one machine going down means a wasted time and frustration for a lot of people at once. In an effort to outline the ways that software could suck less is coding, reading and writing dervish chromatic.

Making Software Suck Less - Processes

Once upon a time, a prominent writer and programmer rose to declare "I want software that doesn't suck!" He then explained that certain successful free software projects have similar development features that contribute to software quality. Most of us aren't gifted with the organizational clarity of a Linus, or the brilliant non-orthogonal design of a Larry.

There's hope, though. Improving the ways in which we produce software can dramatically improve the software itself. Extreme Programming suggests that simple habits, acting in concert, produce extremely powerful results. By adapting these techniques to the unique world of free software, we can improve the quality of our programs. We start by restating some common truths about free software development.

Distributed Development

Open development, of course, means that anyone with the time and the inclination can look at the code. Developers and dabblers have the opportunity to modify it to their needs. This by no means guarantees that anyone will do so. Making source code available is no silver bullet. Many qualified eyes actively looking for bugs make bugs shallow.

To harness the power of additional developers, you must attract them to the project. A simple design and clear documentation reduce the amount of work needed to come to grips with the system. XP suggests an overall metaphor to describe the system as a whole and to provide good names for the components and subsystems.

Test First

The most powerful weapon in your toolbox is comprehensive unit testing. (Unit tests are automated, independent procedures that exercise the smallest possible pieces of functionality individually.) Extreme Programming recommends a test-first approach. Before adding a new feature, the programmer writes a test for the feature and runs all the unit tests. The new test fails, so he writes code to pass the test. When all tests pass, the feature can be checked in. Tests cover everything that could possibly break.

When a bug appears, the programmer writes tests to demonstrate it. After fixing the bug in the code, he runs all tests again. This not only proves that the fix corrects the defect, but it proves that the correction did not break any other features. Besides that, it can prompt the programmer to write additional tests he had not previously considered.

Test-first programming ensures that all features have unit tests. Coders receive immediate feedback -- it's almost like a game. It produces a different mindset, freeing the programmer to concentrate solely on the task at hand. Code becomes easier to write, in the same way that finding the correct piece for a jigsaw puzzle is easier with its neighbors in place. Finally, it gives programmers the confidence to refactor, modifying existing code, by identifying the effects of a change.

Consider providing your test suite with the project. Add a 'test' or 'check' target to the Makefile. Projects designed to run on multiple platforms and distributions can generate better bug reports by including test results. Make it easy for users to report failures.

Simple Solutions First

After writing a test, write the simplest possible code that could pass it. Resist the tendency to make things more flexible than you need at the moment. Concentrate only on the task at hand, programming only what you need to pass the test. Don't sacrifice current elegance and simplicity for a feature months down the road.

"It's true that 'simple and tested code means less bugs'.... Good and clear interfaces reduce bugs. Avoiding complexity reduces bugs. Using your brain before you code something up reduces bugs."
Good tests free you to change things in the future by identifying the effects of a change. Simple code localizes changes, reducing interconnections. Besides that, your design will change. Adding a feature will take the same amount of time whether you do it now or in the future. Don't spend time and energy overgeneralizing for something six months away when no one will use it in the meantime. Reduce the need for costly and time-consuming rewrites by avoiding extraneous complexity.

Have a Plan, Code For Your Users

Write a plan for the software. Describe each feature in a paragraph or less, with sufficient detail that people will know when it is complete. Arrange the stories by importance, then tackle them in that order. This allows you to identify the work that will provide the most value to the customer. (In a free software project, the lead developers may be the customers.)

Dividing the project into stories allows delegation, especially in free software projects. Some tasks require an experienced hacker, while others serve as a gentle introduction to the program. Writing stories also provides sane goals and a project roadmap. Choose a few stories for each release. This gives end users a clear view of project progress.

Continuous Design, Refactor

With tests in place, you have the freedom to refine your initial design. By using the simplest solution first, you avoid investing time in hard to follow and difficult to maintain code. Your initial design will change. Your plan will change. Expect this and allow it to happen.

"Premature optimization-including premature low-level design--is the root of all evil."
When you see an opportunity to refactor, do it! Eliminate duplicate code. Relocate common features into a new object or a function. Reduce complexity and interconnections. Don't maintain the same functionality in multiple places. Use simple, well-defined, and consistent interfaces. This, along with your test suite, will allow you to overhaul individual pieces without having to track down holes in far-flung files.

Release Often, Release Working Features

Commit to regular release dates. This shortens the feedback loop. Users who can count on regular, stable releases with valuable new features will be more likely to use the software. It also provides more frequent entry points for new developers.

Follow your plan to add a few important features to each release. Focus programmer time and effort towards a simple, reachable goal. Allow time for design, testing, documenting, and packaging. The more often you have to do this, the more likely you are to streamline these processes. Resist the urge to add features you cannot complete in time. Instead, break them up into smaller stories and implement the most important parts. As usual, the unit tests help to stabilize the codebase and keep it in a state of stability. After completing a release, take time to modify your stories, shuffling priorities as necessary. Then commit to the next release.


If we truly want excellent software, with well-developed features and no messy surprises, we need more discipline in our approach to creating software. In my experiences with these techniques (and in talking to other developers), I have found that even simply migrating to a test-first approach, though painful, has increased my productivity and my confidence. It's scary at times, but immensely satisfying. Taken together, who knows what levels of excellence we can reach?

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


Re:Most of us don't have this option... (1)

dbarron (286) | more than 12 years ago | (#486988)

My condolences on the death of your website. But seriously, I always wished time and management would allow one to design two web sites. 1) this is the one you told me to do 2) this is the one I think you should have. Now go compare them and see what YOU think. Of course, if the customer has crappy taste....what a waste of time. Often when I've had the opportunity to do something like this...ppl do swing around.

Premature optimization root of all evil! (1)

Kaz Kylheku (1484) | more than 12 years ago | (#486995)

That quote should be attributed to Donald Knuth, not Abrash.


Isn't this just common sense exemplified? (2)

Proteus (1926) | more than 12 years ago | (#486997)

It seems to me that these techniques, while sound, are one of two things -- either simply common sense, or needless rules.

The problem with too much structure in a process is this: either you are making rules for things that are done intuitively, or you are confining the creative process. I have used a lot of free and open-source software, and I would guess that 80% of projects that are in the 'stable beta' stage are of higher quality that the average commercial application.

YMMV, of course.


Re:Software Engineering will make software suck le (3)

Proteus (1926) | more than 12 years ago | (#486998)

Companies are willing to hire programmers without degrees for a combination of two reasons: (1) they can be just as good, if not better than, a software engineer (in some cases); and (2) they work cheaply.

I know many programmers that, despite having no 'formal' training, can run rings around the Software Engineers I know. IMO, formal training often reduces the ability to think creatively -- once you are taught "the right way", it's hard to break new ground.

All of that said, I do agree that companies hire people without checking thier abilities. When I interview a potential candidate, I ask them to design code for a small, arbitrary problem. If the design is solid and the code functions smoothly, it goes a long way.


Is this really groundbreaking? (2)

boinger (4618) | more than 12 years ago | (#487000)

While I like the message, and perhaps re-iteration is good for the PHBs, I think all of the coders who dwell on Slashdot know this and try to make it their own (well, the good ones do, anyway).

And, if people aren't aware of what it takes by now, do you really think they're going to get it, now? Save for perhaps the younger folks just spreading their programming wings, I guess.

Okay, fine. say it again. If a few people get the message it was worth it.

Re:As long as non-coders are involved in coding... (2)

Schoos (4736) | more than 12 years ago | (#487001)

No, definitly not: You need noncoders during the development process, or your software will suck as well. Coders have quite a different view than normal users, and so they need someone to tell them "Hey, this is unusable", or "Hey, I'd like to do it that way".

Non-Coders should talk place in the process, testing the product, working with it, helping to get it out, but they should stick to "easy" coding tasks: defining user interfaces and such things.
The backend of an app should be reserved for they guys that know what they do ;)

Works pretty well (1)

eGabriel (5707) | more than 12 years ago | (#487003)

We used this method when I was contracting at Deja.com, and several times we delivered much sooner than expected, and the expectations were typical.

One problem is that XP calls for pair programming, and a lot of teams are really too small to always have a pair. In those cases, you deal; write a small chunk of code, test and commit quickly, and try to have a partner on the next cycle.

XP isn't rigid; you have to tweak it to your needs. If you find yourself objecting to it on the basis of areas where it doesn't fit, try the bits that do fit and see what it buys you.

VB is not bad. (2)

jeff.paulsen (6195) | more than 12 years ago | (#487007)

Try making a 30-screen database app in Visual Basic. Actually no; don't ever try that. Just beleive me when I say that it's damn near impossible to produce a good product that way!

I've done it repeatedly. It's not nigh-impossible - it's just not like writing in C. You have to bring the same professional attitude toward it, though. Design well, profile before optimizing, refactor, test, test, test.

Which "useful language constructs" are missing? Even in VB 3, which lacked even rudimentary object orientation, we (less than 4 full-time-equivalent employees) managed to write a 90+ screen casino accounting package. Performance was excellent even on the 486-100s of the time. Modern VB is far, far better, and VB.NET better still.

I use other languages as needed. Perl is fine for anything that won't leave my own machine. Occasionally I'll find something I can do much much better in C than in VB - in which case I write a DLL and call it from VB.

I agree with your point that experience is critical. Please consider that language bigotry is the enemy of experience.

Say no to stupid fucking requirements (3)

gelfling (6534) | more than 12 years ago | (#487009)

Does it REALLY have to make toast, brush your hair, whisper in your ear, service the wife, numerically prove the existance of an afterlife, feed the world and have good beat you can dance to?

C'mon scope creep and stupid fucking requirements (SFR) are what generate sucktocity and general sucktitude. How many times have you listened to some account weenie get on all 4s and scarf the customer over and over. "Sure we can do that, no problem !!!!!!!"

But it's an SFR and it will kill you.


Re:OK I'll bite (1)

Cederic (9623) | more than 12 years ago | (#487020)

System tests yes; unit tests should be written by the programmers writing the code, as they write it.


Re:Software Engineering will make software suck le (2)

Cederic (9623) | more than 12 years ago | (#487023)

Most accountants do not have a degree in Accounting.

Most of the best software engineers I have known have done degrees such as Physics, or don't have a degree - I am working with a guy my age, who has twice the industry experience that I do, because he didn't go to university. And he knows as much Software Engineering as I do, and I study it for fun outside of working hours. And we "do the right thing" when we're writing our software.

Don't be elitist and assume that a degree is everything - my experience is that a degree is almost irrelevant, it's the experiences that you gain at uni that count, and it's industry experience and good tutelage from experienced engineers that make good programmers and software engineers.


Re:Isn't this just common sense exemplified? (2)

Cederic (9623) | more than 12 years ago | (#487024)

Although I agree with much of what you are saying, I have to pull you up on the unit testing - how many open source projects have unit test suites that can be run in a few seconds and tell you instantly whether or not all the tests have passed?


Re:OK I'll bite (2)

Cederic (9623) | more than 12 years ago | (#487025)

You write your tests at a very basic level. And you test your tests.

E.g. Lets take a very very contrived (and poorly designed) piece of software:
I want to write a web browser. Lets keep it simple and assume I'm just connecting to a server, downloading some HTML and calling an existing object to do the rendering.

First off, write a test testing whether you can connect to the server. Write the skeleton code of your connection class only as much as you need for your test to compile.

Run your test - it fails. It has to fail; you haven't written the connection class yet.

Now write the part of the connection class that connects. The test passes.

Now shut down your test server. Re-run your test. If it fails, you know your test is working.

Now write your test that checks whether you can download a file (ideally html) from the server. Run it. It fails - we haven't written the code to retrieve a file.

Write that code. Run the test. Does it pass? If it does, we've finished that piece of code. But, remove the file from the server. Run the test again. Does it fail? It should - if it doesn't, it's not testing the right thing. Put your file back, and move on.

We need to validate that we got a file back (because our last test failed when the file was missing) - so write a test that validates this. Run it. Does it pass? Assume it fails. Ok, change the connection class so that the validation works properly. Run your test - does it work. Yes. But, while adding the validation, we broke the file retrieval. And now that test is failing. So now we make the changes needed so that the file download test works.

Run the tests. Always run all the tests. Do all three pass? If so, move on. If not, fix the code.

Suddenly we have a complex connection class, that's doing connection, validation, file retrieval. Disregard for the moment our poor design, ignore the obvious refactorings that are leaping to your mind, and consider the tests. Do we trust them? Yes we do - we've built them individually, we've tested the integrity of each test by making sure we can force it to fail, and one of the tests has already caught a potential (albeit obvious) bug for us.

So taking a methodical approach we can build up a suite of 4-500 tests, and be sure that they all work. And since they all pass, we have an immense amount of confidence that our system works.


Re:Is testing code some sort of new idea? (2)

Cederic (9623) | more than 12 years ago | (#487026)

It's not new, but XP is the first methodology that I've seen that takes unit testing to the extent that it does. And what frightens me is that nobody taught me, showed me, even suggested to me that such testing could so easily be done, so effectively, and with such a beneficial outcome on the code I write. I owe Kent Beck, Martin Fowler and a few others (whose books I've bought) big thanks for that alone.


Re:Most of us don't have this option... (2)

Cederic (9623) | more than 12 years ago | (#487027)

Most of the steps suggested in the article will result in better code being produced in less time overall.

Plus, if your manager asks you what you are doing, and you answer, "Writing tests" then he's going to love you.

Sneak these practices in the back door. Or even talk to your manager about them - complain about the low quality code you are being forced to produce. Demand the resources to do it properly. Insist on being permitted a small degree of professionalism. If you approach your boss with a list of things that are wrong with your current development process, and some suggested steps to improve them - especially if they involve writing tests, meeting user requirements and using source control systems - then if he doesn't agree these are good things then it's definitely time to find a new job.


Re:What about existing software? (2)

Cederic (9623) | more than 12 years ago | (#487028)

Buy the book "Refactoring" by Martin Fowler. It has a whole ton of useful advice, techniques and methods for people in your situation. I rate is as perhaps the single most useful software engineering book I've read.

For instance: If you are going to change code that isn't unit tested, then add a test for just that piece of code you are about to change. That takes a few minutes only. And add tests to the other parts of the system only when you change them.

And use tests to recreate the bugs you are about to fix - then you know you've fixed it (because the test passes) and you'll know instantly next time someone changes the code to make the bug occur again - because your test will pick this up.


Re:Software Engineering will make software suck le (2)

wik (10258) | more than 12 years ago | (#487030)

CMU currently has an undergraduate software engineering course in the CS department. The course tends to turn out pretty lousy projects in the end. Last semester they focused too much on the process and too little on the code (as they left around two weeks to write code and shoved test under the table). Some semesters go better than others.

At least one of my undergraduate courses (Distributed Embedded Systems, in the ECE department) had a significant focus on the process of designing and managing an embedded system. We used a watered-down UML and requirements, wrote tests suites and did forward and backward traceability to make sure the requirements matched up with the diagrams. Then we wrote code (and had a very short debug cycle because we found most of our bugs in the design before coding).

There are also graduate courses in and out of the SEI building which explore (or attempt to fix for real-time embedded systems, in the course in which I am currently enrolled) these processes.

uh, okay (1)

kaisyain (15013) | more than 12 years ago | (#487037)

The title and the summary didn't mention this was going to be an XP feature or I would have skipped it. What's the point of a summary if it doesn't accurately summarize the article?

Re:uh, okay (1)

chuckw (15728) | more than 12 years ago | (#487038)

Dude, that was Jamie [mailto] who did that write-up [slashdot.org]. Do some research before shooting off your mouth. Moron!
*Condense fact from the vapor of nuance*
25: ten.knilrevlis@wkcuhc

Re:Software Engineering will make software suck le (2)

TWR (16835) | more than 12 years ago | (#487040)

If anything, software engineering should be like an apprenticeship.

And I agree completely. As I said in my original post, a CS degree is NOT a Software Engineering degree, and it's training in Software Engineering which is needed. An apprenticeship should certainly be a part of the program.

So I think pretty much everyone (except you obviously) knows that they are not hiring geniuses

No, the problem isn't that you think you're hiring a genius, it's that the untrained ignoramous that you hire thinks of HIMSELF as a genius.

There was a well-publicized study in 1999 or 2000 on just this topic. The more someone knows about something, the less competent they tend to evaluate themselves. Conversely, the less someone knows about something, the more they think they are competent. This leads to wildly unrealistic self-evaluation.

I'd bet that the professional programmers who DON'T have degrees in CS tend to consider themselves better programmers than the degree holders. Draw your own conclusions.


Re:Software Engineering will make software suck le (2)

TWR (16835) | more than 12 years ago | (#487041)

This same problem faces universities trying to create a software engineering school that is teaching to an ever moving target.

And yet Chemical Engineering and Electrical Engineering can be taught. Amazing, that. I guess there haven't been any advances in those fields, either.

If Software Engineering has changed SO much in the last N years, why is "The Mythical Man-Month", written before most /. posters were even born, still considered the best book on Software Engineering ever written?


Re:Software Engineering will make software suck le (4)

TWR (16835) | more than 12 years ago | (#487047)

IMO, formal training often reduces the ability to think creatively -- once you are taught "the right way", it's hard to break new ground.

Bah. Would you hire an architect to design a house for you without formal training? (I don't want to hear about Howard Roark; he's a fictional character in a poorly written book) Would you hire an untrained civil engineer to build a bridge for you?

There is no relationship between formal training and creativity. There IS a relationship between formal training and knowing what will work. Geniuses know how to push the limits on what will work and create new paradigms. Most untrained people in any field (and heck, most people in any field) are not geniuses, and the less people know, the more likely that they think they are geniuses. That's the real danger.


Software Engineering will make software suck less (5)

TWR (16835) | more than 12 years ago | (#487048)

The real problem isn't a particular methodology like XP (which does have good ideas in it), it's the complete lack of professionalism in the software industry.

How many times have people heard of programmers with no degree working on or designing large-scale projects? It's insane. No one would hire an architect or mechanical engineer who didn't have at least a piece of paper from a college. But it happens all the time in software. The costs of the defective systems being turned out by untrained programmers is starting to matter.

Even a CS degree really isn't a sufficient solution to the problem. Software Engineering is NOT computer science, just as Chemical Engineering is not Chemistry. You need knowledge of the latter to do the former, but there is a different skill set which must be learned. Unfortunately, I'm not aware of any school which is teaching it to potential software engineers. When they do, real software development can finally begin.


Check out these guys! (1)

Maktoo (16901) | more than 12 years ago | (#487050)

They already have it figured out.

BareBones software "Software that doesn't Suck"


This is not groundbreaking, but it's IMPORTANT (3)

drenehtsral (29789) | more than 12 years ago | (#487060)

I always see a lot of people saying "this is all just common sense" or "this is nothing new" or whatever, but if people followed this set of guidelines, there would be a lot fewer bugs out there irritating computer users.
A similar strategy is set forth in some of the newer computer programming books i've seen including "The Practice of Programming" and "The Pragmatic Programmer", both of which aim to develop habits in programmers that cause them to produce cleaner saner code in a practical and intuitive way.
I think this is important because it is a practical alternative to the people who say "all programmers should be licenced and regulated, they should all have degrees, and all their code should be mathematically proven and group audited" while this will produce space-shuttle or medical-instrument grade applications, it will also produce space-shuttle grade costs. When you have to pay $125,000 per seat to use your word processor, but it's bug free, it's just not worth it.
These common sense practical approaces are more efficent than standard high pressure, low quality, commercial software development in terms of man-hours spent developing the same software, and as an added bonus, the software works better, and when it does have bugs, they are easier to track down.
So, no it's not new, it's the advice from older programmers who have been doing this since _way_ before i was born, so i should listen to it, not ignore it because it's not new....

Configuration Management Tools? (3)

a.out (31606) | more than 12 years ago | (#487061)

How important do you guys value Configuration Management Tools (tools that aid in the process of developing software)? I think they are very important to the development process. If you don't use them you're dead in the water.

The design, development, testing and deployment of software is a very iterative process. What kind of tools do you use that you have found to match this process and be very sucessfull?

I realize that these tools have to be easier to use and have more benifits to using them than not to use. But what would be an ideal situation for the development of "software that doesn't suck?"

Re:Software Engineering will make software suck le (1)

lomion (33716) | more than 12 years ago | (#487063)

Wit hsoftware its the design phase not the coding that is the most important. Any monkey can code but finding someone who can design a good piece of software is hard.

Often times time constraits force people to take shorcuts they shouldn't to release buggy or incomplete software. Thats the real problem , no one is taking the time to do it right the first time. They think, oh i'll just post some patches on our website, or i'll get them on the upgrade with that fix. Lack of ethics and lack of professionalism and lack of time all contribute.

The other big issue is communication, many times the clients needs are not fully understood or the project manager doesn't know what questions to ask or assumes information is known.

When these things are solved perfect software may be a possibility.

Re:Software Engineering will make software suck le (2)

Tower (37395) | more than 12 years ago | (#487069)

The problem isn't usually the implementation, but the lack of proper architecture and definition... once the problem is clearly defined, any good programmer can solve the problem. Getting the puzzled divided into the proper sections, and making sure that all of those pieces fit together in a nice way - that's tougher.

Software engineering isn't about the "passed in this stuff, do a bunch of stuf and spit this out" as much as it has to do with defining what will be passed in, what is spit out, and properly controlling those interfaces. Since you have already given them a small, defined problem, the Sotware Engineering portion is taken out of the equation. It's architecture, control, and testability, rather than the specific methods to a given function.

Re:Isn't this just common sense exemplified? (1)

QuantumG (50515) | more than 12 years ago | (#487077)

Gee, could it be that you think this because you havn't read the book (Extreme Programming Explained by Kent Brock) or indeed didn't read the above?

test first (2)

QuantumG (50515) | more than 12 years ago | (#487078)

I always write my test cases first. Well, I write the first test case :) Then once I've written the code I think of a few more test cases and add them to the test unit. So for example, if I have a class called Power, I create a class called test_Power and add a function to test each of the functions in the Power class. I then put a main func in the test_Power.cpp file and put the tests as the first thing in my make script. Just the other day I had an interesting one. I had to go down and up two sorted (stl) lists and build sets of the data within a certain range. Then I had to do a set intersection of the two sets and return the resultant list. For my test case I generated random data and pumped it in. The result was scary. I would do a make and get a segfault. Sometimes I would immediately see the problem and go and fix it, do a make and get another segfault. Moral: throw enough random data at a function and it will expose all your bugs. So after the segfaults are fixed you're left with the cases that run to completion but give the wrong results, which is even more annoying. So then you usually have to fire up gdb and figure out what exactly went wrong. Oh, and you can get carried away with this. Sometimes you think: I'll run the tests overnight and see if it fails any tests on some obscure case and just when you think it is rock solid it will fail a test after 10 hours of running. You have to be careful using random data too cause you're test data might be so random that is nothing like what will actually happen when you start using that function. ok, I've rambled enough.

Re:OK I'll bite (2)

QuantumG (50515) | more than 12 years ago | (#487079)

Yes.. it is not flawless but it is better than coding the function and then saying "oh, that'll do.. I guess that'll work" and then some blatantly obvious test case crashes it and causes a segfault that the user just sits there staring at dumbfounded. Oh, and writing the test case first makes it easier to write the function and thus increases productivity. Surely you are aware that hunting down bugs is the biggest time drain in development?

Re:Is testing code some sort of new idea? (2)

QuantumG (50515) | more than 12 years ago | (#487080)

The key to XP is that he (Kent Brock) insists that you do all these things to extreme (thus the name). So you should write automated tests, intergrate quickly, pair program (yes, that's pretty lame but you can replace that with a less extreme "peer review"), etc. All this stuff works together to create tight feedback loops that get you to market under budget and before schedule with quality software.

Re:The easiest way to make software suck less (2)

QuantumG (50515) | more than 12 years ago | (#487081)

it is an interesting point. The warranties would have to be significantly vague however, no-one expects bugless software, that's just too damn hard. Maybe when we have good verification techniques this could happen, but that will require good specification techniques :)

Re:As long as non-coders are involved in coding... (2)

QuantumG (50515) | more than 12 years ago | (#487082)

I know guys that have written very good database oriented systems in VB. They're M$FT geeks but they can produce a product.

Re:Software Engineering will make software suck le (3)

QuantumG (50515) | more than 12 years ago | (#487085)

how many hundreds of years have we been building bridges and houses? The problem with formal training of Software Engineers is that the stuff that academics think that software engineers need to know is a lot different to what industry thinks they need to know. If anything, software engineering should be like an apprenticeship.

Oh and the reason why we call people "geniuses" is because they are a minority that have higher intellect (or whatever the hell you want to call it) than the majority of the population. So I think pretty much everyone (except you obviously) knows that they are not hiring geniuses, nor do they expect geniuses (actually that's one of those things about geniuses, you never really expect to run across them).

Uh, QA? (2)

British (51765) | more than 12 years ago | (#487087)

Your statements are wrong. You can't just rely on unit testing alone to fix all the bugs or "suckiness" in an app. It takes a lot of time to test the simplest app, time usually the programmer doesn't have. Envision "Quality Assurance" that does a helluva lot more than "unit testing".

How about usability testing? While the coder may make a program that he/she finds logical to use(not necessarily easy to use), the general public(unless you're just writing the software for yourself) may find it extremely difficult or impossible.

Your statements about non-coders should stay away from the coding process(or perhaps I should say development process) sounds a bit elitist.

a language that doesn't suck (1)

eric17 (53263) | more than 12 years ago | (#487088)

Processes are important, but it would not hurt at all if there was an OO language that was fast, powerful, elegant, didn't require a virtual machine, and had something of a C-ish flavor to it. Dream on...

Re:Software will still suck.. (1)

Saige (53303) | more than 12 years ago | (#487091)

In the case of your average software developer, both of these are happening. Good programming practice gets put on the back burner because they *need* to ship.


One of the great things about the last project I worked on was that our group manager told us that the schedule was HIS problem to work out. We were to tell him how long it would take to do something right, and he'd take care of making sure we had the time to do it.

You know what? Since we were never getting the schedule shoved into our faces, we did things well, and pretty much on time.

Re:What about existing software? (1)

Saige (53303) | more than 12 years ago | (#487092)

But if there is no unit testing, then there needs to be an extreme effort to integrate it into the code. This isn't productive - you are adding no new features, and, until you have completed the test suite, you aren't sure that your test code isn't breaking something!

Umm... what kind of unit testing are YOU doing? All the unit testing we've done has been "self-contained" - as in we haven't needed to do anything to the code being tested to do so. All the work on testing is done in seperate test drivers, stubs, and makefiles.

For some reason, the idea of changing code that's being tested to do the testing sets off major warning bells to me.

If it's because you don't have any small pieces of code that are easy to access individually to test, then well, that's a sign that complexity is a serious problem.

Re:What about existing software? (1)

Saige (53303) | more than 12 years ago | (#487093)

you aren't sure that your test code isn't breaking something!

Umm... this is a quote from the original message. If your test code is seperate, then it can't break something.

And you don't have to write tests for everything all at once. We just wrote tests for the functions we actually touched ourselves. There were plenty more that needed them, but because we didn't modify the code for our release, we didn't worry about the tests either.

Yes, it did take a lot of time. Yes, I spent a few weeks writing test driver after test driver after test driver until the tedium was getting to be a big problem. But the code was better because of it. And those tests are now there, and they won't have to be written again, just edited with new features. (Assuming that people don't ignore them for a few releases until they reach the point of being obsolete. But then again, I'm getting out of here soon for completely unrelated reasons, so I really don't care that much if they do that)

Process and Testing (5)

Saige (53303) | more than 12 years ago | (#487096)

As the article said, those two are by far the biggest steps you can take toward making good, quality software.

I recently helped to add that CALEA surveillance garbage to a certain cellular system that was kinda news recently due to working with Sega on games for the subscriber unit, etc, etc. I didn't want to do it, most people I worked with didn't want to do it, but we still took the time to do it right.

We followed software processes, tailored to eliminate unnecessary steps, and adding ones useful to us. We did quality unit testing on everything we touched, including functions that had been around for years. We re-wrote any DOL and function comments that were hard to read or out of date. And that was most of the old ones we touched.

We took the time to break old functions that had grown complex (20+ cyclomatic complexity) into smaller pieces.

Guess what? Not only were we just about on schedule (even with the extra time fixing problems left by other people), we found defects that had been sitting around that nobody knew about, and within maybe a month from the time we hit the system test lab, the area of the box we worked on was more or less defect free.

We put more effort into process and testing than people had before, and had one of the best quality releases the department has seen. In fact, we've been spending months trying to find things to do because time that was set aside for us to fix defects found in testing and the field has been idle, because they haven't been coming in.

We're not talking about minor changes either. 13 people, months of work each. The other feature that was in the release at the same time as us was smaller, and had fewer people, yet more defects, and took longer.

A process for the sake of process, well, isn't a good idea. One that is based on doing things that work, and changes with feedback, becomes a great thing to have.

Re:First Names... (2)

Coward, Anonymous (55185) | more than 12 years ago | (#487099)

Why is it that geeks feel the urge to call celebrity geeks by their first name only?

Because the geek's brain is capable of optimizing away the second part of the label when it is not necessary for proper human dereferencing.

Frank Lloyd Wright (5)

pos (59949) | more than 12 years ago | (#487104)

As somone who has quoted Wright in my sig for some time now (See the article dept.) I feel I should point something out.

Wright saw things as a whole object. He spent months thinking about the construction of Fallingwater and visiting the site. He drew the first concept draft in about 3 hours. (he actually called the client to come over and see what he had drawn before sitting down to draw it) It changed Very little from that initial drawing. Most experts at the time said the horizontal balconies would not stay floating out into space the way they do and would collapse. The workers were constantly changing the plans because they did not have faith in Wright's design. (Modern analysis now shows that these workers acually ended up weakening the structure)

As someone who has actually walked through fallingwater, I think one could easily say that the design is the most elegant, natural design you could possibly want.

To apply Wright's ideas to the concept of software engineering: I would say you either have to be very gifted in how your brain processes/sees information, data and functionality, or create a system that is whole and complete through lots of careful adjustments and evolution. The latter seems to be the common OSS approach however the former is the more respected/impressive way. :) I suppose one could argue that even Wright evolved his prarie style and his catilevered/fallingwater style over several hundered homes. I guess I can see some similarities between Wright, Torvalds, and Wall among others. (inspired design, excellent execution, and refinement over time)

I think the important lesson here would be that all of these people create something that stands as a whole unified concept that doesn't sprawl out where it doesn't belong and is fundamental enough to change the way other people see the world or problem space. They all thought about their designs A LOT! They are all artists and craftsmen.

Wright's work inspires me and fills me with awe, as does perl and the linux kernel. Does your software?


The truth is more important than the facts.

Unit testing isn't all it's cracked up to be (4)

soaper (63056) | more than 12 years ago | (#487108)

"The most powerful weapon in your toolbox is comprehensive unit testing"

It's this kind of thinking that causes too many of the problems you are trying to prevent.

According to _Programming Productivity_ by Capers Jones, unit testing, will only find 25% of the defects. At its best, unit testing finds 50% of the problems. Compare this to, for example, formal inspections, which find 60% of defects on average, 70% at best. Modeling and prototyping (build one to throw away) can find up to 80% of defects.

None of these methods will build a completely defect-free program, but by combining a number of them, you can get extremely close (99%).

Re:Most of us don't have this option... (2)

dolanh (64212) | more than 12 years ago | (#487109)

The reason a semi-natural-language interpreter hasn't been done (AFAIK) is probably due to the difficulty and varied results of natural language parsing w/regards to language meaning (see article on wearable translator).

It's a great idea, but natural language capabilities are to computer scientists what Pluto is to NASA -- you can see it there but it's still pretty much unattainable.

Re:Software Engineering will make software suck le (1)

captredballs (71364) | more than 12 years ago | (#487115)

The Evergreen State College in Washington state has a program called Student Originated Software that attempts to address this problem. It is a Software Engineering class (well, its a full year program) that draws students from comp.sci., liberal arts, and natural science backgrounds and puts them in a fairly realistic SE atmosphere. They must solicite for projects, then design and implement them. The focus is on cooperation, organization and design, not Comp.Sci. fundamentals.

TESC [evergreen.edu]

Re:uh, okay (1)

DebtAngel (83256) | more than 12 years ago | (#487117)

Yeah, I found the whole "XP Ad" thing silly. I mean, one of the reasons I hate most computer shows is that "reviews" are simply ads, with a common host for half an hour. Just like this "feature". I think a link and a paragraph here would have done quite nicely, thank you very much.

In other words, I agree with you.

Re:What about existing software? (1)

Pennywise (92193) | more than 12 years ago | (#487124)

I don't think "integrate it into the code" means changing the existing code to make the test suites. I think he means that if you have a large existing codebase (without test suites), it will take a huge amount of time/effort to write the test suites for it. This is a legitimate concern since you'll have to write test suites for your entire program before you can add any new code as the previous poster noted.

Re:What about existing software? (1)

Pennywise (92193) | more than 12 years ago | (#487125)

I assumed he meant "your new code isn't breaking something!". I'm not saying that building the test suites isn't a good idea ( in fact I'm trying to get my current company to go in that direction ), it's just the time it will take that is the main concern since we have a very large codebase.

That aside, just writing test suites for the functions you touched won't catch all the possible new broken code if the functions have any side-effects, so you've got to be very carful in what you don't write a test suite for initially. Baby steps are the most palatable way of doing it though :)

Re:Software Engineering will make software suck le (2)

molo (94384) | more than 12 years ago | (#487128)

The Rochester Institute of Technology (RIT [rit.edu]) has a Software Engineering program [rit.edu] that will graduate its first class this May. It is a spin-off of the CS department. (See also here [rit.edu])

Degree is not the main issue (1)

Tablizer (95088) | more than 12 years ago | (#487129)

The issue is incentives. If you don't reward somebody for doing behavior X, then most will simply stop doing behavior X.

The problem is that good software is expensive and time-consuming to write, but everybody wants a $99.95 box with all the trendy features.

The public is simply getting what they pay/ask for.

Design Patterns (2)

Broken ( Moon (102369) | more than 12 years ago | (#487137)

Most programs need to be carefully prototyped. VB is often critized for the over-simplification that it enforces, but it's a valuable tool for rapidly developing classes for testing and evaluation of the design.
Considering robust design takes more time initially, but once a solid model is decided on the implentation is relatively easy. I recommend the book "Design Patterns: Elements of Reusable Object-Oriented Software" as a great place for young developers to learn how to think about complex programs.

Software will never be perfect (1)

11thangel (103409) | more than 12 years ago | (#487138)

There will never be quote "perfect" software. As the title says, it can only suck less. Many features that some people love, other people hate, and some really important features can simply not coexist with other less important features. Someone will always be unhappy with a piece of software, which is why we have variety.

Re:OK I'll bite (1)

jamesbulman (103594) | more than 12 years ago | (#487139)

I see where your going with this, but any serious code will be tested by people other that the people who developed it. This approach of testers trying to catch developers out and developers trying to avoid being caught out, does lead to a total quality ethos, and utimately better software.

Root of all evil? (1)

chrysrobyn (106763) | more than 12 years ago | (#487143)

If the head admin for Microsoft ran *NIX, would (s)he be considered the root of all evil?

Re:Isn't this just common sense exemplified? (1)

Vanders (110092) | more than 12 years ago | (#487145)

Is it? If it was common sense, why is it that so little OSS software goes through any sort of structured testing phase?

Most testing of OSS seems to be:
  • Developer can compile & run code. Unit testing
  • Developer releases code as an "Alpha". Component testing
  • Fixes bugs, releases "Beta". System testing
  • Fixes bugs, releases final build. Testing over!
Sorry, that isn't a proper structured testing scheme. Beta & Alpha releases are no good other than for limited releases. If you don't know what uses your users are putting to software too, some features may never get tested until it is too late.

Developers seem to view testing as a neccesary evil, but are happy to release fix, after fix, after fix for eternity, rather than writing & following a test plan. Honestly people, it saves time in the long run!

Re:Software Engineering will make software suck le (1)

Relic of the Future (118669) | more than 12 years ago | (#487152)

Unfortunately, I'm not aware of any school which is teaching it to potential software engineers.

Carnegie-Mellon's Software Engineering Institute [cmu.edu]

While I was interning last year several top-level programmers were sent there for seminars. Granted, they all had been CS majors in college, and it wasn't a degree program, just a seminar, but CMUs undergrad CS courses are starting to incorporate some of the ideas from SEI.

God does not play dice with the universe. Albert Einstein

Cool Edit Doesn't Suck (1)

YIAAL (129110) | more than 12 years ago | (#487164)

In fact, it has the easiest-to-grok-instantly user interface of any program I've ever used. Sonic Foundry's Acid is almost as good. My theory: these programs have to be comprehensible to musicians, so they *have* to be easy to use...

1. Fire the managers 2. Design patterns (2)

code_rage (130128) | more than 12 years ago | (#487167)

  1. Fire the lickspittle program managers / marketroids who promise the world to the customer without having a clue on what is realistic. Listen to the engineers when they say "we're pushing too hard". Consider the end game -- we can get to a solid final release via lots of buggy "final" releases and chaos or by lots of interim releases which are not advertised as final, and which are easier to kick out the door than "final" releases.
  2. Send the entire team to an in-depth design patterns seminar. Even if you are not using OOD or DP, it will get people thinking about design, design artifacts (diagrams), and collaboration.

Yet another "improve software reliability" article (2)

dpilot (134227) | more than 12 years ago | (#487169)

and no mention of strong typing, Ada, or the like.

Not even an "Ada was a babe" thread.

Clearly, strong typing isn't everything. But neither is any other single component of software development. You need an arsenal of tools to do the job right, beginning with your brain, and you need to know how to use them.

But a weakly typed language takes a whole slew of potential errors and makes finding them a matter of human diligence, debugging, and auxiliary tools like lint.

Re:As long as non-coders are involved in coding... (1)

Crackos (137764) | more than 12 years ago | (#487170)

Non-Coders should talk place in the process, testing the product, working with it, helping to get it out, but they should stick to "easy" coding tasks: defining user interfaces and such things.

True and False.

Non-coders are really good at bashing an application till it breaks. Not having any idea whatsoever about how it works inside makes them try clicking and typing things that most geeks would overlook.

It takes a special cross-breed of geek and artist to design a good user interface. One has to know what the underlying code does, while also making the interface "feel right". Hardcore geeks typically make very functional but very unintuitive UIs. "If you don't find it user-friendly enough, then you're not a real user", or so they say. Just look at any UNIX-type shell for a fine example. ;^)

Re:As long as non-coders are involved in coding... (1)

Crackos (137764) | more than 12 years ago | (#487171)

They're M$FT geeks but they can produce a product.

As in they work for MICROS~1? If so then, they're with the only company in the world that actually gets decent tech support for MICROS~1 development environments. The rest of us have to search through the horrid "Knowledge Base" on the web and attempt in vain to contact techies via email. Try doing that some time. No wait; don't ever try that! Go to the comp.lang.* newsgroups. You'll get flamed by a bunch of elitist programmers who believe that all answers are contained in the FAQ, but it's much less frustrating than the MICROS~1 web page!

As long as non-coders are involved in coding... (4)

Crackos (137764) | more than 12 years ago | (#487172)

...software will continue to suck.

Most people in software development these days are clueless. Having a university degree, college diploma and/or MCSE does not make one any better at coding, from what I've seen. Programming is something that requires both inate talent and experience.

Second, making development environments supposedly more accessible and "fun", while stripping away useful language constructs because they are "too complicated for the average programmer", only makes for sub-par software. Try making a 30-screen database app in Visual Basic. Actually no; don't ever try that. Just beleive me when I say that it's damn near impossible to produce a good product that way!

Finally, most new programmers are thrown into difficult tasks without much background knowledge at all, and very little if any mentorship. Still they're expected to produce exemplary results. Sure it's fun to be "challenged", but that's not the way to have a good end result.

What's important is allowing people to gradually gain experience in programming, to guide them along the way, to show them how to improve their skills, and to give them the proper tools to get the job done. This is how it's done in every industry, except for that of software.

First Names... (4)

Electric Angst (138229) | more than 12 years ago | (#487174)

Okay, I just noticed this sentance...

Most of us aren't gifted with the organizational clarity of a Linus, or the brilliant non-orthogonal design of a Larry.

Why is it that geeks feel the urge to call celebrity geeks by their first name only? You sound like thirteen year old girls reading Tiger Beat magazine!


Re:Software Engineering will make software suck le (1)

hardburn (141468) | more than 12 years ago | (#487176)

No one would hire an architect or mechanical engineer who didn't have at least a piece of paper from a college.

Architecture and mechanical engineers have had centuries to develop well-thought-out standerds for doing things. Computer Science has had about 30 years.

Do you really think Microsoft actualy hires people that haven't gotten that scrap of paper? They have plenty of money to do so (yes, BillG never did graduate, but thats just BillG). They have no reason to hire anyone else. Yet, their software sucks.

And just what do CS majors learn? I've taken a High School CS course for AP and I'm not sure how I came out of it not hateing programing. For instance, when it came time to learn about linked lists, the book talked about what a linked list was. Then, it talked about what a linked list was. Then, it talked about what a linked list was. It never really said how to code the blasted thing. Not surprisingly, everyone failed the linked list test.

I don't hold out much hope on college, being that AP courses are designed to place you at or above the level of a college-level course.


Not a programmer, but.... (1)

woody_jay (149371) | more than 12 years ago | (#487188)

I am not a programmer, so I don't pretend to know that much about coding. I do know this much, as the need for software that can intigrate with more, and also be tailored to specific need rises, the complexity of writing such software also rises. We are only human and will always make mistakes. What makes us different, is that we can learn from them. It's going to get better.

Re:As long as non-coders are involved in coding... (1)

thetoad911 (152458) | more than 12 years ago | (#487189)

I attended SAIT in Calgary, AB Canada. I have taken an Human Computer Interaction (HCI) class. Most people thought this class was stupid and common sense, but really it isn't. There is a lot of very useful concepts that get racked/driven/forced into your head, but when I program now and write code, I don't break the rules. I know it confuses end-users and frustrates the hell out on them. If users get frustrated with my software, they will not use my software, thereby I don't make money. $$$$ :)

can you say HCI (2)

thetoad911 (152458) | more than 12 years ago | (#487190)

Software programmers spend too much time learning code and not enough time learning Human Computer Interaction concepts. I want to code all the time myself, but when that happens I revert to planning as I try to think of the user. They are the ones that must suffer with the system.

The system makes complete sense to you, because you have developed it and understand the logical model. Developers must make it easy for the user to develop their own logical model of the system and give the user "locus of control"; which means they believe they are in control! Ya trick 'em, it is so easy to do.

XP site (1)

GutterBunny (153341) | more than 12 years ago | (#487191)

Here's a site that I didn't see mentioned. It goes further into the XP realm and has a lot of good links.

XP [xprogramming.com]

A tip.. (3)

PopeAlien (164869) | more than 12 years ago | (#487195)

everytime someone has a *great new idea* for a feature (Animated dog with sunglasses to help people with the process of pasting 3gig mpg's into their word document) look at them blankly and say ..'what?'..

Here in Canada, it is your right to have things told to you in French.. This is usefull if you don't understand french. Repeat until they give up.

Re:Software Engineering will make software suck le (1)

schulzdogg (165637) | more than 12 years ago | (#487196)

I've taken a High School CS course for AP and I'm not sure how I came out of it not hateing programing. For instance, when it came time to learn about linked lists, the book talked about what a linked list was. Then, it talked about what a linked list was. Then, it talked about what a linked list was. It never really said how to code the blasted thing. Not surprisingly, everyone failed the linked list test.

You took a high school class and from their you can extrapolate out the entire scope and range of all CS curriculum in world?

It's this kind of self delusional intellectual wanking that makes open source look so bad. Some manager somewhere read that and thought: "These linux kids a fucking morons". Now when I try to convince people that linux/apache/perl is the way to go the ghost of every halfwit moron post like that stands arrayed against me...

As a community, can we try to look at things when we say them and think about it and not be total tools?

The part about being told what a linked list is but not how to code it is icing on the cake.

Re:Software Engineering will make software suck le (1)

sqlrob (173498) | more than 12 years ago | (#487200)

And just what do CS majors learn? I've taken a High School CS course for AP and I'm not sure how I came out of it not hateing programing. For instance, when it came time to learn about linked lists, the book talked about what a linked list was. Then, it talked about what a linked list was. Then, it talked about what a linked list was. It never really said how to code the blasted thing. Not surprisingly, everyone failed the linked list test.

And they'd fail in reality. Think about it. For a project you are given requirements, not how to code it.

Re:The easiest way to make software suck less (1)

sqlrob (173498) | more than 12 years ago | (#487201)

They don't even have to be vauge (well, I don't consider this vague):
The program does what it is claimed to do.

OK I'll bite (1)

sjbe (173966) | more than 12 years ago | (#487206)

OK, you write tests for everything first. Fine, sounds reasonable. (ignoring for a moment the usual absurd time constraints) Except for, umm... well exactly how do you ensure that your tests aren't broken? Seems a bit of a catch-22...

If your tests aren't telling you what you think they are, then doesn't the whole idea of test first sort of fall into a big gaping hole in the ground?

Not meant to be a troll, just curious.

Re:1. Fire the managers 2. Design patterns (1)

enrico_suave (179651) | more than 12 years ago | (#487211)

You probably should keep the program/project managers and get 3. business/product analyst to buffer between the technical resources (what can be done) and the end business client (wants the moon...)

As great as doing everything yourself is... would you rather be coding/designing patterns, or sitting in boring meetings deciding on radio button vs. check box with the marketingdroids ?

just a thought...


www.randomdrivel.com [randomdrivel.com] -- All that is NOT fit to link to

Is testing code some sort of new idea? (1)

Pandion (179894) | more than 12 years ago | (#487214)

What makes this XP stuff so good? It cant possibly be the first technique to advocate rigorous testing. Or is it? That would be really scary...

Re:Software Engineering will make software suck le (1)

ThomK (194273) | more than 12 years ago | (#487223)

I'd like to see that study, where is it?

The right tool for the job (3)

Deanasc (201050) | more than 12 years ago | (#487228)

I'd rather have my software programmed by someone who's actually faced my problem in the real world. You can have your CS degree (or Software Engineering degree) but if you're going to write programs that calculate the electron cloud around a complex ion you need to know chemistry, physics and calculus. Trouble is few people know how to do this sort of thing well and write code. Most of the programs I've seen were written by non-CS majors who needed the program badly enough to write it themselves. They're quick and dirty with only one way to do things in the interface but they work and usually don't crash taking out the OS with them.

The real issue here is bells and whistles that are not central to the programs function. It's nice that Word can mailmerge an address list from an Outlook or Excel file but since I'm not in the mass mailing business I really don't need the feature. It's there and there's nothing I can do to get rid of it. It should be a plug-in for those who need it. (Professors where I go demand all reports emailed as a Word attachment so not using Word is not an option yet.)

Any one can make shelter. It's a primal instinct that man has. Some thick branches, leaves and mud and you have a house. All you really need an Architect for is to make bigger fancier more expensive houses with features that don't always work properly. Like fire alarms that go off when you use the oven. Like hidden water pipes that sweat condensation which drips into a hidden electric box shorting out the current and burning down the house.

Now a good Architect knows how to avoid these kind of problems but sometimes a builder just buys house plans and lets the plumbing contractor rough in the plumbing and the electrical contractor rough in the wires and hopes they don't burn anything down when the software is shipped. (oops I mixed my metaphor.)

So really what I'm saying is too many cooks and not enough guidance from the top is what spoils software. Marketing can't give a manager a list of contradicting or confusing features and expect a committee to crunch out the code in time for the ship date. That is how houses burn down. But it wasn't our fault the fault lies with the pipe vendor who didn't make the pipes out of anti-sweat copper. However if you go to our website we have a patch for your security system so that the fire alarm doesn't go off when you turn on the stove.

Re:What about existing software? (1)

JWhitlock (201845) | more than 12 years ago | (#487229)

Correct - ideally, I would want to not touch existing code, but instead treat exisiting code as units, calling functions from test routinues, setting up test builds, etc.

However, I failed to mention that the code in question is in procedural Fortran (a dialect of Fortran 77), without data structures, and destined for a real-time environment. Most function interaction is through global variables (a datapool), and the code is somewhat tweaked for real-time.

None of the existing test are really computer based. They all require human interaction (story-based tests, comparing plots, watching for lights). It would be a significant effort to determine interfaces (all global variables look alike), and to even determine what the units are.

Unit testing would be nice, but it isn't really object-oriented code. It would take some real trickery to make it look object-oriented enough to use unit-testing, and, once you have made those changes, then how do you know you are testing the same things? For this type of code, it is a real possibility that the test functions would cause significant changes to existing code, or there would be code forks between existing code and test code.

It's also not possible to move to better languages. We have scripts, we have Fortran, and we have assembly - that's it.

It may not be as bad as other maintainance projects, but there is a significant amount of non-OOP code out there, and I'm not sure unit-testing will map well on all of it.

What about existing software? (3)

JWhitlock (201845) | more than 12 years ago | (#487231)

This plan of action (make test function, make code, verify code, repeat) seems to work well for brand new software. It answers the question, "Where do I start", with a great answer: start with something you can test. Sounds very much like the scientific method, and seems to work in the real world.

But, what do you do when you have an existing piece of software? Most software is maintained, not created. If a system is already using unit testing, then you can be assured that your changes and additions do not break preexisting code. But if there is no unit testing, then there needs to be an extreme effort to integrate it into the code. This isn't productive - you are adding no new features, and, until you have completed the test suite, you aren't sure that your test code isn't breaking something!

You can argue about future productivity gains, but sometimes those that give the money don't care about future gains. In my business, we make local changes to large systems (modifications to aircraft simulators). The existing self-test functions are inadequate, but we aren't being paid to make the whole system better, just to add our part. There isn't even assurance that we will do future work, so it is possible that our testing features will assist a competitor!

Interesting idea, I'll use it on my pet projects, but I'll need to see a proven path for existing systems before I go to my boss and ask for a procedure change.

Re:Software Engineering will make software suck le (1)

ScuzzMonkey (208981) | more than 12 years ago | (#487235)

The practical physics involved in architecture or mechanical engineering doesn't change radically in four years. I don't think mechanical engineering is a good comparison to software engineering. Even calling it engineering somehow implies a more rigorous set of guidelines than programming actually has. I like the architecture comparison better--there's a little bit of art to it, not just the strict mechanics of gravity and materials. And in that light, I would ask, when's the last time you ran into an architect who didn't have to put in years of apprenticeship scut-work before getting to work on the big, cool projects? They may get the degree at a college, but they get the experience in the real world. Same thing with programmers. Most of the real knowledge and best practices are acquired outside the classroom. Unschooled does not mean untrained.

That said, I agree that a little more discipline would not hurt most programmers. But I think XP is a good step in that direction.

Re:Software Engineering will make software suck le (3)

Riplakish (213391) | more than 12 years ago | (#487237)

Please do not confuse the acquisition of a piece of paper from a certified educator with compentency.

The percentage of less than compentent people without college degrees is probably the same as ones who have them. I personally know of a small village of people who attended college and basically skated to graduation with a decent GPA just by glomming all the answers from friends, boy/girl friends, family, etc. I also know of an equal amount of people that learned their craft by OJT, research, and dedication to knowing everything necessary in order to the the job right.

There are many reasons why someone can be skilled at a job, in this case Software Engineering, and not need a sheepskin in order to do the job right.

Its not the process, stupid... (1)

cscalfani (222387) | more than 12 years ago | (#487242)

The problem with software development is that people who don't know what they are doing are controlling it.

If management knew what they were doing then...

They wouldn't hire programmers who don't know what they are doing.
They wouldn't just go through the motions of following the process-of-the-week just to say that they have a process.
They would tailor a process to work for their organization by picking and choosing intelligently aspects from many software development processes.
They wouldn't hire overpriced consultants (who have supposedly read books on software development processes) to tell them what process to pick.
They would hire architects to design systems before letting coders start their work.
They would hire QA professionals who understand testing terms like unit testing, black-box testing, white-box testing, code coverage, regression testing, etc.
They would read books on software development processes.
They would read books on software management.
They would read books on software.
They would read books.
They would be able to read.

Design Metrics (1)

berb (231742) | more than 12 years ago | (#487251)

Having just written a paper about the future of Open Source Development as an enterprise solution I want to point out what I think is the major problem in OSD. Unlike developemnt in the Microsoft world (...Sun world) OSD lacks a codified base of design metrics akin to COM, DCOM or CORBA. The ANSI ruleset connot be used as a design metric, it was never intended to.
Until we all can write it all down and get together in agreement on some simple (or not so simple) rules I think we will always get crappy code. The current development of the OSDN is a step in the right direction.

The easiest way to make software suck less (2)

arfy (236686) | more than 12 years ago | (#487255)

The easiest way to make software suck less is to force software companies to provide a real, truthful legal warranty for it when it is sold.

Software would cost more initially but less in the long run since the purchaser would not have to pay as much for after-sale support simply to get the software to perform as it is advertised or written in the manual.

Most of us don't have this option... (4)

Bonker (243350) | more than 12 years ago | (#487257)

For those of us who code, develop, (or even make graphics) in the workplace, we often do not have the luxury of making our work not suck. The reasons are threefold:

1.) Time. This is caused almost totally by sales and marketing pressure on developlers. As release cycles shorten and deadlines loom, the questions developers ask of themselves stop being 'is it good?' and 'is it usable' and change to 'will it compile with no errors?'

2.) Management. This speaks for itself. When your boss demands that you create a crappy product and you do what you're asked, you have made a crappy product. This is a pretty painful burden to bear in the webdesign world. I once had to design a site for a gas grill company according to the owner's rather dubious tastes. It's pretty horrid: http://www.tiernanoutdoorproducts.com/ [tiernanout...oducts.com]

3.)Imitation. This almost belongs in the paragraph above, but when products become successful, there is a drive to imitate them. Take Winamp for example. What audio programs do *not* offer skinning now? Unfortuneately, this can be taken the wrong way. Look at the whole WIMP movment in GUI's. While it's nice to have a graphical interface, *everyone* spends time on the graphics and leaves out really useful features like a semi-natural language interperater. How nice would it be to type "Copy all jpgs with 'sitename' in the filename to 'sitename' directory" rather than a more arcane command or without having to worry about command typos? For the beginner, this would almost completely eliminate the learning curve to using a PC. Nobody spends time on this because there all still busy imitating MacOS.

Re:Software Engineering will make software suck le (1)

TechnoWeenie (250857) | more than 12 years ago | (#487260)

Of course the difference between architecture or civil engineer and a software engineer is that the laws of physics don't change every couple of years. 90% of what a civil engineer learned 20 years ago is still valid. 90% of what a software engineer learned would be irrelevant (what internet?).

Since a software engineer has to re-learn his craft at a much faster rate then the other examples, the relative value of a degree some years in the past is much less.

This same problem faces universities trying to create a software engineering school that is teaching to an ever moving target.

Re:Programming languages and code should be natura (1)

Phredward (254393) | more than 12 years ago | (#487263)

I think computer languages should conform to a higher ideal, and that ideal should be "doesn't make buggy software." Now, I like C as much as the next guy, but the fact of the matter is, it's a pretty lo-level language. While I have absolutely no evidence to back this up, it seems like a higher level, more modular programming language would be more condusive to making large software. Not as good for making high-speed pointer heavy code? Maybe. But if you're writing a word-processor (read: huge suite of non-speed critical apps) who cares?


Software will still suck.. (1)

cmowire (254489) | more than 12 years ago | (#487264)

Guys, we've known for a LONG time that there are a set of things that need to be done in order to make stable software. None of that is anything new.

So the problem is not that we don't know what to do. It's either that it's not sticking in people's heads or that there are outside forces that are preventing this.

In the case of your average software developer, both of these are happening. Good programming practice gets put on the back burner because they *need* to ship.

Incomplete attribution (2)

geomcbay (263540) | more than 12 years ago | (#487270)

While this is a bit of a nit, the Michael Abrash quote is a paraphrasing of a Donald Knuth quote ("Premature optimization is the root of all evil.").

Issue (4)

geomcbay (263540) | more than 12 years ago | (#487271)

One issue that this article doesn't bring up, and that many software engineering books ignore, is that sometimes all of the processes in the world won't help your software be more stable because of reliance on other software.

What I mean by this is, outside of embedded programming of small devices and game console programming, nobody writes programs 100% from scratch anymore (and even in embedded systems and consoles this is changing as they add standard OSes and libraries and JVMs to support the programmer).

So, not only do you have to worry about YOUR code not sucking, but you have to rely on all the DLLs or .so shared libraries you use not sucking, the underlying OS not sucking (sure, Microsoft has been the biggest name guilty of this in the past, but every OS has its share of kernel bugs, including Linux and *BSD), the JVM not sucking (heh heh, good luck on that one) if using Java, the C++ compiler you use not sucking and adhering to the standard, etc.

This problem actually seems to only be getting worse as the world moves increasingly towards net-based software. Anyone who has written Java for the client (either applet or full blown application) can tell you that write once, run anywhere is a joke because each different JVM has its own set of annoying and incompatible bugs..Likewise even simple scripting tends to be incompatible between different versions of the same browser (Netscape and IE both guilty) let alone different vendor's browsers.

Unfortunately there's so much suckage that is ingrained into current systems (and no, its not confined to Microsoft platforms, don't kid yourself) that some amount of suckiness is unavoidable no matter how careful you are.

XP (2)

des09 (263929) | more than 12 years ago | (#487273)

I have been working on an XP project for the last few months, and I have some words of free advice to anyone who reads up on xp and believes it to be a magic bullet...
  • There are no magic bullets.
  • XP works best with smaller teams, up to about 10 developers.
  • everyone on the project, clients, anal_ists, management, developers has to buy into XP to make it work.
  • Unit tests are vital

Re:Root of all evil? (1)

markmoss (301064) | more than 12 years ago | (#487279)

I long ago concluded that MS programmers must use *nix, if they had to use DOS or Windows they would have done a better job!

Sigh, yet another fad to kowtow to (1)

jack_doe (305833) | more than 12 years ago | (#487287)

Most of the named techniques make sense in context, but their grouping under a single name encourages cultish thinking and counterproductive politics - things which will at best delay and at worst sink your project.

Sanction lazy reasoning like "unit testing is good because it's part of Extreme Programming" instead of "unit testing is good because it quickly reduces defects" at your company's peril.

The promotion of jargon like "stories" adds to the confusion. (The previous "use cases" is not only conventional but also compatible with normal English.)

Finally, some people like to divert the focus from their and the group's actual productivity by talking about "mindset." In my experience, such people are usually obstacles to getting anything done. We have one of these clowns at my current company - he's barely done a useful thing in the last eight months, but he's sure talked a lot about mindsets (not XP, but other preferences) and absorbed a bunch of our unwilling time.

To be clear: I take issue, not with any of these ideas (which are in fact useful), but with their assembly into a sacred cow with private language and a Capitalized Name.

Re:Programming languages and code should be natura (1)

Bobo_The_Boinger (306158) | more than 12 years ago | (#487291)


I'm not sure how you can say any of this. How is English, with it's complex myriad meanings that make it so difficult to learn, better than Esperanto, or Loglan for that matter? Just because it has become a de-facto standard in no way means it actually is better. Or would you argue that Microsoft must be the god of all software packages since it is used so extensively?

As for your statement, "as long as everyone writes stuff that they personally can read", that would create a lot of potentially useless code. Imagine that someone write a wonderful word processor, everyone loves it and begins to use it. Then imagine that the writer of the software dies and suddenly everyone notices that the author wrote the software using his own proprietary language. Now, either everyone can spend (waste really) months learning his new language to update the software, learn to live with the current version for the rest of their lives, or write a new wordprocessor from scratch. Imagine how much time could have possibly been saved if the original author had instead invested some time to write easily understandable, well documented, managable code. Everyone would benefit.

Programming languages and code should be natural (2)

Urban Existentialist (307726) | more than 12 years ago | (#487293)

The idea that computer languages and code should confirm to some higher ideal has been with us too long. What counts is what works best in the real world, airy principles aside.

Chaotic, naturally evolved languages work best - like the english language compared to esperanto. When it come to code, as long as everyone writes stuff that they personally can read (and if they have half a clue they will) then its no big deal if it doesn't confirm to your old CS professors unfounded ideals. Let GOTO's stalk the land!

Principles in these matters are just invented artifacts.

You know exactly what to do-
Your kiss, your fingers on my thigh-

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account