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 | » ]
John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

HW vs. Software Posted: Sep 22, 2005 12:00 PM
Reply to this message Reply
Advertisement
> > Is software doomed to mostly suck just like everything else?
>
> Here's a question to ponder: if elevators and bridges
> mostly sucked wouldn't most of us be dead?

(A) How many thousands of years have people been building physical bridges? How easy is it to tell whether or not a bridge is having problems? How simple are even the new bridges compared to even something as basic as say MS Word.

(B) One of the killers benefits/curses of software is the very fact that it is, by definition, soft. That is, unlike bridges where physical reality is 99.9...% of the issue and all of the abstract issues are covered by what's leftover, for most software, it's basically the other way around.

John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

"That's easy" Posted: Sep 22, 2005 12:05 PM
Reply to this message Reply
> In addition to all these excellent reasons, another one I
> see is a lack of respect for or ignorance about the degree
> of difficulty represented by software engineering. I see
> way too many developers believing writing software apps is
> easy - simply because writing code and making it "work" is
> easy. Unfortunately, this type of code writing has little
> to do with the task of software app creation and
> maintenance.
>
> So, developers write easy code, get it working, and think
> they've done an adequate job. The result is huge messes.

Indeed.

So, what do you think the cause of this is? Is it really as simple as not caring enough? Or, like drug dealers, do we get hooked because it's so easy and fun to get started and by the time that we realize that we're completely hooked it's too late to change?

What do you think we can do to fix the problem?

John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

Re: Rent seeking Posted: Sep 22, 2005 12:23 PM
Reply to this message Reply
> well, i did my college in Economics, and about the first
> day: Sunk costs are irrelevant to decision making.

Ah, gotta love those classical econ "laws". :-) For the record, I'm clearly of the behavioral school of economics.

> i've always supposed that, because it doesn't look
> physical and the marginal cost of production is near zero,
> code managers (those who "own" that 30 year old codebase)
> prefer to ignore this. most MBAs do (the Econ grad
> students and the MBA students didn't get along <G>). it's
> just too easy to burn another CD. they wish to "leverage
> the software investment". thus we see "web services"
> wrapping mainframe sequential file batch programs. no,
> i'm not kidding. the quintessential way to make sucky
> software.

I concur but I don't think that's anywhere near the whole story. For example, what about the perceived (and actual :-) risks of updating/rewriting those (presumably brittle) legacy batch programs? What are the (dis-)incentives on the managers to actually fix the problem?

> a homo economicus decision weighs future revenue against
> cost of investment. my sense is that the hoarders of
> these old codebases don't think they can do it again in a
> modern way; there are no second acts in life. they
> learned program development in a 60s or 70s context, and
> by gum that's how things should be. well, our competitors
> have GUI/database systems. i know, let's put an applet
> front-end on it. now we'll LOOK modern. that's the
> ticket.

But isn't it rational to, say, write emulators for those old mainframe platforms to run on the latest hardware instead of trying to extract all of the years of accumulated wisdom that's embodied in the old program? Isn't it more cost-effective to put a new dress on the old girl to impress the suits/analysts/whatever without having to risk e.g., losing a safe sinecure?

What I'm trying to get at is where's the crux, the chasm, across which we have to make a transformative decision rather than a status quo decision.

> even Windoze itself carries this kind of baggage: QDOS
> was a control program, which gave coders access to the
> hardware. early MS-DOS made its living on the ability of
> games to run really fast because of this. to call it an
> operating system was a stretch. that legacy continues to
> this day.
>
> eventually, someone does it right from scratch. rarely is
> this the owner of the existing codebase; it's just too
> easy to burn another CD. and anyway, a decent software
> salesman can sell anything if it has a GUI. <G>

So it's the old "bread and circuses" excuse? Okay but then how does that explain all of the crappy software for developers that's written by developers?

> so far as refactoring goes; in the cases i'm talking
> about, these are MF COBOL suites. not sure how one could
> refactor batch VSAM routines into event driven java. or
> if one should.

Indeed, I've been stuck in similar straightjackets.

> corporate software is about where the American auto makers
> were in the mid 1960s. the car folk were intent on
> "leveraging" their 40s and 50s "technology" in the 60s and
> 70s. then the Japanese and Europeans, whose technology
> had been bombed to non-existence and replaced, woodsheded
> 'em. US auto still hasn't recovered.

You optimist! I don't think I'm quite that generous. :-)

> there's lots of software from the 70s and 80s which is
> batch and file oriented. and a push to web-ify and gui-fy
> it all. so the code managers put lipstick on the pig.
> kind of like deciding to put bigger tail fins on, rather
> r than building a better car.
>
> summary: sucky (non-retail, corporate) code persists
> because much of it exists in islands of monopoly, code
> architected according to 60s and 70s paradigms, now being
> prettified, but that's all. cat food blended by bean
> counters, who may be making a rational (if short term)
> decision.

