Linked by Thom Holwerda on Mon 17th Oct 2005 20:27 UTC
Features, Office "No one makes bad software on purpose. No benevolent programmer has ever sat down, planning out weeks of work, with the intention of frustrating people and making them cry. Bad software, or bad anything, happens because making things is hard, making good things doubly so."
Order by: Score:
BS.
by Anonymous on Mon 17th Oct 2005 20:36 UTC
Anonymous
Member since:
---

Lazy programmers write bad code.
- If's require elses.
- Error handling needs to be designed and written.
- Short cut programmers write bad code.

Reply Score: 0

RE: BS.
by bryanv on Mon 17th Oct 2005 21:46 UTC in reply to "BS."
bryanv Member since:
2005-08-26

You mean ctrl-c and ctrl-v aren't citizens of "Good Design"?

Heretic!


(I totally agree. I see someone use copy/paste while coding and my immediate reaction is a strong desire to club them over the head.)

Reply Score: 1

RE: BS.
by Anonymous on Mon 17th Oct 2005 22:34 UTC in reply to "BS."
Anonymous Member since:
---

No one who uses your code cares, at all, how many dnagling if's you have or how brilliant your error handling is or how many shortcuts you took. They don't care if you wrote bad code or good code. They only care if they like your product. Nothng of what you've mentioned has naything to do with how people react to your product.

Reply Score: 0

RE[2]: BS.
by Sphinx on Tue 18th Oct 2005 14:02 UTC in reply to "RE: BS."
Sphinx Member since:
2005-07-09

I'm sorry but reality is that is exactly why your customers will be suing you, what you're writing is shelfware. The three most, nay the only things that matter in software are performance, performance and performance. You don't get it by doing a crappy job on the code. How your product is written is how it performs is how people react to your product. It's all connected in the grand cycle of development.

Reply Score: 1

RE[3]: BS.
by dagw on Tue 18th Oct 2005 14:57 UTC in reply to "RE[2]: BS."
dagw Member since:
2005-07-06

Performance is far from everything. Things like useability and features are far more important in many programs. If a program is a pain to use and doesn't have the features I need at the quality I expect I don't care how fast it is. You can have the most beautiful code in the world and still produce a program no one will want to use.

Reply Score: 1

RE[4]: BS.
by Sphinx on Tue 18th Oct 2005 16:25 UTC in reply to "RE[3]: BS."
Sphinx Member since:
2005-07-09

You are describing an application user interface of poor performance, all facets of the application must perform equally well, I stand by the rule.

Reply Score: 1

RE: BS.
by Anonymous on Tue 18th Oct 2005 00:31 UTC in reply to "BS."
Anonymous Member since:
---

Not just lazy programmers. Egotistical programmers who can't admit they lack the mental ability to formulate good code on the fly. These are the people who will go off about how important logic and mathemtics are, but when asked to complete a complex task they fall sort.

Reply Score: 1

RE[2]: BS.
by Anonymous on Tue 18th Oct 2005 05:01 UTC in reply to "BS."
Anonymous Member since:
---

Lazy programmers write bad code.

wrong. bad programmers write bad code. lazy programmers will write code which is difficult to maintain, but often does borderline miracules things. the woz would be a great example.

- If's require elses.

wrong. ifs need elses only when they fit the logic of what you are trying to do. sometimes they need else ifs. sometimes they dont. if you believe every if needs an else, you are probably one of those coders who write bad code.

- Error handling needs to be designed and written.

partially wrong. virtually every modern language has a built in way to do error handling. rolling your own is redundant, and more prone to errors itself, therefor is a Bad Thing. you are only right if you are referring to older stuff.

- Short cut programmers write bad code.

this is a reiteration of your first point, and just as wrong. hackers could fall under "shortcut programmers", and hackers are the only ones who innovate in the industry. they treat code as a language rather then a formula. sometimes it takes work to understand, but more often then not their code is insanely better then what i usually refer to as "drones", who do everything the long way.

Reply Score: 0

RE[3]: BS.
by japail on Tue 18th Oct 2005 06:18 UTC in reply to "RE[2]: BS."
japail Member since:
2005-06-30

> the woz would be a great example

It would be difficult to characterize Wozniak as lazy. Between the two of you, you both manage to define who writes bad code baselessly and then disagree with each other about whose axioms are more worthless.

> partially wrong. virtually every modern language has
> a built in way to do error handling.

If you think having exceptions negates the need to design for the handling of errors, then I seriously doubt your development experience. Whatever means you have of dealing with erroneous behavior (return codes, continuations, flying zebras) you need to design around dealing with exceptional conditions. Where will conditions be propogated to? How will they be handled? What should really be done when you can't secure a limited resource like memory or a graphics context?

If your idea of error handling is letting an exception just terminate your program, then your software is probably crap.

> hackers could fall under "shortcut programmers", and
> hackers are the only ones who innovate in the
> industry.

Paul Graham called and said that he wanted his self-delusion back.

Reply Score: 1

RE[4]: BS.
by Anonymous on Tue 18th Oct 2005 14:43 UTC in reply to "RE[3]: BS."
Anonymous Member since:
---


It would be difficult to characterize Wozniak as lazy. Between the two of you, you both manage to define who writes bad code baselessly and then disagree with each other about whose axioms are more worthless.


if he doesnt now, that was the reason he alwas gave for designing boards with very few chips, because sodering was a pain and he was lazy.

If your idea of error handling is letting an exception just terminate your program, then your software is probably crap.

there is a far cry between not catching exceptions, and designing and writing error handling. its already designed and written in most modern languages, all you need to do is use it.

Paul Graham called and said that he wanted his self-delusion back.

Paul Graham was one of the spearheads of the .com boom. Paul Graham was the guy who came up with the idea of using bayesian filtering for spam, which is pretty much the only thing that has remotely worked so far. Paul Graham is one of the innovators I was talking about.

Reply Score: 0

RE: BS.
by Anonymous on Tue 18th Oct 2005 08:24 UTC in reply to "BS."
Anonymous Member since:
---

"Lazy programmers write bad code."

Then they're not lazy enough. Really lazy programmers realize that bad code generates lots of headaches over a long period of time and tries to avoid that. :-)

