The Artima Developer Community
Sponsored Link

Weblogs Forum
Why Software Sucks

67 replies on 5 pages. Most recent reply: Sep 29, 2005 5:09 AM by Vincent O'Sullivan

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 67 replies on 5 pages [ « | 1 2 3 4 5 | » ]
robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Dichotomy purgatory? Posted: Sep 23, 2005 4:54 PM
Reply to this message Reply
Advertisement
> (A) BCNF is only "complete" w.r.t. attribute constraints.
> It's incomplete in terms of join dependencies. Note
> carefully that that use of "complete" is heavily qualified
> because the "completeness" isn't predicated on e.g.,
> reality but rather the self-consistency of the model.
> That's a huge, quantum difference.

quite so. P/JNF is higher up. and gets into the realm of NP complete, in terms of analytic solvability with automatic tools. that said, it's still better, IMHO, if all formal constraints are managed from one place. one fact, one place, one time. the alternative is hard-coding. that's the real result. of course, coders declaim that they would Never Hard Code Anything, but of course, that's exactly what happens.

workflow and business rule engines are au courant. Chisholm has a book on BR engines. written from Access, if you can believe it. i buy Date's argument: a row is a Business Rule.

>
> (B) Note clearly that the SQL worldview is distinct from
> the actual relational worldview. For a more detail on
> this, check out e.g., C.J. Date's recent book published by
> O'Reilly, http://press.oreilly.com/pub/pr/1353
>
> (C) As noted previously, the database is everything
> approach is just as broken as the code is everything
> approach. This has been proven again and again over the
> years.

i'm not convinced that it's been done often enough to know. no argument that SQL /== RM. OTOH, SQL databases can get the job done. and anyway, what constraints on data integrity *have to* live outside the data? that's the question that the code is everything (or mostly) need to answer. and why these constraints are better housed across multiple programs. and so on.

>
>
> >> For example, is the shifting view of programmers
> >> due to unit testing actually helping people think
> better?
> >
> > no.
>
> Really? Isn't a lot of the changes in behavior in terms
> of the awareness of e.g., the value of quality being
> helped along (if not instigated among many groups) because
> "unit testing" has become popular?

in the java world, at least, this is tied to Bean Paradigm, to which i do not subscribe. and there is a, smaller, movement here to, calling itself Prefactoring or Big Design Up Front (Spolsky's term). Meyer's Design by Contract is about the same thing. the problem with the dynamic/test-it-til-it-breaks viewpoint is the assumption that one can define all the execution paths empirically after the fact and test them in finite time. i don't subscribe to that either.

Scott Berkun

Posts: 3
Nickname: berkun
Registered: Sep, 2005

Re: Why Software Sucks Posted: Sep 23, 2005 6:08 PM
Reply to this message Reply
Hope I don't spoil the party by de-lurking, but the excellent dialog here provoked a response.

Three things:

1) I completely avoided the business of software arguments, which have a huge set of implications about quality. Different business models place a different emhpasis on quality. The essay was fat already (4k) so I ripped it out. Some of you made points i'd have agreed with.

2) There are tons of reasons things suck, software or otherwise. I tried to get that across in the essay: it's usually a combination of the factors we've mentioned occuring in minor levels that combined make for signifigant suckage: it's rarely a dramatic failure of just one thing.

3) I've thought about suck for software and in general and it seems for most things, most of the time, people are happy with mediocrity. It's only a minority of people that care enough, and can afford, excellent things. Apple, BMW, Rolex are all minority brands: the best of anything is rarely the most popular. It's safe to say that in any industry, at any time, people are having the same conversation we are.