So, what do we need to add to the mix to help make e.g., rational decisions for the mid- and long-term?

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Why Software Sucks Posted: Sep 22, 2005 3:53 PM
Reply to this message Reply
Christopher Diggins Here's a question to ponder: if elevators and bridges mostly sucked wouldn't most of us be dead?

No. Re-read Scott Berkun article:

'What it means to say "this sucks"...

- I’m annoyed by this, but I don’t need it often
- This Sucks
- This is acceptable

... The point of this representation is that "this sucks" is right in the middle.'


The Millenium Bridge sway sucked but it didn't kill anyone.
http://www.galinsky.com/buildings/millenniumbridge/

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Why Software Sucks Posted: Sep 22, 2005 4:27 PM
Reply to this message Reply
We seem to be talking about Why Software is Bad rather than Scott Berkun's notion that "This Sucks" is somewhere just below acceptable.

afaict "Why software sucks" could mean "Why the software that sucks, sucks" and we only seem to be reading it as "Why most software sucks".

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Rent seeking Posted: Sep 22, 2005 5:00 PM
Reply to this message Reply
> I concur but I don't think that's anywhere near the whole
> story. For example, what about the perceived (and actual
> :-) risks of updating/rewriting those (presumably brittle)
> legacy batch programs?

first question: do we prefer to keep a [sequential|batch|procedural] process? if so, then stay with the COBOL. but you'll have a nasty impedence mis-match with the GUI. i'm up to my knees in that again. superficially, the demo shows a neat clickable, tabbed, check boxed, etc. interface. just like Word. what the users (cats) find out after the Suits buy the stuff is that it really isn't like Word at all. you have to do A then B then C. if you don't, you get some cryptic error. of course, the procedure is never written down, since to do so admits that it isn't like Word at all. it's still that nasty old Procedural Suite they used to have. then everybody gets irritated. what's worse (see Spolsky, et al), is that the GUI is not well suited to heads-down data entry, which much of corporate software really is. it shouldn't be like Word at all.

What are the (dis-)incentives on
> the managers to actually fix the problem?

the incentive is to be able to sell the WhizBang Software Suite for the next decade. but if WBS is already behind the technology curve, because they've been riding that rented mule for 20 years, they often choose to ride it into the ground.

> But isn't it rational to, say, write emulators for those
> old mainframe platforms to run on the latest hardware
> instead of trying to extract all of the years of
> accumulated wisdom that's embodied in the old program?

welllll, that leaves the paradigm mis-match still there. not much different from wrapping the MF COBOL with "web services". the real issue is paradigm shifts (or not): event vs. procedural, file vs. database. also, often that "accumulated wisdom" isn't very smart: this kind of software generally implements mission-critical process. lots of advances have been made, and embodied in new software. for example: inventoried vs. JIT manufacturing. the olde style software can't support JIT.

> Isn't it more cost-effective to put a new dress on the
> e old girl to impress the suits/analysts/whatever without
> having to risk e.g., losing a safe sinecure?

sure. sucks. if you're not on the profit sharing train.

>
> What I'm trying to get at is where's the crux, the chasm,
> across which we have to make a transformative decision
> rather than a status quo decision.

the future. does the software house (or in-house, for that matter) still want to be viable in 5 years. if not, grab the lipstick. M$ has been doing much the same thing with windoze for a llllllllong time. Excel stole 1-2-3. which stole VisiCalc. imagine the return on investment if Bricklin could have controlled all that!!!!!!!!!!!
> So it's the old "bread and circuses" excuse? Okay but
> then how does that explain all of the crappy software for
> developers that's written by developers?

well, the stuff i use isn't really crappy: SlickEdit, wincvs, cvsnt, and jswat. 3 are Open Source. i used M$ tools years ago.

> So, what do we need to add to the mix to help make e.g.,
> rational decisions for the mid- and long-term?

if *we* are the developers, then some way to prove to the Suits that there *is* a long-term. or find another start-up. all of this crappy software did get built for the first time, once. not all of it was crappy when it did something new and better. and the history of software isn't all that long. not like, oh, civil engineering. the 360 is 40 years old. IBM doesn't like to admit it, but the zSeries is not much different in architecture. and on purpose. in some ways, there's never been a long-term in the software business.

what happened before that doesn't much count. the two paradigm shifts since then: databases, GUI. the Web is retrograde so far as paradigms go: a disconnected block mode interface, that's CICS 1968. unix circa 1990 had character mode connected databases. very cool. edit on each key stroke against the database. except for the pixels, Web stuff is very old hat. the java kiddies don't know this, of course. they just see the pixels.