I agree with the rest.

Reply Score: 0

RE: BS.
by martinus on Tue 18th Oct 2005 09:27 UTC in reply to "BS."
martinus Member since:
2005-07-06

Lazy programmers write bad code.
That's wrong. Lazy programmers write:
* Simpler code, which therefore is more easily maintained
* Do not like complexity because they don't want to think, which keeps things simple
* follow the DRY (don't repeat yourself) principle, to keep things simple

Oh, and did I mention that simplicity is usually the most important aspect of software?

Reply Score: 1

RE[2]: BS.
by Anonymous on Tue 18th Oct 2005 14:29 UTC in reply to "RE: BS."
Anonymous Member since:
---

Lazy programmers write bad code.
That's wrong. Lazy programmers write:
* Simpler code, which therefore is more easily maintained
* Do not like complexity because they don't want to think, which keeps things simple
* follow the DRY (don't repeat yourself) principle, to keep things simple

Oh, and did I mention that simplicity is usually the most important aspect of software?


There's NO SUCH THING as SIMPLE software.
Only the TRUE path thru the code is simple.
The real work is in the ELSE CONDITIONS and the error handling. This is where the bad programmers fall down on their ass.

To simplify: If you've never coded an Exception in C# you should reconsider that management job at Denny's.

Reply Score: 0

RE[3]: BS.
by Anonymous on Tue 18th Oct 2005 14:48 UTC in reply to "RE[2]: BS."
Anonymous Member since:
---

print "Hello, World.";

Reply Score: 0

RE: BS.
by Sphinx on Tue 18th Oct 2005 14:08 UTC in reply to "BS."
Sphinx Member since:
2005-07-09

I'd add.
- a value returned is a value checked.
- great programming requires great discipline.
- there are no short cuts but a proper design will almost code itself.

Reply Score: 1

Normal people don't understand that...
by Eugenia on Mon 17th Oct 2005 20:50 UTC
Eugenia
Member since:
2005-06-28

Good code is EXPENSIVE as it's DIFFICULT to write.
And as long as good code is so expensive, don't expect commercial/home-oriented software to ever be "good". This is true for both OSS and commercial software. If you really need perfect quality, I suggest you ask NASA and nuclear plants to give you some references of software houses that might will fix things for you, given a few million dollars. More here: http://www.livejournal.com/users/jbq/91727.html

Reply Score: 5

dylansmrjones Member since:
2005-10-02

Now now, Eugenia ;)

This wasn't what was meant with good code.

Reply Score: 1

corentin Member since:
2005-08-08

> Good code is EXPENSIVE as it's DIFFICULT to write.

Bad code is way more expensive and difficult if you have to maintain or reuse it.

Reply Score: 3

Anonymous Member since:
---

> Bad code is way more expensive and difficult if you have to maintain or reuse it.

Good code costs you money/time/resources at the time it is originally created: bad code may appear to be cheap at the beginning, but it's much like a plague that starts out small, and the resources required to fix the problems as a result end up being much more than the cost of doing it properly the first time, and keeps on giving in that way.

If your product(s) start out notably bad, but are otherwise on time to market, your reputation is likely to be blown to hell, such that the seemingly low-cost of the initial implementation ends up being no bargain, because you may never be able to convince people after that that the product(s) in question are worth spending their time and money on in the future, while some other solution that may have taken longer initially to get to market can come in and swoop up potential customers.

The cliche of you never get a second chance to make a first impression applies too often.

Reply Score: 1

Tuishimi Member since:
2005-07-06

I agree. See my longer comments above.

Reply Score: 1

Sphinx Member since:
2005-07-09

Bah! bad code is expensive, lawsuits, lost customers,poor reputation, bankruptcy, dreams crushed.
It's real easy to do good code right if you've got the skill, discipline and focus. If it's too difficult then maybe a career change should be considered before too much damage is done. Project management may be a better fit. Not everybody has what it takes to be a programmer no matter what the latest fad language groupies decree.

Reply Score: 1

There Are Exceptions
by Anonymous on Mon 17th Oct 2005 20:59 UTC
Anonymous
Member since:
---

The article suggests up front that sucking software is the result of low skill on the part of programmers and designers. Computer software is a weird market, and it breeds major violations of this idea. I can think of three major types, two perpetrated or caused mainly by Microsoft.

One is that software that annoys and bedevils the user is created in order to sell upgrades later, or to segment the market by selling a low-quality version of the same software. Examples of this include every version of Windows. "This version is REALLY secure! REALLY!"

The second example is that, since Microsoft is directly or indirectly competing with just about every programmer on the planet, they inflict constant sorrows on us to keep us busy. Read "Fire and Motion" by Joel Spolsky for the general principle. Does anyone really believe that Microsoft just couldn't fix IE6 for five years?

A third cause, unrelated to Microsoft, is that PHB types decide they need to Step In And Decide Something, and their decision sucks. Again, I suggest reading "Two Worlds" by Joel. This happens all the time. Whenever you're using a piece of otherwise great software, and you run into some feature of the software that makes you scream "WHAT THE HELL, WHY WHY WHY" that's probably the result of a bungling manager. It really happens. I've seen it.

Reply Score: 3

RE: There Are Exceptions
by Sphinx on Tue 18th Oct 2005 14:21 UTC in reply to "There Are Exceptions"
Sphinx Member since:
2005-07-09

Marketing kicking stuff out the door way too soon has to be the lead cause, very insightful of you to point that out. Not too many bad programmers last long enough on the job to do any where near the damage of bad marketing.

Reply Score: 1

No
by Vonskippy on Mon 17th Oct 2005 21:02 UTC
Vonskippy
Member since:
2005-07-10

Good Code takes programmers that care. To many coders think that anything they develop should be fawned over by the masses. How many times have you heard "if you don't like it - learn to program and do it yourself". No other industry puts up with such bullshit ego attitude. Dentists, Farmers, Airline pilots, and thousands of other professions all have skills that programmers don't - yet do they tell everyone to "learn how to do it themselves"?. If you're going to do something, do it well, or not at all. That's a truism no matter what the task.

Reply Score: 5

What does it mean?
by Anonymous on Mon 17th Oct 2005 21:02 UTC
Anonymous
Member since:
---

"Benevolent"? Malevolent?

Reply Score: 0

RE: What does it mean?
by Anonymous on Mon 17th Oct 2005 22:02 UTC in reply to "What does it mean?"
Anonymous Member since:
---

From Google's 'define [term]' searches:

Definitions of benevolent on the Web:

intending or showing kindness; "a benevolent society"
charitable: showing or motivated by sympathy and understanding and generosity; "was charitable in his opinions of others"; "kindly criticism"; "a kindly act"; "sympathetic words"; "a large-hearted mentor"
generous in providing aid to others
beneficent: generous in assistance to the poor; "a benevolent contributor"; "eleemosynary relief"; "philanthropic contributions"
wordnet.princeton.edu/perl/webwn
the performance index of social man; the capacity to obtain happiness through the happiness of others vs egoistic happiness obtained at the expense of others by sociopaths.
www.corebooksweb.com/definitions.htm

Definitions of malevolent on the Web:

wishing or appearing to wish evil to others; arising from intense ill will or hatred; "a gossipy malevolent old woman"; "failure made him malevolent toward those who were successful"
malefic: having or exerting a malignant influence; "malevolent stars"; "a malefic force"
wordnet.princeton.edu/perl/webwn
A malevolent spirit is one that wishes to do harm.
laurelparanromal.tripod.com/id13.html

On another note: the reply preview doesn't work in Konqueror

Reply Score: 0

RE: What does it mean?
by Anonymous on Tue 18th Oct 2005 07:13 UTC in reply to "What does it mean?"
Anonymous Member since:
---

Without looking up definitions, I would say:

Benevolent = kindly, giving

Malevolent = Evil, cruel

Reply Score: 0

Good code...
by dylansmrjones on Mon 17th Oct 2005 21:04 UTC
dylansmrjones
Member since:
2005-10-02

...is easy to write, when you remember the rules.

Always remember to have a running dialogue with your customers.

When you don't you'll end up with a screwed up system like the one, the danish police got. Completely unusable and a good laugh in the rest of the industry.

This article is GOLD.

Reply Score: 2

RE: Good code...
by dylansmrjones on Mon 17th Oct 2005 22:43 UTC in reply to "Good code..."
dylansmrjones Member since:
2005-10-02

Woot... how did that post get modded down?

Unless somebody has a thing against me?

Reply Score: 1

RE[2]: Good code...
by DittoBox on Tue 18th Oct 2005 01:18 UTC in reply to "RE: Good code..."
DittoBox Member since:
2005-07-08

I modded you back up, since folks obviously don't read the "are you sure you want to mod that post down" info.

NOTE: This feature is to report comments that are offensive, inflammatory, off topic, or otherwise in violation of the OSNews forum rules detailed on this page.

Please do not use this feature to vote down comments that you merely disagree with, or even ones that contain factual errors or misinformation. Rather, use the reply feature and enlighten us all with your opinion or correct facts


Please read the rules people.

Reply Score: 2

RE: Good code...
by Sphinx on Tue 18th Oct 2005 14:25 UTC in reply to "Good code..."
Sphinx Member since:
2005-07-09

The clear specification, you have got to work from a clear spec. Can't hit it if you don't know what the target is. Not too many programmers are very good at reading the customers mind. Clairvoyance while a desirable trait is rarely seen on a resume.

Reply Score: 1

Oh?
by Anonymous on Mon 17th Oct 2005 21:05 UTC
Anonymous
Member since:
---

I would contend that people have written bad code on purpose.

Have a look at this if you don't believe me: http://perversiontracker.com/archives/000438.html

I would draw, perhaps selfishly, attention to: http://ghostlords.com/mole/

Reply Score: 0

RE: Oh?
by dylansmrjones on Mon 17th Oct 2005 21:39 UTC in reply to "Oh?"
dylansmrjones Member since:
2005-10-02

*LOOOOOOOOOOOOOOOOL*

The best link ever posted!

I believe certain developers on the Mac platform have to much spare time, or are just mentally retarded...

The best one was the 'seamon' remark ;)