Anyway, just wanted to say hi, and commend the dialog here. The signal to noise on /. is hard to follow but I enjoyed reading all the comments here.

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: Why Software Sucks Posted: Sep 23, 2005 9:01 PM
Reply to this message Reply
Simple answer: because there is no objective measure of software reliability in general. As long as there are tests that provide definite answers ( e.g. tests used in certification processes ) reliability can be measured and software doesn't suck more than any other engineering product. If we talk about subjectively felt sucking about beauty or budget overrun I would recommend a little more self-confidence: stop spreading braindead car comparisons and the software-sucking myth which has become a kind of folklore among software developers. As long as you aren't precisely know what you are talking about and what you are accused for let others spread the myth and try to defend your position. You can almost always be sure that most of the accusations made by people are completely idiotic. Try to listen but don't take them to serious.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Why Software Sucks Posted: Sep 24, 2005 2:20 AM
Reply to this message Reply
> Nah, the biggest problem is customer expectation.

I don't think it can be over emphasised enough that neither the customers nor their expectations are problems. They are the starting point from which all software is generated.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Why Software Sucks Posted: Sep 24, 2005 12:13 PM
Reply to this message Reply
Scott Berkun:
> 3) I've thought about suck for software and in general and
> it seems for most things, most of the time, people are
> happy with mediocrity. It's only a minority of people that
> care enough, and can afford, excellent things.

"Reasonable people adapt themselves to the world. Unreasonable people attempt to adapt the world to themselves. All progress, therefore, depends on unreasonable people."
George Bernard Shaw

John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

DB-or-bust Posted: Sep 24, 2005 1:14 PM
Reply to this message Reply
> quite so. P/JNF is higher up. and gets into the realm of
> NP complete, in terms of analytic solvability with
> automatic tools. that said, it's still better, IMHO, if
> all formal constraints are managed from one place. one
> fact, one place, one time. the alternative is
> hard-coding. that's the real result. of course, coders
> declaim that they would Never Hard Code Anything, but of
> course, that's exactly what happens.

I'm confused by your argument... You note things like NP-complete barriers and yet you seem to believe that there can be complete control from the database. Do you not see the contradiction there?

> > (C) As noted previously, the database is everything
> > approach is just as broken as the code is everything
> > approach. This has been proven again and again over the
> > years.
>
> i'm not convinced that it's been done often enough to
> know.

Seriously? Ouch. For the current crack, check out the Model-Driven Architecture hype and reality -- CASE lives. Also, have you looked at all of the abject failures in the DB-is-everything approaches to building web sites? Ando those are relatively simple.

> no argument that SQL /== RM. OTOH, SQL databases can
> get the job done. and anyway, what constraints on data
> integrity *have to* live outside the data? that's the
> question that the code is everything (or mostly) need to
> answer. and why these constraints are better housed
> across multiple programs. and so on.

No, that's exactly the point. SQL can't get the job done by itself. It's fundamentally incomplete and broken. Seriously, Date's book that I mentioned makes very clear arguments of this.

> > Really? Isn't a lot of the changes in behavior in terms
> > of the awareness of e.g., the value of quality being
> > helped along (if not instigated among many groups) because
> > "unit testing" has become popular?
>
> in the java world, at least, this is tied to Bean
> Paradigm, to which i do not subscribe.

Huh? Java beans have nothing per se to do with unit testing (or testing in general, for that matter).

> and there is a,
> smaller, movement here to, calling itself Prefactoring or
> Big Design Up Front (Spolsky's term). Meyer's Design by
> Contract is about the same thing. the problem with the
> dynamic/test-it-til-it-breaks viewpoint is the assumption
> that one can define all the execution paths empirically
> after the fact and test them in finite time. i don't
> subscribe to that either.

(A) My question was about whether the popularity of e.g., unit testing has had any beneficial effect on programmer mentality w.r.t. quality. Yes, of course other approaches such as DbC have a lot of overlap therewith but they haven't ever caught on like the JUnit-instigated unit testing "fad". I find it hard to believe that there are any arguments to that but I'm certainly curious.

(B) What does the question about e.g., unit testing mindset have to do with the question of perfection? Is anything in this thread about perfection? Aren't we talking about how to reduce suckage (and increase goodness)?

(C) The unit testing fad is part of the TDD movement. I.e., the incremental, write-test-first worldview rather than the reactive, post-code testing approach.

John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

Mediocrity normalcy? Posted: Sep 24, 2005 1:39 PM
Reply to this message Reply
> Hope I don't spoil the party by de-lurking, but the
> excellent dialog here provoked a response.

Thanks for joining in.

> Three things:
>
> 1) I completely avoided the business of software
> arguments, which have a huge set of implications about
> quality. Different business models place a different
> emhpasis on quality.

