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 ]
Scott Berkun

Posts: 3
Nickname: berkun
Registered: Sep, 2005

Re: Why Software Sucks Posted: Sep 27, 2005 8:16 AM
Reply to this message Reply
Advertisement
> 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 ecome
> normalized?

Some people certainly are. Watch people at the supermarket - you'll see plenty of people buying the middle of the road quality, despite shopping from shelves that have high end and low end goods.

I think satisfication with mediocre things depends on: the person, the situation and the need. There's also a relativity issue: the mediocre brand of toliet paper in a U.S. supermarket might be of a higher grade than what you'll find in a 3rd world country. At some point a product becomes so mature that what's mediocre is actually well beyond what most people need.

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

Your goal is better - but my goal in the essay was just to lay out some markers. I still think it's true that suckage is relative to the individual, so even great things from my point of view will be seen to suck by someone with different expectations.

Scott Berkun

Posts: 3
Nickname: berkun
Registered: Sep, 2005

Re: Why Software Sucks Posted: Sep 27, 2005 8:35 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.

Fair enough - Feel free to substitute better examples of quality goods. My point wasn't specific to Apple, BMW, or Rolex - I was just using them as examples to make a point about quality and popularity. Arguably high quality but lesser known brands than these makes my point equally well.

John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

Re: DB-or-bust Posted: Sep 27, 2005 10:14 AM
Reply to this message Reply
> 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.

Ah, thanks for the clarification.


I was just reminded of Martin Fowler's entry on "Database Styles": http://martinfowler.com/bliki/DatabaseStyles.html.

John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

Context matters Posted: Sep 27, 2005 10:30 AM
Reply to this message Reply
> > 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 ecome
> > normalized?
>
> Some people certainly are. Watch people at the supermarket
> - you'll see plenty of people buying the middle of the
> road quality, despite shopping from shelves that have high
> end and low end goods.

I hear ya. However, to be clear, that's not the same as "happy". Most of the stuff that most of "us" (i.e., the middle class) buy most of the time falls into the big fat middle where habit is the primary driver (followed (closely) by price and then everything else).


> I think satisfication with mediocre things depends on: the
> person, the situation and the need. There's also a
> relativity issue: the mediocre brand of toliet paper in a
> U.S. supermarket might be of a higher grade than what
> you'll find in a 3rd world country. At some point a
> product becomes so mature that what's mediocre is actually
> well beyond what most people need.

I totally concur.

> > 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.
>
> Your goal is better - but my goal in the essay was just to
> lay out some markers.

Got it, no worries. My goal has been to poke a bit deeper. :-)

> I still think it's true that suckage
> is relative to the individual, so even great things from
> my point of view will be seen to suck by someone with
> different expectations.

Hmm... How much of the notion of suckage is built on opinion vs. actual, objective, qualitative reality? I.e., I understand that e.g., beauty is in the eye of the beholder but there are certainly layers for which there's pretty solid footing to make fairly objective judgements.

Basically, I think part of the conflict in the whole discussion of suckage is that there's too much conflation of the "opinion" from the "facts" that's exacerbated by the presumptions of context.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Why Software Sucks Posted: Sep 27, 2005 8:49 PM
Reply to this message Reply
Wow, what a popular exchange :-)

The biggest parallel I see, is the hardware world. In the hardware world, developers have standards such as voltage, current and in the analog/RF world, impedence. When the design hardware, there are a handful of interworking compatibility issues to deal with.

In the software world, we make up the incompatibilities at will. We can't make our software work together because it has a constraint that no other software can meet.

The Web Services programming mantra, where everything speaks XML over a handful of protocols, seems to me, to be an attempt (deliberate or not) at creating a BUS like mechanism for coupling software things together. The problem is that all things don't speak this protocol/interface either. So, we are trying really hard to put facades on everything old so that it looks like the new.

The problem with XML is that we are creating a protocol over the interface, with each such coupled piece of software. That software is designed and implemented to speak the protocol, so it's like a chip, but it has limited use. It has to speak to things very much like the things on the other end.

I think we're building, larger, more complex things than we need which create tons of couplings. All of this is because it is more expensive to create small things. Now, the EJB and other similar container models are attempts at making it easier to create small things to solve specific problems. The problem is that there's a very limited set of intefaces and protocols that an EJB "device" can see. Thus, it can't be used for just anything. It usually can only talk to a database, or be a piece of a web service. It can't be a simple desktop component that maps the size of all the files on your desk. It can't be a web browser plug-in that finds, via google, web pages like the one you are looking at.

The JVM is a very generic container, as is the smalltalk environment, the LISP environment etc. These all let us develop really small and really large pieces of software to solve specific problems. However, these environments/virtual machines have a tremendous mismatch and thus a smalltalk IDE can't run my Java program that I am developing. The LISP runtime, doesn't let me write some functions in Java because they are more procedural and less recursive in nature.

The internet is another BUS that we've all gotten used to use for some very focused applications such as web browsing, email, instant messaging etc. But, underneath, all of these applications share the same ability. They take something off the bus, or put something on the bus, and it gets used on the other side.

