The Artima Developer Community
Sponsored Link

Weblogs Forum
Why Software Sucks

67 replies on 5 pages. Most recent reply: Sep 29, 2005 2: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 | » ]
Howard Lovatt

Posts: 321
Nickname: hlovatt
Registered: Mar, 2003

Re: Liability Posted: Sep 22, 2005 7:16 PM
Reply to this message Reply
Advertisement
> 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.

Like evrything else in a democracy the courts would ultimately decide the gray areas. Perhaps all is needed is a little stronger consumer laws that don't allow software companies to disclaim responsibility for the bugs and subsequent losses. I don't see this as much different than the automobile industry which used to have reliability problems until lemon laws were passed. I think once there is a liability then people will start to make sure the product does as advertised.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: Rent seeking Posted: Sep 22, 2005 7:25 PM
Reply to this message Reply
> 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.

I coined Blanchard's Law to describe this phenomenon. Totally agree.

> 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.

NextStep had this with Enterprise Objects Framework (EOF) which was absorbed into WebObjects. The DirectToWeb tool does this and gives you vanilla CRUD apps that are very boring but functional. Still, it turns out that users don't edit tables, they perform tasks and a single task may create many records. IOW, there's not a clean mechanical mapping from ER model and constraints to business process.

See http://developer.apple.com/documentation/WebObjects/Developing_With_D2W/index.html

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: Why Software Sucks Posted: Sep 22, 2005 7:43 PM
Reply to this message Reply
Alan Kay summed it up nicely in his talk <a href="http://www.openp2p.com/pub/a/p2p/2003/04/03/alan_kay.html">"Daddy Are We There Yet?"</a>

I think a lot of our problem is we are not learning from our past. Not enough attention is payed to our history and we keep re-solving the same problems over and over again. Each new programming language slavishly steals from the last one, frequently repeating the same design errors over and over again. The most recent example is Java's evolution which closely parallels that of C++. Is this really the best we can do?

In my opinion, Lisp machines and Smalltalk VMs reached the pinnacle of what software systems could be in terms of flexibility and interactivity. Nothing has equaled them and they were mature technologies over 25 years ago. Back then the hardware struggled. Now we have cycles to burn. Perhaps we should revisit the concepts. Heck, most practicing programmers today know C++, Java, maybe Perl. Their imaginations are bounded by the capabilities of these languages and it shows.

The code we build these days is too rigid and hard to reuse. Minor interface differences result in endless riffs on the same couple themes.

Recent discussions of memory management strategies in these fora underscore my point. Memory management and garbage collection is a solved problem. Lets move on and figure out how to build a system that will let people make things by adapting components casually. We need to move beyond "programming" to systems that support dynamic assembly of components.

Unix provided a literate environment with a common data structure (lists and streams) that enabled end users to endlessly recompose units of capabilities (programs like tr, sort, grep, find) to perform ad hoc computation. It was a powerful start, but we can do better.

Software sucks because we are still writing programs and not building systems for users to assemble their own tools.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: How have you make software less sucky, today? Posted: Sep 23, 2005 12:07 AM
Reply to this message Reply
> To be clear, I think that software suckage is a (set of)
> choices. For a lot of reasons, we as individuals,
> organizations, communities, industries, etc. choose to
> support, make, use, buy, condone, incite, etc. sucky
> software.

I do agree. It is part of a complex problem but look through the answers here and you'll see that the majority of answers, however eloquent, can basically be summed up by the phrase "blame everyone else for the quality of the software that we produce. Go down that road and the problem will never be resolved.

The production of serious software does involve a chain of people and decisions, many of which are out of our control. Nevertheless, no one else writes the software, we do. No one else maintains the software, we do. Therefore, no one else is responsible for the quality (or lack thereof) of said software, we are.

Impractical answers that try to pin the blame on 'suits', 'buyers', 'managers' or 'Microsoft' just aren't worth the paper they're written on.

Vince.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Why Software Sucks Posted: Sep 23, 2005 12:08 AM
Reply to this message Reply
Here's a topical artical from the BBC:

http://news.bbc.co.uk/1/hi/technology/4272382.stm

Note particularly the last paragraph.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Why Software Sucks Posted: Sep 23, 2005 12:10 AM
Reply to this message Reply
> artical

Hoist by my own petard!

Steve Donovan

Posts: 24
Nickname: stevedonov
Registered: May, 2005

Re: Why Software Sucks Posted: Sep 23, 2005 5:15 AM
Reply to this message Reply
The article was a good attempt to be more precise about suckage. User psychology is still full of mysteries ;)

About the cat-food theme; it's important to have people eating their own cat-food. For instance, it would show bad faith for developers of an IDE not to be using their own IDE. And that's why QA remains important; people who are paid to eat the cat food, who work down the hall, and can translate 'this software sucks' into terms understandable by programmers. In my experience, programmers make poor users.

steve d.

Michael Stover

Posts: 28
Nickname: mstover
Registered: Jul, 2005

Re: "That's easy" Posted: Sep 23, 2005 6:53 AM
Reply to this message Reply
> 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?

In my experience, the vast majority of developers are so ignorant of the difference between good code and bad, that it becomes impossible to have a meaningful discussion with them about their design choices. The most basic OO design techniques become huge discussions about whether or not it's really a good idea to, for example, separate an <i>Address</i> object out from the <i>Person</i> object.

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

Find an employer who knows the difference between good programmers and bad and convince them to hire you. Sadly, I'm in a small market, and it doesn't appear any such employers are in my area.

John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