and so on. it's the Time Horizon. isn't that the edge of Black Holes?

John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

Re: Why Software Sucks Posted: Sep 22, 2005 5:31 PM
Reply to this message Reply
> We seem to be talking about Why Software is Bad
> rather than Scott Berkun's notion that "This Sucks" is
> somewhere just below acceptable.
>
> afaict "Why software sucks" could mean "Why the software
> that sucks, sucks" and we only seem to be reading it as
> "Why most software sucks".

For myself, I don't see any of those being at odds with one another. That's just defining spectrum of "suckage" (across various dimensions). Feel free to weigh in anywhere.

John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

Re: Rent seeking Posted: Sep 22, 2005 5:59 PM
Reply to this message Reply
> first question: do we prefer to keep a
> [sequential|batch|procedural] process? if so, then stay
> with the COBOL. but you'll have a nasty impedence
> mis-match with the GUI. i'm up to my knees in that again.
> superficially, the demo shows a neat clickable, tabbed,
> , check boxed, etc. interface. just like Word. what the
> users (cats) find out after the Suits buy the stuff is
> that it really isn't like Word at all. you have to do A
> then B then C. if you don't, you get some cryptic error.
> of course, the procedure is never written down, since to
> o do so admits that it isn't like Word at all. it's still
> that nasty old Procedural Suite they used to have. then
> everybody gets irritated. what's worse (see Spolsky, et
> al), is that the GUI is not well suited to heads-down data
> entry, which much of corporate software really is. it
> shouldn't be like Word at all.

So that example would seem to fall into e.g., the cat food problem, the expectation problem, the don't know what we're trying to solve problem, and the suckered by the shiny bauble problem.

If there's that many problems, how can we possibly hope to create even just decent sofware?

>> What are the (dis-)incentives on
>> the managers to actually fix the problem?
>
> the incentive is to be able to sell the WhizBang Software
> Suite for the next decade. but if WBS is already behind
> the technology curve, because they've been riding that
> rented mule for 20 years, they often choose to ride it
> into the ground.

So is that as much an issue of inertia as anything else?

> > But isn't it rational to, say, write emulators for those
> > old mainframe platforms to run on the latest hardware
> > instead of trying to extract all of the years of
> > accumulated wisdom that's embodied in the old program?
>
> welllll, that leaves the paradigm mis-match still there.
> not much different from wrapping the MF COBOL with "web
> b services". the real issue is paradigm shifts (or not):
> event vs. procedural, file vs. database. also, often that
> "accumulated wisdom" isn't very smart: this kind of
> software generally implements mission-critical process.
> lots of advances have been made, and embodied in new
> w software. for example: inventoried vs. JIT
> manufacturing. the olde style software can't support
> JIT.

I totally agree. Alas, IME, rather than seeing the opportunities, people use all of that as yet more excuses to stick their heads in the sand. I.e., their analyses are completely asymmetric: With the old product, they heavily inflate its goodness and discount its failings while with the potential new solutions they heavily discount the potential and inflate the actual risks. Alas, given how wretched most software sales pitches are, it's hard to fault them too much.

Also, this brings up the fear of change. I.e., in your example, isn't an underlying issue really the fact that the organization is so set in it's ways that it is unable to change? Perhaps, ala Blade Runner, we should build in termination dates for organizations?

> > What I'm trying to get at is where's the crux, the chasm,
> > across which we have to make a transformative decision
> > rather than a status quo decision.
>
> the future. does the software house (or in-house, for
> that matter) still want to be viable in 5 years. if not,
> grab the lipstick. M$ has been doing much the same thing
> with windoze for a llllllllong time. Excel stole 1-2-3.
> which stole VisiCalc. imagine the return on investment if
> Bricklin could have controlled all that!!!!!!!!!!!

Ah but what's the value of the marketing? Regardless of what we might think about the technological merits, MS changed the game in terms of marketing power.

> > So it's the old "bread and circuses" excuse? Okay but
> > then how does that explain all of the crappy software for
> > developers that's written by developers?
>
> well, the stuff i use isn't really crappy: SlickEdit,
> wincvs, cvsnt, and jswat. 3 are Open Source. i used M$
> tools years ago.

Hmm... Is that to say that suckage is relative?

I mean, really, CVS is a wretched mess of an SCM. JSwat is an interesting example to me personally since I spent a few years using the original Swat.