The reason that the data can be used on the other side is because there is a very specific expectation for the use. There are protocols and specification which create very focused uses of the data (well, the web browser is getting muddier day by day).

In some of the earlier discussion, the suck factor was linked to mismatches in expectations and knowledge. The whole MS-Word argument is amazing. MS-Word is the best because it fulfills requirements which are undocumented, and somewhat intractable to describe. It sets a standard that is unobtainable, because there is no specification of what needs to be achieved. Look at what MS has done with HTML over the years. It constantly submits changes and updates to the specification that meet the abilities of its browser in an attempt to standardize, but stay ahead in the game.

What we need to do, is decide "The network is the computer" and move on. We should do this because it requires protocols to be documented and interfaces to be confining. This helps manage the expectation and the knowledge gap so that everything is well known.

If we could get IPV6 in place, then every object that we create could be a service with a specific IP address. We could find it anywhere in the world and reuse it over and over. Okay, I know that sounds far fetched. But, there are some things that would definately improve.

The notion of lookup services such as those provided by many different platforms provide registration for each of the associated platforms. But, those registrations are invisible to others. We need standards and we need specs and limiting, controlling interfaces. Then, we can design software using tools instead of a paint brush. This would move us more towards a hardware model and way, far away from the artist model.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Why Software Sucks Posted: Sep 27, 2005 11:15 PM
Reply to this message Reply
http://news.bbc.co.uk/1/hi/technology/4286294.stm

Dave Nicolette

Posts: 6
Nickname: dnicolet
Registered: Sep, 2005

Re: Why Software Sucks Posted: Sep 28, 2005 6:32 AM
Reply to this message Reply
I think the comments that compare hardware components with software components are onto something. Throughout my career, which goes back to the 1970s, I've seen people trying to make software development work the same way as a manufacturing process. A few years ago there was a big push for service oriented architectures. That was probably the most comprehensive attempt to date. I suspect one of the reasons software sucks is that there is a prevailing belief in the idea that it ought to be possible to produce software products on an assembly line basis, just like hardware components.

But hardware and software are fundamentally different. For one thing, there's no reuse of a hardware component; you can only install a light bulb in one socket. That's why there have to be many, many copies of the same item. What you're actually reusing is the design of the component. One level of abstraction higher than that, you're reusing its interface spec; you can substitute a different type of lightbulb, as long as it fits into a standard socket.

With software, you can reuse a component by copying it. You don't need to manufacture millions of copies. One copy is sufficient because it's so easy to duplicate it as needed. A manufacturing process works when you need to make many identical copies of a product. With software, you only "make" one when it has to be different; you don't "make" many copies of the same thing.

Another key difference is that no two software solutions are identical. Even if you're talking about a well-defined niche - say, checking account management for a bank - each solution for each bank has a certain amount of custom functionality. Some off-the-shelf components may be used, but there will also be a need for custom development. The key reusable thing is the interface spec. By following standards for interfaces, we enable developers to integrate whatever components make sense for their solution, knowing they will also have to do some custom development to complete the product. So there's nothing wrong with stopping the quest for reusability at the level of standard interfaces. That is the appropriate level for software products.

One reason software sucks may be that the manufacturing metaphor never really applied to software development in the first place. Past attempts to control quality through manufacturing-oriented techniques like TQM, kaizen, and Six Sigma fail to reduce software suckiness because they are solutions to a different problem.

Was it Einstein who defined "insanity" as repeating the same action over and over and expecting a different result? We've been crazy for a long time, now. Is it any wonder our stuff sucks?

A better metaphor for software development might be the construction industry. Construction projects have a lot in common with software development projects. We've already adopted some practices from the construction industry - design patterns, adaptive methodologies, etc. Yet we continue to view the overall "art" as a kind of manufacturing activity. <a href="http://www.cee.umd.edu/laufer.html">Alexander Laufer</a> wrote <a href="http://www.pmforum.org/library/cases/cases05-0506.htm">an article</a> about his findings for the Construction Industry Institute about why construction projects fail. Don't you see many parallels there with our work?

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: "That's easy" Posted: Sep 29, 2005 2:09 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.

Whilst there are many possible ways in which software production may be improved, Michael has hit on what is probably the biggest hurdle to implementing any of them. The quality of the code turned out by the 'average' programmer is bloody awful (and as many as half of all programmers could be described of being below avaerage).

I've just come away from a discussion with an experienced programmer who was being overwhelmed as he attempted to iterate through an ever expanding massive multi-dimensional array (Excel VBA of all things). One dimension represented courses, one was lecturers, one rooms, one equipment, one clients, etc. I think I've convinced him that defining everything in self contained collections of objects that handle only things they are responsible for but he's taking some persuading that many objects are actually simpler than a single array.

Of course a simpler solution still is to use a 'proper' database and a 'proper' coding language but I think it shows the very basic level at which the true 'suckage' problem lies.

Flat View: This topic has 67 replies on 5 pages [ « | 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