So, suckage is contextual.

> 2) There are tons of reasons things suck, software or
> otherwise. I tried to get that across in the essay: it's
> usually a combination of the factors we've mentioned
> occuring in minor levels that combined make for
> signifigant suckage: it's rarely a dramatic failure of
> just one thing.

Indeed. Would you agree that suckage is primarily a systemic issue?

> 3) I've thought about suck for software and in general and
> it seems for most things, most of the time, people are
> happy with mediocrity. It's only a minority of people that
> care enough, and can afford, excellent things. Apple, BMW,
> Rolex are all minority brands: the best of anything is
> rarely the most popular. It's safe to say that in any
> industry, at any time, people are having the same
> conversation we are.

Are people actually "happy" with the mediocrity? Or is it really the case that most people are so used to the mediocrity and suckage that it's become normalized?

Also, is the polarization into sucks vs. "best" really the issue? I think a more useful goal is transforming sucks into decent and/or good.

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: DB-or-bust Posted: Sep 24, 2005 2:43 PM
Reply to this message Reply
> I'm confused by your argument... You note things like
> NP-complete barriers and yet you seem to believe that
> there can be complete control from the database. Do you
> not see the contradiction there?

no. because there isn't. it's not a barrier to database driven design. only the quest for a final NF, in some cases.

certain structures need to be 5NF or DKNF to avoid anomalies. the NP complete argument is that finding such with automated tools is known to be NP complete. the complication still exists, whether it's dealt with by structure (NF) or code (check constraint, domain constraint, trigger, SP, application code). to quote Mr. Celko (who??): "There are strong JPNFs and overstrong JPNFs, which make use of JOIN dependencies (JDs for short). Unfortunately, there is no systematic way to find a JPNF or 4NF schema, because the problem is known to be NP-complete".

i vote for putting the code not in the application(s), if only to avoid the duplication (and lack of accurate duplication, of course). DRY is au courant, but coders rarely see that the database is the best place (barring clear evidence to the contrary) to make this happen. the individual coder seeks to not repeat s/heself. blissfully ignoring all those other folks who end up repeating the same code and/or data (with egocentric variations, of course). this is progress?

>
> > > (C) As noted previously, the database is everything
> > > approach is just as broken as the code is everything
> > > approach. This has been proven again and again over
> the
> > > years.
> >
> > i'm not convinced that it's been done often enough to
> > know.
>
> Seriously? Ouch. For the current crack, check out the
> Model-Driven Architecture hype and reality -- CASE lives.

MDA is not database driven. i just googled the OMG-MDA FAQ. database is not used even once. such was my recollection.

> Also, have you looked at all of the abject failures in
> n the DB-is-everything approaches to building web sites?

cite a couple of examples, and i'll go look at the craters.

> Ando those are relatively simple.
>
> No, that's exactly the point. SQL can't get the job done
> by itself. It's fundamentally incomplete and broken.
> Seriously, Date's book that I mentioned makes very clear
> r arguments of this.

but Date *doesn't* argue that data control, a posteriori, should be in countless application codebases. he, and Pascal, argue for strengthening the database, not abandoning it. read them on OO and XML; bring your asbestos undies. you won't find any support from them.

> (A) My question was about whether the popularity of e.g.,
> unit testing has had any beneficial effect on programmer
> mentality w.r.t. quality. Yes, of course other approaches
> such as DbC have a lot of overlap therewith but they
> haven't ever caught on like the JUnit-instigated unit
> testing "fad".