> > So, what do we need to add to the mix to help make e.g.,
> > rational decisions for the mid- and long-term?
>
> if *we* are the developers, then some way to prove to the
> Suits that there *is* a long-term. or find another
> start-up. all of this crappy software did get built for
> the first time, once. not all of it was crappy when it
> did something new and better. and the history of software
> isn't all that long. not like, oh, civil engineering.
> the 360 is 40 years old. IBM doesn't like to admit it,
> , but the zSeries is not much different in architecture.
> and on purpose. in some ways, there's never been a
> a long-term in the software business.

Indeed. So perhaps it's just a question of patience in terms of waiting for people to grow up? Perhaps but I figure I'll be dead long before that happens. :-)

> what happened before that doesn't much count. the two
> paradigm shifts since then: databases, GUI. the Web is
> retrograde so far as paradigms go: a disconnected block
> mode interface, that's CICS 1968. unix circa 1990 had
> character mode connected databases. very cool. edit on
> each key stroke against the database. except for the
> pixels, Web stuff is very old hat. the java kiddies don't
> know this, of course. they just see the pixels.
>
> and so on. it's the Time Horizon. isn't that the edge of
> Black Holes?

Indeed, it's been really funny watching the pendulum swing back and forth. All of the hoopla over "AJAX" is just unbelievable to me.

Do you think anything technological is really helping this problem? For example, is the shifting view of programmers due to unit testing actually helping people think better?

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Why Software Sucks Posted: Sep 22, 2005 6:39 PM
Reply to this message Reply
John For myself, I don't see any of those being at odds with one another. That's just defining spectrum of "suckage" (across various dimensions).

So it's just another lament on the state of the software industry?
Scott Berkun seems to have been writing about something more partcular.

John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

Re: Why Software Sucks Posted: Sep 22, 2005 6:48 PM
Reply to this message Reply
> So it's just another lament on the state of the software
> industry?

Of course not.

> Scott Berkun seems to have been writing about something
> more partcular.

Check out the myriad questions that I've asked in the various postings in this thread (including my original). That would seem like a good place to start.

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: Why Software Sucks Posted: Sep 22, 2005 7:02 PM
Reply to this message Reply
Why does software suck?

Because it can.

John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

Chickens? Roads? Posted: Sep 22, 2005 7:45 PM
Reply to this message Reply
> Why does software suck?
>
> Because it can.

Mu.

Howard Lovatt

Posts: 321
Nickname: hlovatt
Registered: Mar, 2003

Re: Why Software Sucks Posted: Sep 22, 2005 8:07 PM
Reply to this message Reply
> Why does software suck?
>
> Because it can.

I agree with this comment, so the question is how do we stop it? How about this: when I buy software from company X and the software fails I can ask X to pay for my time that their software wasted. This is similar to the principle of what happens if you build a bridge and it fails, you are publically liable!

John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

Liability Posted: Sep 22, 2005 9:08 PM
Reply to this message Reply
> I agree with this comment, so the question is how do we
> stop it? How about this: when I buy software from company
> X and the software fails I can ask X to pay for my time
> that their software wasted. This is similar to the
> principle of what happens if you build a bridge and it
> fails, you are publically liable!

So, who's going to decide what "failure" means? What does "wasted" really mean? How is the line going to be drawn in terms of all of the gray areas?

The government? Which one? Heck, they can't even run a patent office.

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Rent seeking Posted: Sep 22, 2005 9:54 PM
Reply to this message Reply
> Do you think anything technological is really helping this
> problem?

yes. and java is to be thanked, oddly. i've generally been opposed to code generation, on the assertion that if the abstraction level of the language isn't high enough, then you should be using a different language. python and Ruby on Rails come to mind.

but then i got to thinking. my java colleagues were using XML (from the SMEs via an XML editor) as input to make lots o lots o java. being a database wonk from wayback, i wasn't convinced that this was making things better. their exercise was lipstick oriented and drove the database from the naive view of data as is the wont of SMEs.

but wait, what if one starts with a database schema (3NF or BCNF) instead? *all* of the constraints on the data are *explicit* in this schema. so long as the database is SQL-92 compliant or better, it's all recorded as readable text in the catalog (or whatever term your DB uses) tables. well, now you can generate the mid-tier stuff, if that's what you're doing, and the UI stuff too. everything you need to enforce is already defined. neat.

so, being lazy, and having Cubeland Suits unwilling to spend the time and $$ to roll it, i went looking. turns out there is a movement afoot. Google for 'database driven development'. it already exists. the most complete seems to be Firestorm/DAO. it's java, but who cares? middlegen is the most advanced OS attempt i could find.

now, for those saddled with flat file databases from days of yore, getting a clean database schema might not be in cards for the reasons already discussed. but for those who have a clean sheet, give it serious thought. not only do you get structure, but also sharable data. just what Dr. Codd had in mind.

For example, is the shifting view of programmers
> due to unit testing actually helping people think better?

no.

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