Reply Score: 1

RE[2]: Oh?
by Anonymous on Tue 18th Oct 2005 16:09 UTC in reply to "RE: Oh?"
Anonymous Member since:
---

I believe certain developers on the Mac platform have to much spare time

Believe me, writing iWhackEm did not take me very long.

The best one was the 'seamon' remark ;)

Thanks. Because that wasn't annoying enough back when I was in middle school.

Reply Score: 0

RE: Oh?
by lemmy on Tue 18th Oct 2005 11:20 UTC in reply to "Oh?"
lemmy Member since:
2005-07-10

why are there nothing but mac apps in the perversion tracker thingie?

Reply Score: 1

RE[2]: Oh?
by Anonymous on Tue 18th Oct 2005 15:56 UTC in reply to "RE: Oh?"
Anonymous Member since:
---

Bad mac software is the focus of that site, I'm afraid. They did once review IE 6, but only because it couldn't render their page at all correctly.

Just remember it in case you ever have access to a mac. Some of the stuff there is really hilarious.

Reply Score: 0

Software indeed sucks
by brulle on Mon 17th Oct 2005 21:13 UTC
brulle
Member since:
2005-09-21

Computer systems are a huge stress factor in my life. They suck pretty badly overall. I think this is why:

* Generally, the problem is not bad code but rather the lack of overall design. There are too many technologies and designs patched together in contemporary software systems.

* We need more well documented interoperable standards and less outdated proprietary software. Software should be designed so it can easily be adapted to the constantly evolving platforms (old cruft can then be thrown out easier.) Software must follow standards.

* Software makers must pay more attention to usability expertise. Software needs to be more intuitive. Abstractions must be solid so they don't constantly leak and bother users.

Reply Score: 1

RE: Software indeed sucks
by Anonymous on Tue 18th Oct 2005 04:42 UTC in reply to "Software indeed sucks"
Anonymous Member since:
---

Exactly!

Reply Score: 0

Writing good software is difficult if...
by DHofmann on Mon 17th Oct 2005 21:15 UTC
DHofmann
Member since:
2005-08-19