it encourages coders (used globally) to not put much thought into what they're doing. the tester will find all the bugs, so, What, Me Worry??. "fad" is a synonym for "herd". we've seen where that has brought the world lately, now haven't we? fact is, there are few high-order thinkers in this world. generally, where the "herd" goes is where i try to avoid. herds don't have high-order thinkers.

I find it hard to believe that there are
> any arguments to that but I'm certainly curious.
>
> (B) What does the question about e.g., unit testing
> mindset have to do with the question of perfection? Is
> anything in this thread about perfection? Aren't we
> talking about how to reduce suckage (and increase
> goodness)?

see above. but, again. when talking about the applications that most people deal with in a working environment, we're dealing with data based (DB or files or whatever) programs with a UI. suckage in this milieu comes down to one of two things: the app is harder to use than the one i had before; the app screwed up the data that i gave it. for this arena, where some of the programming world is going, back to language/data, is retrograde. and the source of the suckage.

if someone posited that the COBOL/VSAM paradigm was the apotheosis of programming in 2005, wellllllllll. but, structurally, java/object, is really no different. both assert that the data belongs to one set of code, written in one language, and that access to the data *must* (even read) go through that code. code independent access to data, read or write, is forbidden. i object to that. and it makes for suckage for this class of users. business data is being tied up in java just as tightly as it was tied up in COBOL in the 1970s. this is progress?

and don't start with the "XML is a great database" stuff. please. the idea is not the progeny of high-order thinking.
>
> (C) The unit testing fad is part of the TDD movement.
> I.e., the incremental, write-test-first worldview rather
> than the reactive, post-code testing approach.

well, there is the think-about-it-and-design-it-right way too. the TDD cult assert that this is not possible, so why try?

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Dichotomy purgatory? Posted: Sep 24, 2005 3:27 PM
Reply to this message Reply
>
> (C) As noted previously, the database is everything
> approach is just as broken as the code is everything
> approach. This has been proven again and again over the
> years.
>
>
looking for a place to toss another carrot into the stew.

let's take as axiomatic that MVC is the dominant paradigm these days. and let's take as empirically proved that (most) always, the Model and Controller are joined at the hip in the code. certainly, in the java servlet world, that's true.

consider that the database is perfectly capable of implementing M & C; these are the schema objects, we don't need no stinkin java. that leaves V. as stated muchly, there is a movement afoot to drive V from the database schema (M & C), rather than from some form of user generated artifact; which in turn must drive the datastore.

in re-reading the thread, i still haven't found any evidence that this is a stupid thing to do, other than by reference to the (as yet unidentified) "abject failures". it may be that current technologies don't do it very well. but, i see that as a separate question. the original question was: "why does software suck?". and in the arena where this sub-thread lives, the answer is because the code too often messes up or obscures the data or is less easy to use than old way.

the View can be as complicated or prettified as the view language can make it. after all, it is decoupled from the Model. widgets aren't the data.

John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

Re: DB-or-bust Posted: Sep 24, 2005 4:41 PM
Reply to this message Reply
> i vote for putting the code not in the application(s), if
> only to avoid the duplication (and lack of accurate
> duplication, of course). DRY is au courant, but coders
> rarely see that the database is the best place (barring
> clear evidence to the contrary) to make this happen. the
> individual coder seeks to not repeat s/heself. blissfully
> ignoring all those other folks who end up repeating the
> same code and/or data (with egocentric variations, of
> course). this is progress?

So, what you're wanting to do is make the whole universe fit in the database. The only way that can possibly work is to add all sorts of dirty stuff that code is currently used for. And so how would that be progress? Back to monolithic jumbles?


> > Seriously? Ouch. For the current crack, check out the
> > Model-Driven Architecture hype and reality -- CASE
> lives.
>
> MDA is not database driven. i just googled the OMG-MDA
> FAQ. database is not used even once. such was my
> recollection.

As sorry for the too-abrupt segue. MDA suffers from the same basic delusion -- that one thing can be everything for everybody.