Re: How have you make software less sucky, today? Posted: Sep 23, 2005 7:43 AM
Reply to this message Reply
> The production of serious software does involve a chain of
> people and decisions, many of which are out of our
> control. Nevertheless, no one else writes the software,
> we do. No one else maintains the software, we do.
> Therefore, no one else is responsible for the quality (or
> r lack thereof) of said software, we are.

We are (part of) the consumers and buyers, too. Hence why I question a lot of the arguments that are predicated on simplistic notions of responsibility.

I totally concur that, regardless of the systemic issues, each individual is, of course, responsible for their own choices and actions.

John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

Education? Posted: Sep 23, 2005 7:48 AM
Reply to this message Reply
> In my experience, the vast majority of developers are so
> ignorant of the difference between good code and bad, that
> it becomes impossible to have a meaningful discussion with
> them about their design choices. The most basic OO design
> techniques become huge discussions about whether or not
> it's really a good idea to, for example, separate an
> <i>Address</i> object out from the <i>Person</i> object.

Two things...

First, does that imply that's it's primarily an education issue? I.e., that we need to educate, train, mentor, coach, etc. individuals and organizations to the real costs and benefits?

Second, doesn't that still just come down to a question of whether or not people/organizations care enough? I.e., like addicts, it's nearly impossible to make any substantive changes until the addict at least realiizes that they are an addict?

John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

Re: Liability Posted: Sep 23, 2005 7:57 AM
Reply to this message Reply
> > The government? Which one? Heck, they can't even run a
> > patent office.
>
> Like evrything else in a democracy the courts would
> ultimately decide the gray areas. Perhaps all is needed is
> a little stronger consumer laws that don't allow software
> companies to disclaim responsibility for the bugs and
> subsequent losses. I don't see this as much different than
> the automobile industry which used to have reliability
> problems until lemon laws were passed. I think once there
> is a liability then people will start to make sure the
> product does as advertised.

So, from that I must take it that you think that the various programmer "certifications" actually correlate to better software? How does that jibe with the reality that there's almost no correlation? For organizational "certifications", have you actually looked at the joke that are things like CMM(i) certifications both domestically and internationally? For example, have you actually had to deal with code created by e.g. "CMM(i) level 5 certified" organizations? They are a dime a dozen in e.g., India and the software is uniformly, utterly wretched.

So, how is some extra-industry entity such as the government going to possibly deal with the complexity of software relationships? Seriously, I'd love to hear the details of how that could possibly work.

John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

Indirection sucks? Posted: Sep 23, 2005 8:07 AM
Reply to this message Reply
> About the cat-food theme; it's important to have people
> eating their own cat-food. For instance, it would show
> bad faith for developers of an IDE not to be using their
> own IDE. And that's why QA remains important; people who
> are paid to eat the cat food, who work down the hall, and
> can translate 'this software sucks' into terms
> understandable by programmers. In my experience,
> programmers make poor users.

Is this another side to the cat food problem: there needs to be enough indirection (insulation/translation/specialization/etc.)? Or is it perhaps another example of programmers caring about different things than "normal" users?

John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

ITLS! Posted: Sep 23, 2005 8:12 AM
Reply to this message Reply
> http://news.bbc.co.uk/1/hi/technology/4272382.stm
>
> Note particularly the last paragraph.

I strongly concur that language is a crux to this problem:
http://www.artima.com/weblogs/viewpost.jsp?thread=81574
http://www.artima.com/weblogs/viewpost.jsp?thread=84070
http://www.artima.com/weblogs/viewpost.jsp?thread=106031

John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

Dichotomy purgatory? Posted: Sep 23, 2005 8:27 AM
Reply to this message Reply
> 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.

Indeed, it's all about the languages.

> 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
> e database from the naive view of data as is the wont of
> SMEs.

So is the underlying problem this artificial dichotomy of code vs. data? I.e., the other extreme of data is everything, code is nothing is just as stupid so there must be some transcedent option(s).

> 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.

Hmm...

(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.

(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.


>> 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?

nes

Posts: 137
Nickname: nn
Registered: Jul, 2004

Re: Why Software Sucks Posted: Sep 23, 2005 12:15 PM
Reply to this message Reply
Nah, the biggest problem is customer expectation. If you know what the client wants and what he does not want, you can make something he likes. If you have to acomodate for a common denominator, it will suck to varying degree for the users of it. If you write shrink wrapped software your software will suck by definition for certain number of your customers. If you can write software for yourself that you enjoy using but can not do it for others then the problem is that you do not understand what they want (a lot of desktop software falls under that category).

Of course many times the customer of the softare does not know what he wants either until he had to use the software for a few months. Worse at the begining he probably wanted fancy menues, but now that he is an expert he wants shortcuts to be able to work faster. This is why open source software works well. When the programmer is a customer of his software he figures out what is usefull for him. It usually ends up being software that works well for advanced users only (the programmer has wrestled with the problem for some time already so he is usually an advanced user himself).

Of course software that crashes in obvious ways sucks for everybody (video card drivers come to mind), but this has more to do with the complexity of the problem and lack of standards, skills and tools to manage them.

The laws of physics relevant to bridges and elevators do not change when moving from New York to Los Angeles, neither do they change every 3 months. No such thing comforts the software engineer. Each platform has its own ways of doing things and there are too many of them. Worse yet: there is no documentation because of trade secrets OR the documentation does not match reality. The software engineer ends up being the physicist trying empirically to determine the effects of the "ecosystem" on his software, and that every time a new "version" of some component of the ecosystem comes out. Constants aren't, and you can complain to other vendors until you are red in your face about non compliant products, you are to blame. The customer does not care that some .dll from his webcam sometimes causes your software to crash. As far as he is concerned your software "sucks".

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-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use