Without the right tools, a good requirements spec, unit tests, acceptance tests, usability tests, smoke tests, a daily or continuous build, revision control, a change control plan, defect tracking software, code reviews, well-defined milestones, and a reasonable budget and timeline, I'm sure that writing good software would be very difficult.

Reply Score: 1

Anonymous Member since:
---

Without the right tools, a good requirements spec, unit tests, acceptance tests, usability tests, smoke tests, a daily or continuous build, revision control, a change control plan, defect tracking software, code reviews, well-defined milestones, and a reasonable budget and timeline, I'm sure that writing good software would be very difficult.

It is indeed. My company has treated me (personally) extremely well. The biggest stress I have has been due to schedules that Development has to meet but has no input into. For example:

- I've added features days before official GM, and sent out products and updates with no testing AT ALL beyond a quick run through on my development machine.

- It's no joke to say that I spend more time on exotic new UI elements some suit envisions than on the functionality they control.

- I've had a salesman promise a product he'd never seen to a big account, say he'd have it for them in a month, then call and tell us the good news. This is where our schedules usually come from.

Of the list above, we do have decent tools, revision control, we do continuous builds, and Code Reviews (when debugging something somebody else wrote.) So far we've been very lucky with our products being reasonably stable once they hit market (never mind who this is or what we make, but if you've been in your local electronic retailer in the last few years, etc, you've probably seen it.)

Welcome to the real world!

Reply Score: 2

Anonymous Member since:
---

You can have all that, and the code can still be badly written for historically reason. (spaghetti code)
All that will help you to have a pretty solid codebase but not necesseraly good code.

Reply Score: 0

A Relative Perspective
by Anonymous on Mon 17th Oct 2005 21:16 UTC
Anonymous
Member since:
---

Good code is not expensive or difficult to write. Good code is time consuming to write. Writing software against every possible known bug to man is possible. But is it practical? Designing the most optimal and accurate algorithm, data structure or interface is possible. But is it practical?

The response differs from person to person. A business that needs to meet a deadline will most likely respond in the negative. A research team designing nuclear software will tell you they have no other choice.

Things get worse, because programmers are generally lazy by nature. They won't be programmers if they weren't.

Reply Score: 0

RE: A Relative Perspective
by Anonymous on Tue 18th Oct 2005 17:20 UTC in reply to "A Relative Perspective"
Anonymous Member since:
---

"Good code is not expensive or difficult to write."

time = money

Reply Score: 0

"sucks" sucks
by doug on Mon 17th Oct 2005 21:25 UTC
doug
Member since:
2005-07-07

Saying something "sucks" doesn't help much though. Most commercial software sucks as well. But a commercial developer hears people saying their software sucks and they think about the money they might lose. So in that sense maybe it can work to publicly rant. An open source developer it may only frustrate by the lack of specific or constructive comments, esp. when the critics blame the "mentality" of open source developers.

There are better ways to understand usability and improve usability. Like have some actual data and specific suggestions, and/or code it yourself if you can. Instead of only focusing on "educating" the software designers, we should focus on educating the users as well.

Reply Score: 3

People *do* set out to write bad software
by Anonymous on Mon 17th Oct 2005 21:28 UTC
Anonymous
Member since:
---

The pervasive attitude in software engineering is "I'll just hack this together". This is the mental root cause of bad software. It is especially prevalent in OSS, where hacks are cool, but it is the dominant attitude in the commercial world, too.

I've done it. You've done it. And the software sucks because of it.

Reply Score: 2

bryanv Member since:
2005-08-26

Yep.

I'm guilty. I've been guilty, and as long as I'm working for "the man" I'm stuck in an environment where I'll continue to -have- to be guilty just to keep on target with schedules.

Quality means very little to most people, so long as it can work.

While I personally cannot stand that attitude, it's the prevailing one in the IT industry and corporate world. No one builds anything to last. Planned obsolescense, upgrade versions, cyclic design, never-ending profit centers by forced upgrades.

No manager, CIO, owner, etc. actually WANTS to fix it. They loose their money if they do. It's horrible. No one has any moral character or ethical behavior. Good software could be written, and cheaply. It's a matter of people exacerbating the problem for profit.

Reply Score: 2

Anonymous Member since:
---

Hey, what are you doing, reading and posting on here, when you should be working on the BeOS Java port! ;)

Let me see: you aren't getting paid for the port, and you only have anxious users waiting for it, but they aren't paying for it, and haven't set a fixed deadline (beyond "ASAP") so, does that mean you won't cut corners? ;)

Reply Score: 0

ma_d Member since:
2005-06-29

The meaning of hack in the FOSS world can have a different meaning. It can mean the work done by a hacker, a hacker being one respected by his peers for his work (according to ESR, to be a "hacker" another "hacker" must refer to you as a "hacker", a sign of respect).
Now, the noun, a hack, is something that extends the believed possible behaviour of something. Which is indeed cool, and rarely considered something permanent.

I think a lot of the problem lies in both sides trying to push for too much new stuff too fast. We need to sit back and say "ok, how can we make this better instead of cooler." But that's expensive for the commercial world, and it doesn't please 90% of the users in the FOSS world (except maybe for Apache/MySQL/PHP/Python and other projects where users depend on the dependability a great deal).

Reply Score: 1

Software is About People
by Anonymous on Mon 17th Oct 2005 21:30 UTC
Anonymous
Member since:
---

The reality is that software development is a creative activity whos difficulty depends not only on the complexity of the problem domain, but also on the skills and experience of the programmer(s). Anytime people are involved, you are dealing with a bell curve of maturity and ability. Not everyone is in the 90th percentile. Half the programmers suck (at least more that the other half). When you indiscriminantly put programmers together into teams, you either amplify bad things or neutralize good ones - it is hard to win.

So is all hope lost? For those who are interested in improving their professional skills, no. And the rest don't matter because they probably aren't reading this comment thread anyway. There are organizations out there that are trying to improve the quality of software. The Software Engineering Institute (SEI) at Carnegie Mellon University comes to mind - sei.cmu.edu. The Software Capability Maturity Model and the work on personal and team software processes is interesting. Then again, on the other side of the spectrum, the agile development world has interesting things to offer.