> > Also, have you looked at all of the abject failures in
> > the DB-is-everything approaches to building web sites?
>
> cite a couple of examples, and i'll go look at the
> craters.

There everywhere. Do some searching. If you can't find them, look at it from the other direction: Where are all of the purely database driven solutions (and, if they are so much better, why haven't they wiped the floor with all of the other crappy solutions :-).

> > Ando those are relatively simple.
> >
> > No, that's exactly the point. SQL can't get the job
> done
> > by itself. It's fundamentally incomplete and broken.
> > Seriously, Date's book that I mentioned makes very
> clear
> > r arguments of this.
>
> but Date *doesn't* argue that data control, a posteriori,
> should be in countless application codebases. he, and
> Pascal, argue for strengthening the database, not
> abandoning it. read them on OO and XML; bring your
> asbestos undies. you won't find any support from them.

Sigh. This DB vs. the rest of the world chip on the shoulder is really boring.

Date is talking about the Relational Model. That's a very different thing from SQL databases. Yes, maybe someday an actual database system will be built that is precisely the relational model. That's completely irrelevant to this discussion (AFAICS) because Date recognizes that the relational model isn't, by itself, sufficient to cover all of the capabilities of a complete software system (it's "merely" a necessary component). I.e., as I've said, the database-is-everything approach is just as broken as any other such simplistic notion.


> > (A) My question was about whether the popularity of e.g.,
> > unit testing has had any beneficial effect on programmer
> > mentality w.r.t. quality. Yes, of course other approaches
> > such as DbC have a lot of overlap therewith but they
> > haven't ever caught on like the JUnit-instigated unit
> > testing "fad".
>
> it encourages coders (used globally) to not put much
> thought into what they're doing. the tester will find all
> the bugs, so, What, Me Worry??.

I think you're confused about what "unit testing" means. (A) "unit tests" are created by the developers. (B) Ala TDD, the tests are typically written before the code and so, by definition, the developers are having to think about what is being created.

> "fad" is a synonym for
> "herd". we've seen where that has brought the world
> lately, now haven't we? fact is, there are few high-order
> thinkers in this world. generally, where the "herd" goes
> is where i try to avoid. herds don't have high-order
> thinkers.

So the fact that herd is making progress is irrelevant to you?

> > (B) What does the question about e.g., unit testing
> > mindset have to do with the question of perfection? Is
> > anything in this thread about perfection? Aren't we
> > talking about how to reduce suckage (and increase
> > goodness)?
>
> see above. but, again. when talking about the
> applications that most people deal with in a working
> environment, we're dealing with data based (DB or files or
> whatever) programs with a UI. suckage in this milieu
> comes down to one of two things: the app is harder to use
> than the one i had before; the app screwed up the data
> that i gave it. for this arena, where some of the
> programming world is going, back to language/data, is
> retrograde. and the source of the suckage.

IME, a very big chunk of the anti-DB-centric movement is actually a reaction to the suckage of the DB-centric worldview. The complexity of the unified, centralized DB has shown to be very costly and very brittle. I do like the Agile Database movement as it's helping to break down the brittleness issue into something more manageable.

> if someone posited that the COBOL/VSAM paradigm was the
> apotheosis of programming in 2005, wellllllllll. but,
> structurally, java/object, is really no different. both
> assert that the data belongs to one set of code, written
> in one language, and that access to the data *must* (even
> read) go through that code. code independent access to
> data, read or write, is forbidden. i object to that. and
> it makes for suckage for this class of users. business
> data is being tied up in java just as tightly as it was
> tied up in COBOL in the 1970s. this is progress?

As I've said repeatedly, the code-is-everything approach is just as broken as the DB-is-everything approach. They are merely two ends of the same paradox. I'd like to get to the question of what's the unification/transcendence of that paradox because I think that's the only way out of this "religious" war.

> and don't start with the "XML is a great database" stuff.
> please. the idea is not the progeny of high-order
> thinking.

I totally concur.