Good programmers need to learn more than languages and frameworks - a little professional knowledge goes a long way. But the software development profession is young compared to others. In many ways, it is a chaotic, personality-driven domain. With time, best practices, ethics and community self-regulation will carve out a lowest-common denominator that doesn't suck as hard. These are interesting times.

Reply Score: 1

Two part problem.
by Anonymous on Mon 17th Oct 2005 21:32 UTC
Anonymous
Member since:
---

Just speaking from my experience, the problems are usually that programmers are rushed to get an application out the door. That causes the programmers to find shortcuts in order to meet that deadline. That then cuts the time for the analyst to hammer at the code and ensure that it's working properly.

Reply Score: 0

re: eugenia's comment
by Anonymous on Mon 17th Oct 2005 21:53 UTC
Anonymous
Member since:
---

bad software results from (1) bad management, (2) bad developers.

in my experience, too many "developers" get jobs without proper qualifications - often they are hobbyist geeks who think they can code - sure they can code, but not design. some of the horrors i have seen ...

i have worked at a nuclear power plant - and they coded everything in fortran 77 - nothing newer because they lacked the oomph to look into alternatives. the error-prone language led - yes, to errors. then some bright spark did what all bright sparks do - contract out the work - and the contractors had no background in physics, maths or chemistry - and they coded in unmaintainable C - with the gravitational constant g==0.

in my experience - the vast majority of bad software is as a result of clueless management.

Reply Score: 0

v bitching!!!!
by Anonymous on Mon 17th Oct 2005 22:16 UTC
One minor overlook?
by mouth on Mon 17th Oct 2005 22:41 UTC
mouth
Member since:
2005-07-06

No one makes bad software on purpose. No benevolent programmer has ever sat down, planning out weeks of work, with the intention of frustrating people and making them cry.

Viruses?

Reply Score: 2

RE: One minor overlook?
by BrianH on Mon 17th Oct 2005 22:44 UTC in reply to "One minor overlook?"
BrianH Member since:
2005-07-06

The key word here is "benevolent".

Reply Score: 1

RE: One minor overlook?
by ma_d on Tue 18th Oct 2005 04:05 UTC in reply to "One minor overlook?"
ma_d Member since:
2005-06-29

Actually, well written virus's are very good software. The quality of 'good' has nothing to do with the morality of the programs output, it has to do with the efficiency and reliability that it does it (including human-machine interaction efficiency and reliability).
Successful worms are extremely good programs in that sense.

Reply Score: 1

The inmates are running the asylum
by corentin on Mon 17th Oct 2005 22:42 UTC
corentin
Member since:
2005-08-08

Now that, after years of "brainwashing" by irresponsible software companies, everybody is used to buggy (if not crappy) software, most companies do not care about delivering reliable products anymore. Most users will not know if the run-time errors they encounter come from the applications, their hardware or their operating system anyway...

It is just about time to market and eye-candy GUIs... Engineers must feel like craftsmen working in factories.

Reply Score: 1

ma_d Member since:
2005-06-29

Ding ding ding, what do we have for him Jonny?!

I still think people are too hard on software. This talk of "using the tool instead of working" is stupid. Ever met a carpenter who "does his work and doesn't think about the tool?" Did he have 10 fingers, no. Oh, this isn't dangerous work you say? Neither is carpentry, you're probably more likely to die as a semi-truck driver!
The tool must receive some thought, from the user too. Otherwise, why can't the user do it without the tool? At some point he gets used to the tool, but still. The more powerful it is (read: the more useful it is), the more a small mistake can screw things up royally. And if a program can predict every mistake possible, well it should be able to do the work without interaction!

Reply Score: 1

Your Customers Don't Care How You Code
by Anonymous on Mon 17th Oct 2005 22:46 UTC
Anonymous
Member since:
---

Successful software is not the result of following good engineering practices. Successful software results from paying attention to what people want, not what you think they need. Good coding and ddesign practices help you, but your customers have no reason to care. They judge you by your deliverable, and they don't care how you got there.

Commercial software has the advantage of the obvious feedback loop provided by sales. Not enough sales? Poof, you're gone. No one will care if you wrote good code or bad code. Commercial vendors don't have the luxury of blaming their unpopular products on their customers.

FOSS coders, of course, have no real feedback loop with their customers, and can continue blithely working on software that the world ignores.

Reply Score: 0

drfelip Member since:
2005-07-06

I think one big advantage of FOSS is just the contrary: very often you can e-mail the authors and tell them "THAT doesn't work for me". They could fix it or not, but communication IS possible. It's more and more difficult as the project is bigger: projects like KDE, Gnome, big commertial distributions like Fedora, SUSE... are less likely to listen to you. So... Think about software giants like Microsoft.

I'm not very sure sales are a good way of knowing if something works well or how to improve it. Sadly, too often marketing is more powerful that quality. Not always the best product is the more successful.

Equally for FOSS and commertial software, communication is ALWAYS important

Reply Score: 1

It's the environment
by Anonymous on Mon 17th Oct 2005 22:49 UTC
Anonymous
Member since:
---

Non-programmers complain about sucky code and ego maniac programmers will call other programmers not fit for the job. Yeah, there is some bad code out there, but we should be thankful for the programs we have. Most programmers aren't trying to write bugs on purpose.

The problem with software development of any kind is the environment. In a changing environment, software is put to the test. Planning what can happen and what does happen can be totally different. I was on one job where we had users come in a test a peiice of software. They used it in ways that didn't dawn on any of us. Programmers will never think exactly like regular users. Also, the environment can be anything. A downed server, and overloaded server, a hung os, a corrupt file, etc.

So quit your crying and find something more productive to do. ;-)

Reply Score: 1

...
by suryad on Mon 17th Oct 2005 22:59 UTC
suryad
Member since:
2005-07-09

Software dev is very hard. Writing good code is very hard. In my software dev class I found that out first hand. I found out because of my desire to finish and because no one in my team was of any use that I was taking horrible shortcuts and not using any of the benefits of OOP. It was a rather huge wakeup call for me. There are tiny things in the process of writing good code that are quite hard to keep track off or keep in line...your teammates attitudes...their coding style, etc etc...it is not just code writing but it is communication amongst the team and the environment as well that will dictate how good code is written.

I read that Nasa has like 1 bug per 100k lines of code or something like that. There is a reason why because every line of code they right, they make sure no bug has been added and they prob produce 5 lines of production code a day.

Software that home users use dont demand insanely high quality like that to keep prices down.

Reply Score: 2

RE: ...
by ma_d on Tue 18th Oct 2005 01:26 UTC in reply to "..."
ma_d Member since:
2005-06-29

You should read Brooke's book. I think you'll find his team suggestions fall in line as a solution to your team problems.

Reply Score: 1

Ironic
by Anonymous on Mon 17th Oct 2005 23:16 UTC
Anonymous
Member since:
---

In his about page:

Scott was a program manager at Microsoft Corporation for many years (1994-2003). He worked on Internet Explorer 1.0 thru 5.0, ...

Am I the only one who finds it ironic that this guy is takling about software quality?

Reply Score: 3

RE: Ironic
by corentin on Mon 17th Oct 2005 23:25 UTC in reply to "Ironic"
corentin Member since:
2005-08-08

> Am I the only one who finds it ironic that this guy is takling about software quality?

Probably.
Maintaining such a beast (based on quite a lot of legacy code, IIRC) is not exactly an easy job, you know. IE is obviously far from perfect, but I am pretty sure it could have been *much* worse.

Reply Score: 1

RE[2]: Ironic
by ma_d on Tue 18th Oct 2005 01:28 UTC in reply to "RE: Ironic"
ma_d Member since:
2005-06-29

Yea, they could have spent a year on it and then had to start from scratch ;) .
It wasn't that bad, but it certainly wasn't at the level of usability it could have been. I think most of the IE complaints fall with the time after he left, 5.5/6.0. Have they fixed that address bar bug yet, where it clears what you just typed to put in the current address?

Reply Score: 1

RE: Ironic
by dylansmrjones on Mon 17th Oct 2005 23:37 UTC in reply to "Ironic"
dylansmrjones Member since:
2005-10-02

It's pretty ironic yeah ;)

But the same could be said about other persons and other projects.

I'm sure several developers has been frustrated with IE.

Reply Score: 1

Why the sudden glut of Microsoft news?
by Anonymous on Mon 17th Oct 2005 23:41 UTC
Anonymous
Member since:
---

XP SP3 Preview Package a Fake
Microsoft Says 'Maybe' to OpenDocument
Microsoft Windows Vista Build 5231 Review
Interview: Bill Gates
and now this, all within 3 days.

Reply Score: 0

poor languages
by bonjour on Tue 18th Oct 2005 00:00 UTC
bonjour
Member since:
2005-07-12

i just had to code a project in java, although there are lots of libraries and helper classes, the language itself is too simple in that half the time you're wrestling with the capabilities of the libraries as opposed to focusing on solving the problem. they need higher level languages, like 10 GL.

here's an example, you want to create a webpage, you can construct code from a text editor, or you can use an environment such as dreamweaver that will give you what you need with drag and drop capability.

another example is a content management system. you pick the template, you pick what features you want and you get a full blown system with database, layout, etc in minutes.

i know there are some uml tools that allow you to model problems and then have that translate to skeleton code, but i'm talking about more enhanced code.

i guess we perhaps need ligher level libraries that do a very specific task. simplify my code size, put more things in libraries.

Reply Score: 1

Douglas Adams
by ma_d on Tue 18th Oct 2005 01:20 UTC
ma_d
Member since:
2005-06-29

This guy reads too much Douglas Adams, two paragraphs in and he's made the "doubly" reference and a reference to a man at a dinner.

Ok, now where he's wrong:
"Creators, often sensitive about their work, may respond by rejecting the very people they were supposed to be designing for, starting the ugly downward spiral of resentment and passive aggressiveness between creators and consumers, which can end only with one result: software that sucks."
The instantiator in this instance is clearly the user, the creator is simply reacting. The blame clearly lies with the ungrateful individual who with no care insulted the benevolent creator. Unless, of course, the user exchanged something valuable for said service, in which cause he wasn't receiving what he was promised; then it's the creators fault for promising what he wasn't delivering. Or, more likely, marketing's fault.

Reply Score: 1

SOFTWARE ENGINEERING GLOSSARY
by Anonymous on Tue 18th Oct 2005 02:21 UTC
Anonymous
Member since:
---

SOFTWARE ENGINEERING GLOSSARY or DEFINING COMPUTER TERMS FROM A MARKETING POINT OF VIEW

ALL NEW -- The software is not compatible with previous versions.

ADVANCED DESIGN -- Upper management doesn t understand it.

BREAKTHROUGH -- It nearly booted on the first try.

NEW -- It comes in different colors from the previous version.

DESIGN SIMPLICITY -- It was developed on a shoe-string budget.

EXCLUSIVE -- We re the only ones who have the documentation.

FIELD TESTED -- Manufacturing doesn t have a test system.

FOOLPROOF OPERATION -- All parameters are hard coded.

FUTURISTIC -- It only runs on the next-generation supercomputer.

HIGH ACCURACY -- All the directories compare.

IT S HERE AT LAST -- We ve released a 26-week project in 48 weeks.

MAINTENANCE FREE -- It s impossible to fix.

MEETS QUALITY STANDARDS -- It compiles without errors.

PERFORMANCE PROVEN -- It works through beta test.

REVOLUTIONARY -- The disk drives go round and round.

SATISFACTION GUARANTEED -- We ll send you another copy if it fails.

STOCK ITEM -- We shipped it once before, and we can do it again, probably.

UNMATCHED -- It s almost as good as the competition.

UNPRECEDENTED PERFORMANCE -- Nothing ever ran this slow before.

YEARS OF DEVELOPMENT -- We finally got one to work.

Reply Score: 1

...
by suryad on Tue 18th Oct 2005 02:26 UTC
suryad
Member since:
2005-07-09