> > (C) The unit testing fad is part of the TDD movement.
> > I.e., the incremental, write-test-first worldview rather
> > than the reactive, post-code testing approach.
>
> well, there is the think-about-it-and-design-it-right way
> too. the TDD cult assert that this is not possible, so
> why try?

I totally agree that the extreministas all-too-often hamper the reasonable and rational discussion of adaptive, feedback driven design. That incalcitrance aside, there's no fundamental conflict between good thinking and adaptive, incremental, and feedback driven development. It's just another spectrum -- no single point on the spectrum is magically the best spot above all others for all contexts. IMHO, the point to focus on is the adaptivity to use what works well in the context.

John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

Re: Dichotomy purgatory? Posted: Sep 24, 2005 4:46 PM
Reply to this message Reply
> in re-reading the thread, i still haven't found any
> evidence that this is a stupid thing to do, other than by
> reference to the (as yet unidentified) "abject failures".
> it may be that current technologies don't do it very
> y well. but, i see that as a separate question.

How can that possibly be a separate question? The proof is in the pudding and, right now, most pudding isn't so yummy.

> the original question was: "why does software suck?". and in
> the arena where this sub-thread lives, the answer is
> because the code too often messes up or obscures the data
> or is less easy to use than old way.

And the data by itself is almost as worthless as the code all by itself. Data without semantics. It's not a question of either/or but of and.

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: DB-or-bust Posted: Sep 24, 2005 7:50 PM
Reply to this message Reply
> So, what you're wanting to do is make the whole universe
> fit in the database. The only way that can possibly work
> is to add all sorts of dirty stuff that code is currently
> used for. And so how would that be progress? Back to
> monolithic jumbles?

a misaprehension at work here, i think. not that all function is in the database, per se. just that the specifications for integrity are. flip the coin: why should there be specfications/implementations for the integrity of the data outside the data? what does code know about the data that the data doesn't know? why would that even make sense? the only thing way that could happen is if the coder hard-codes cruft.

> Sigh. This DB vs. the rest of the world chip on the
> shoulder is really boring.

so, i'll sign off.

> So the fact that herd is making progress is irrelevant to
> you?

well, Xquery is my favorite example of herd progress <G>.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Why Software Sucks Posted: Sep 26, 2005 8:39 AM
Reply to this message Reply
> Apple, BMW,
> Rolex are all minority brands: the best of anything is
> rarely the most popular.

Surely these are all examples of 'bling'. If I met someone who climbed out of their BMW - iPod plugged into their ears - checking the time on their Rolex, my reaction would not be that here's someone of good taste, but on the contrary, here's someone who gets their 'taste' from the pages of glossy magazines.

nes

Posts: 137
Nickname: nn
Registered: Jul, 2004

Re: Why Software Sucks Posted: Sep 26, 2005 10:51 AM
Reply to this message Reply
> > Nah, the biggest problem is customer expectation.
>
> I don't think it can be over emphasised enough that
> neither the customers nor their expectations are problems.
> They are the starting point from which all software is
> s generated.

Ok, ok... let's reword that then. The problem is that we as programmers are unable to write software that can determine the individual user's expectation and can then quickly be customized and tailored to him.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: Why Software Sucks Posted: Sep 26, 2005 4:52 PM
Reply to this message Reply
> > Apple, BMW,
> > Rolex are all minority brands: the best of anything is
> > rarely the most popular.
>
> Surely these are all examples of 'bling'. If I met
> someone who climbed out of their BMW - iPod plugged into
> their ears - checking the time on their Rolex, my reaction
> would not be that here's someone of good taste, but on the
> contrary, here's someone who gets their 'taste' from the
> pages of glossy magazines.


And were do the glossy magazines get it? Sometimes the best stuff is the best stuff (not always - but often).

Flat View: This topic has 67 replies on 5 pages [ « | 1  2  3  4  5 | » ]
Topic: Metaprogramming on Steroids: Overloaded Type Operators Previous Topic   Next Topic Topic: Hacking and Refactoring


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us