Someone here posted about Dreamweaver and requirement of better languages than Java and C++. I agree to a certain point but you cannot blame it all on the language. Whenever you approach a programming project I think that one should see the whole picture first, and break it into several components and then identify the tools required for writing the components. If you use an IDE then great your life will be a lot easier.

After identifying the components of the project then you will need to look for the APIs that you will use and Java has a crapload of those already in the Standard Kit.

It is all about following the OOP rules strictly, by learning the knitty gritty of the language, by knowing how the compiler for that language would work, tradeoffs and so on. We as programmers have to think constantly of how to balance the whole situation out. I hope that makes sense what i am trying to say.

Since software is a manmade construct of something that is absolutely abstract and artificial, it is not going to be perfect. And add to that fact that not everyone is a great programmer and of course you will get bad software code all around. Software is not easy to write and develop.

Reply Score: 1

RE: ...
by ma_d on Tue 18th Oct 2005 04:03 UTC in reply to "..."
ma_d Member since:
2005-06-29

I'd argue that an IDE, verse a non-integrated development environment, makes absolutely no difference and can end up being a hindrance as much as a help. But, using all the tools available too you, that is what you do need.

I'd say language makes little difference. The end-decision is going to be based more on what libraries are available in a given language. Don't get me wrong, I'd much rather write something in Python over C; but I think the benefit the language gives you is fairly small. In c, you fight with memory issues that are hard to find. In Python, you fight with bugs that only happen at certain run-times (bugs which would be caught by a compiler in a strongly typed language).
I think quality control is important in every language you use, and it's going to cost significant time at the end.
I can write something a lot faster in Python than c, but I'm still gonna need to fully test and improve the python code for performance when I'm done anyway.

Reply Score: 1

RE: languages
by bonjour on Tue 18th Oct 2005 10:47 UTC in reply to "..."
bonjour Member since:
2005-07-12

i don't think divide and conquer necessarily solves the problem. i'm talking about higher level problems. you're so focused on OOP and the intracacies of OOP that you forget the real problem that you're trying to solve. let's say you want to write a document management/workflow engine. you could probably find several libraries/components to help you get to your end goal. but how much glue code must you write to utilize all these disparate parts?? and how much is missing in terms functionality that you have to build yourself?

how long does it take?

WE NEED 10th GENERATION LANGUAGES (10 GL)

Cocoa is not bad, i think interface builder makes it more like a 5 GL but not a 10 GL. I wrote a text editor in about 20 minutes. the text field with a scroll pane that handles glyphs, fonts, and spell checking was available immediately. drag and drop. interface builder allows you connect things without writing a lick of code.

the only problem is now i want to add line numbers and syntax highlighting. i must code my own package from the ground up.

the base cocoa language only gives you functionality like data structures, very simple gui components. we need more components, pre-fabricated and available.

we're focusing too much on the nuances of each language that we're unable to do big things very quickly and easily. that's almost like job security.

it is the language that is the problem. just like verbal language has not necessarily evolved. for very complex problems, it's sometimes hard to express things easily in say English. if we improved our languages, both programming and speaking, we'd be able to evolve to the next level as humans. mathematics is an evolved language. computer science is an evolved language, however, we're still programming with technology from 20 years ago, OOP isn't new. functions, classes, inheritence, it's all the same as it ever was. we need more.

Reply Score: 1

some points
by Anonymous on Tue 18th Oct 2005 04:49 UTC
Anonymous
Member since:
---

First off, I would like to say that it is insanely difficult to write "good code" in a corporate environment. typically, you have one shot at doing something the Right Way. After that, it is QAd, bugs are fixed, and the chance at a rewrite is next to nothing, unless you manage to convince your manager the world will come to an end if he doesnt let you fix it properly.

As for tools, I would say that a good IDE can make a significant difference. Also, a good IDE is rare, and usually quite expensive. With a good IDE (i.e. real time syntax checking, good customizable code templating/generation, refactoring tools, full featured debugger, compiler/integrated deployment tools) both your productivity and code quality will increase. Nothing can help with logic issues, but not having to deal with more mundane problems will free up your mind, letting you concentrate on the stuff that matters. Time for a manditory IDE of Choice plug, after using intelliJs IDEa for two years, i can say that i never have syntax errors, can rapidly generate "plumbing" classes and methods with a few keystrokes, and can quickly and easily refactor the entire codebase.

last but not least, it is very rarely "lazy programmers", and more often "moronic management" that is the cause of bad code. i cant count the amount of times when something has been sold before it was finished, and massive amounts of work had to be done in a rediculesly short amount of time to deliver what we were legally obligated to deliver. this is rather normal. you tell them "this is bad, it needs to be fixed." they tell you "it offers visible improvement to the clients, and it will take time out of the already tight project plan for things which will offer visible improvements and allow us to sell more copies" you say "this is bad, and we will pay for it later" they ignore you. five months down the line, all hell breaks loose, and the same team that warned management of the problem pulls 18 hour days desperately trying to patch it up so the company doesnt get sued. does that make them lazy? if anything, programmers are the only ones in a software house actually trying to put out something of quality.

users have no clue what goes into software, and what motivates commercial software development. students have no idea whatsoever of what its like to actually work in the industry. and yet both are being quite vocal in this thread, and extremely insulting. if anyone wants to know why programmers are often hostile to users, just look at some of the attitudes expressed here by people who (by their definition) have no clue what they are talking about.

Reply Score: 0

Anonymous Member since:
---


OSS is not going to win SHIT by having prettier desktops and by out-friendlying MS/Apple.. MS has already won if we've decided to try to beat them at their own games. We're goign to win by technocratic superiority, innovation and ultimately through trickle down. Give the people setting up systems more reason to install, the masses will adapt as they are required. What is most important, give developers more reason to become a part of the community. OSS is still building inertia, an inertia which revolves entirely around technical innovation.


not even going to BOTHER with the first part.

we already have technological superiority. i believe you are comparing linux to windows, which is probably one of the least interesting operating systems in use at the moment. if you want interesting, look at solaris. hell, look at plan9. windows isnt even on the map.

we have already won, the goal of oss is to write good software, and we have a great environment at this point in time, so great its really shaking things up for the other guys. the masses are completely and totally irrelivent. the only people who believe that the purpose of linux is to defeat microsoft in some epic battle between good and evil are fanbois.

once again, just so everyone gets it. the grand, overall goal of oss has NOTHING to do with microsoft, the masses, or anything other then writing good software. individual projects may have their own goals, but pretty much anything that is any good is written with the purpose of being a something that doesnt suck, rather then being an alternative to something.

Reply Score: 0

Tuishimi
Member since:
2005-07-06

...and I will tell you that the best code I ever wrote was for DEC because we had rules to follow. Coding standards, review processes in place, documentation throughout the life cycle, etc.

Every where else I have been they have tried to do it. Not with a ton of success. But these new trends... I just don't know. I guess I am old fashioned where I believe 90% of the code is written in the requirements and the functional specification before the actual coding ever begins. By that, I mean the requirements have to be good, the functional design has to be good, THEN the basic functional test plan should be in place and THEN begin with the design specifications.

But these days it goes like this: You have 2 months to do X Y Z. Now get to it and DO IT RIGHT! Well, the battle is already lost at this point. Software engineers are no longer allowed to "engineer". That's why we are all becoming "programmers" and "developers".

:(

Reply Score: 5

Tuishimi Member since:
2005-07-06

And when I say "90% of the code is already written" I meant it figuratively. It is done on paper or in your head because if you have all the data and the processes defined well, that is more than half the battle.

Reply Score: 1

corentin Member since:
2005-08-08

> ...and I will tell you that the best code I ever wrote was for DEC because we had rules to follow. Coding standards, review processes in place, documentation throughout the life cycle, etc.

That is funny, because I just thought of DEC yesterday when reading this thread ;)

You did not wrote the best code ever because you followed rule X or Y; you wrote the best code ever because everyone at Digital (including the managers) cared about, *and was proud of*, the quality of their products (and as a direct result, you used the right tools to obtain quality).

Reply Score: 1

Tuishimi Member since:
2005-07-06

Yes... and because of that processes and procedures were followed/enforced. ;) Let me give you an example: 2 years ago I and a several others were asked to come up with a design and based on requirements (this was not at DEC). We designed it, then provided them with estimates for man hours and also cautioned them that just throwing people at it would not get it done faster, yadda yadda.
They did not like our answer and trimmed their requirements. We like-wise spent another few weeks coming back to them with the revised estimate of (roughly here) 10 months from start to user test (not QA - a sort of Beta version). They said "we'll go with that but you only have 6 months!"

I mean what is that?!?! Talk about cutting corners here and there. And frankly, developers are notoriously optimistic about their estimates (forgetting about the daily interruptions and such).

I don't know. I mean, I understand that it is important to get products out the door... new and improved! Make more $$$... but it seems like they would rather send something out buggy than send it out done right.

Reply Score: 1

Anonymous Member since:
---

The old Rule #1 of product development was: There is never enough time to do it right, but there is always enough time to do it over.

And now, with accelerated release schedules and people working on more than one product at the same time, there is rarely enough time to do it over. Just fix the bugs.

So the new Rule #1 is: ./configure, make, make install, release.

Reply Score: 0

Tuishimi Member since:
2005-07-06

Btw... I guess I don't disagree with you. ;)

Reply Score: 1

Perfection
by jonas.kirilla on Tue 18th Oct 2005 07:09 UTC
jonas.kirilla
Member since:
2005-07-11

Software perfection is limited by the level of perfection of the underlying hardware.

In the words of 'Yes':

"Maybe we'll change
Offered the chance
To finally unlearn our lessons
And alter our stance.
...
Machine, machine Messiah.
Take me into the fire

Hold me, machine Messiah
And show me
The strength of your singular eye."

;)

Reply Score: 1

RE
by Anonymous on Tue 18th Oct 2005 07:42 UTC
Anonymous
Member since:
---

No one makes bad software on purpose

Real Player



next please

Reply Score: 0

Anonymous
Member since:
---

Currently, MS dominates the general public market in the areas of desktop computing. Unless, we get the very platform stabilized, and sucky PC architecture thrown out the door, we won't have a stable software or should I say that it is very hard to do.

It's like trying to build a house on top of mud soil.

:(

Reply Score: 0

Brilliant article
by MatzeB on Tue 18th Oct 2005 09:25 UTC
MatzeB
Member since:
2005-07-06

Very good article. This is exactly the experience I had when creating software and watching people use it then.

I'm shocked by all these comments here that take external things like schedules, hardware, system software or laziness as excuses for not producing good software. It seems most people are not even trying to create good software :-(

Reply Score: 1

Database programmers
by lefty78312 on Tue 18th Oct 2005 12:37 UTC
lefty78312
Member since:
2005-10-18

I encounter this most often with database programmers, who don't have a clue in the world how their program is going to be used and don't care. They write programs they can sell to a buyer; not programs that assist the end user. The concept of actually testing their work with real users never enters their head. I can't tell you how many databases I've worked with that needed changes, sometimes major ones, that will never be made. Even our own in-house database programmer is clueless. He writes what HE thinks will work for us, but he would never consider asking us what really works. What's worse is that he sometimes independently makes changes and sets program defaults that cannot possibly make any difference to him, but that make things more difficult for the users, and we would have to pay him to get them corrected. Which will never happen due to budgetary concerns. I'm not even a programmer, and I could write spreadsheets that are more useful than some of the databases I've worked with.

I don't know who is more to blame; the programmers themselves or the incompetents who approve the expenditure for substandard work without any real-world testing.

Reply Score: 1

Article is wrong
by Anonymous on Tue 18th Oct 2005 13:55 UTC
Anonymous
Member since:
---

"No one makes bad software on purpose." As I programmer I resent this remark. After having to deal with stupid end users I know for a fact that I and other people have seriously considered (and others have created) software with the purpose of frustrating those same stupid users.

Reply Score: 0

I disagree...
by Anonymous on Tue 18th Oct 2005 15:37 UTC
Anonymous
Member since:
---

I fully intend on making a piece of software that will have people tearing out their hair. Of course, it's a puzzle game, but the point still stands. You're generalizing! : )

Reply Score: 0