If Bad Software Developers Built Houses... 578
Richo99 writes "The editor at UI Hall of Shame takes us for a walk through a house designed by bad software developers. It appears Ed is getting a bit tired of really bad software designs in popular shareware titles. It is interesting because how much of a crime these apps perpetrate isn't obvious until you apply the same logic to everyday things, like the design of a house. I especially love the access to the garden. "
His blog follows a flawed design... (Score:5, Insightful)
Perhaps this gentleman should present us with a GOOD DESIGN isntead of just complaining about BAD DESIGN.
His blog is poorly designed.
I had a nice eloquent post all written. I hit the "Say It!" button (There is no 'Preview'), and I get to the next page. The next page complains that I forgot to add my email address, so I click 'back', and I'm presented with a BLANK FORM. Everything I wrote was lost, probably because of some wacky Javascript used in his blog form.
I feel like I entered a bathroom that's 5 feet wide and 100 feet long with a TV at the end.
I love his design!
Re:And the heating system (Score:5, Insightful)
ISO 9002 (Score:2, Insightful)
Availability? (Score:3, Insightful)
If the owners of this site built a house, it would only allow one person in at a time. The door would remain locked until they left.
Re:If builders built buildings.... (Score:4, Insightful)
Well thats the problem with a lot of programmers, they write instead of building software. Lashing code into an editor is not substitute for a little though and a solid development process.
Software is much more complicated (Score:1, Insightful)
The problem of designing a house is, by and large, a solved problem. Sure, there are requirements like soil structures, energy efficiency, and building codes, but by and large a given house has few if any "new" problems, and the combination of problems to solve isn't huge.
Designing software is much more complex and a software designer or team is likely to have at least one, if not many, problems that have never been solved before.
A better comparison would be designing a city, or perhaps a high-rise office building or manufacturing plant, and even that only compares with modest-sized software projects.
After all, most houses have only one architect for the overall design and a handful of specialists designing subsystems like the electrical layout. Most modern good-sized software projects have a lot more people contributing to the overall design.
The problem in a nutshell is (Score:5, Insightful)
They are brick layers and the guys who put in the pipes.
Imagine a house, built without a design as brick layers and guys who lay piples making it up as they go along.
Yeah, but... (Score:5, Insightful)
Not to excuse poor design, but sometime's it's easier to piss on stuff than figure out how to fix it.
Re:His blog follows a flawed design... (Score:3, Insightful)
Anyway, due to experiences like that where someone's lack of intelligible design cost me time that it shouldn't have (for god's sake, write your own makefiles!!!) that I become so.....irate when I have to deal with someone else's poorly designed code. I take those painful experiences in mind when I design my own code now though.
As someone who builds houses and software (Score:5, Insightful)
Building houses: Very detailed specifications with standards that have been honed over 30-40 years (family business).
Software dev: Requirements that are never actually pinned down.
Building houses: Sub-contractors that get paid based on the job, if they fuck up they fix it for free (or lose a valuable account).
Software dev: If it's broke/bug ridden fees are still paid to develop fixes (unless support built into contract which means you're paying more up front in case there are mistakes).
Building houses: Customers understand that if they change their mind when the home is in development the cost gets exponentially bigger as the house nears completion. We get bids for change orders and they sign ammendments to their contract approving changes and paying in advance for said changes.
Software dev: Frequently missed requirements necessitate changes in whole sections of code or UI design.
If software development weren't so fluid/dynamic it would probably be much like building houses. However a house hasn't changed that much since the 1950's for the most part where computers & software development were happy to be using punch cards. Plus I wouldn't wish city inspectors on anyone in the software industry. Those who can do, those who can't work for the city and are pissed off about it. I love watching city implemented projects with these so called "experienced engineers" who fuck up and have cost overruns on every project they do. It's a good thing city engineers don't have to make a profit or they'd be out on their asses.
Re:And the heating system (Score:3, Insightful)
In that case, maybe you shouldn't be reading articles that are posted on the internet. Go back to the print media, where they have editors.
Re:Jef Raskin spoke of such things YEARS ago! (Score:5, Insightful)
Easy to say. The only truly intuitive interface is the nipple.
Convention leads to consistency leads to familiarity, which is not not the same thing as intuitiveness. Apple understood this--that's really why the platform works, not because it taps some Jungian archetype of computerness.
It also leads to stagnation, inertia, inefficiencies writ in stone, and claims of mindless copying.
There are more intuitive and less intuitive interfaces. There are ways to design so as to stay out of the way of the user, or hinder it. But nothing is flat-out, absolute, nonrelative, intuitive.
No one teaches good coding (Score:1, Insightful)
Re:Yeah, but... (Score:4, Insightful)
Part of the problem is ... (Score:3, Insightful)
What's cobbled together rarely does the job except it can usualy be faked into something that looks adequate, right until a changed requirement when the whole thing gets tossed into the trash (it was collapsing into it anyway.)
I find most (hell, almost all,) 'soit-disant' design is missing the basics of software construction principles.
That we seem unable to do any better, regardless of how often we get burnt, is just WRONG!
What ever happened to post-implementation reviews? No wonder we seem to be unable to learn anything.
Re:Yeah, but... (Score:5, Insightful)
If you were building a house, no-one would come and say that you need to add one more floor that is twice as wide between floors 2 and 3 when you are already making the roof. Oh and it's done in two weeks, right?
Re:The problem in a nutshell is (Score:3, Insightful)
They are brick layers and the guys who put in the pipes.
Imagine a house, built without a design as brick layers and guys who lay piples making it up as they go along.
A friend of mine just built a new house, and he compared his old & new... His old house was nothing special, it looked just like the house right next to it, but the architecture made sense: Perfect example: everything that used water (toilets, kitchen, laundry) were located horizontally near each other, so that the plumbing would be nice and simple. In the new house, nothing was near each other, there's probably 100 feet of plumbing (in each direction) in there. I asked "what if this room were flipped the other way around?", and he shrugged, he didn't care either way. With the floorplan he had, simply switching it around so that the toilet is on the left side of the room instead of on the right, would have saved something like 20 feet of plumbing, and wouldn't have changed the rest of the floorplan.
Additionally, there were other things that weren't "quite right" with the construction: One wall didn't have enough support and it wobbles, a column doesn't line up exactly with the thing it is supporting, stuff like that. So what did the people who lay bricks and pipes do? Probably the same thing we do when a project manager gives us requirements that don't make a lot of sense: Grumble about the idiot that design this thing, it'd be a lot better if you simplified it this way, and then do it anyway, because the decision's been made, the higher-ups have spoken!
If houses were designed by the same people who design the requirements for software, you'd end up with.... exactly the same thing: Something that looks nice, but would be better designed & better built if they let people who know how to build these things have some say in the design.
Re:And the heating system (Score:5, Insightful)
But I *will* point fingers at developers for bad design, too. In the same company I have worked with developers who code up something that neither does what it should, is usable by anyone but them, or can be gracefully fit into the existing programming model. Too often they were called a "temporary fix" for the current release, to be fixed in a future release. It never was, it just became more encrusted with shims, helper libraries, and other complexification / bogger-downers.
Same goes for UI designed by developers. *UNLESS* you have spent time with the end users seeing what it is they are trying to do, you are not going to hit the mark by coding UI in your cubicle on the mistaken assumption that you know the best way to do something.
I have seen this happen so many times. I take a developer to a customer site to help diagnose a problem. After only ten minutes, the light comes on in the developer's head and a new solution is created that works, works well, and does what the customer wants and expects. Yet most development happens in reverse: cook up an idea, code it, then see if anyone likes it.
There's a lot of bad software project management out there, and there is enough blame to go around.
Re:Already slow; Full Text of Article: (Score:5, Insightful)
Apples and oranges (Score:4, Insightful)
Who builds shareware houses? You want to compare, at least compare commercial software, and in that case, commercial software that's not cheap. Otherwise, think about shanty towns for your homes and then start doing the comparison.
You get stuff cheap, you should expect to get what you pay for.
On top of which, Software Engineering is a misnomer. It's not engineering. It's not even a science. It's more an art at this point with some aspects of engineering and science.
Once we have automated tools that can verify a program as bug free (doubt that'll happen in my lifetime), then maybe it can become an engineering discipline.
With the assumption that your materials are within tolerances (and this can be determined for many), most engineering disciplines have very verifiable results. You can verify with mathematics that a bridge or building won't collapse, assuming your materials are verifiable. You can't do the equivalent with software.
The same goes for most other engineering disciplines. So the comparisons are invalid for a few reasons. But hey, I'm behind him on what he wants: Better UI design all around.
My manager was telling me yesterday about an resume he received from a UI designer. The resume was in 7pt type and my manager could barely read it.
Re:His blog follows a flawed design... (Score:3, Insightful)
Re:Yeah, but... (Score:5, Insightful)
Here in Boston, one of the fun bits of history is that in 1631, what may have been the first fire ordinance was passed. Among other things, it outlawed wooden chimneys.
Think about it. There was a reason that they decided to ban wooden chimneys. It wasn't done out of silliness.
Sometimes I think of this when I see an especially goofy mis-design in some software. I'm also reminded of it by a lot of the anti-regulation rhetoric in this and other forums.
Re:Yeah, but... (Score:4, Insightful)
Software on the other hand, is much more likely to be unique. Nobody requests a word processor to be made for them, they just go out and buy (or "borrow") a copy of Word. Most software development is largely unique, so there are naturally going to be more problems, delays and cost overruns. This is just one reason why software projects tend to be much harder to manage than other projects such as buildings.
That's right, pin it on the developers. (Score:5, Insightful)
If houses were built like programs are written, it would be a bit more like this...
Client: Build me a house.
Developer: What kind of house do you want?
Client: Oh, the usual. Bedroom, bathroom, kitchen, living room, that sort of thing.
Developer: Can you be a bit more specific than that?
Client: More specific? I gave you all the information you need.
Developer: *shrug* Okay, we'll see what we can do.
Some months later, a small, nondescript, sturdy house is built. It has a kitchen, a bedroom, a bathroom, and a living room. It lacks certain conveniences like air conditioning and a laundry chute, but the client didn't ask for them and didn't pay for them.
Client: Looks okay so far, but where's the laundry chute?
Developer: You didn't ask for one, and we assumed you wanted to keep things simple so you could save money.
Client: You should have anticipated our needs and put one in anyway. Either way, we need you to add one. Oh, and we'd like you to put on a second story. Some more bedrooms, another bathroom, the usual.
Developer: A second floor? The foundation wasn't built to handle that. We may have to change the layout a bit so we can add some addition support to the house. Oh, and there's nowhere to put the laundry chute, so we'll have to maybe bring it down through a closet or something. It'll waste some space, but that's the only way we can do it.
Client: That's fine.
A couple months pass. A second floor is added onto the house, and support beams are put up all over the place, making the place kind of difficult to navigate. A laundry chute is run down through the front closet, using up about half the space inside it and rendering it basically useless.
Client: Well... it's okay so far, but now that we think about it, we'd like to *live* in the basement and do our laundry upstairs. Can you possibly make it so the laundry chute will suck the clothes up through it into the upstairs laundry room? Oh, we'd also like you to put another bedroom on the second floor!
Developer: But there's nothing underneath where the bedroom would go! We'd have to--
Client: Do it! Why wasn't this done months ago? Also, this whole place looks horrible, and I can't even walk around downstairs without running into a support beam. And what kind of idiot assumes [yada yada yada etc]
So, whiny clients, if you can't give us *exact specifications*, then you have to learn to deal with messy software, or be understanding when things have to be restarted from scratch. We can build you the house you want, but that's no help unless we know what it is you want.
Re:Yeah, but... (Score:2, Insightful)
Re:That's right, pin it on the developers. (Score:2, Insightful)
So, whiny clients, if you can't give us *exact specifications*, then you have to learn to deal with messy software, or be understanding when things have to be restarted from scratch. We can build you the house you want, but that's no help unless we know what it is you want.
More specifically, they should know what they want.
Re:That's right, pin it on the developers. (Score:3, Insightful)
Reason we don't do this is because it's no the fun part. It takes the cowboy out of coding.
Re:The problem in a nutshell is (Score:3, Insightful)
They are brick layers and the guys who put in the pipes.
This site has been around for years, and I have to say I've never found it very useful or insightful.
If you want to know why, just consider the name. When has listening to somebody who sets themselves up to deal in shame and mockery ever been worthwhile?
It's not that there isn't a problem with user interfaces. There is. And its not that many of the examples they have aren't egregious. They are (although they're off the mark in their analyses in several cases).
I've done a lot of user intefaces over the years; some bad, some, I think pretty good, none of them perfect. I've learned a few things about them. The first is that almost any product is going to have flaws, some of them serious, most of which can be lived with. But serious or superficial, they're always easy to spot. What is hard is overcoming organizational inertia to get them fixed. Usually, there is no money to be made fixing it, which is pretty much the final word. You can get money to snazz things up with fancy graphics, but you can't get money to make them actually work better.
So, these hall of shame guys don't get any kudos from me, because what they're doing in my view is too easy. They aren't creating new methologies that quantifiably user performance. They aren't creating organizational strategies that improve products. They aren't creating a user constituency for better interface among users or manmagers. They arent even using these examples as case studies for how a user interface can be improved.
They're settting themselves up as pontificators and dealers of shame and mockery to people who don't measure up to their standards, without lifting a finger to help them. If I wanted that, I'd join a church.
Re:His blog follows a flawed design... (Score:3, Insightful)
Re:And the heating system (Score:5, Insightful)
"Standards", as far as software construction, are non-existent. Well, there are some style guides out there, but most of them conflict with most others. "Style" guides usually focus on inane issues like indentation and variable naming, instead of including insightful issues like, "C library functions that operate on strings without checking lengths should not be used: (list of functions to avoid)." Classifications of error conditions and how to recover or adequately respond to them are also usually lacking (what's a warning? what's an error?)
When issues like this are developed for software, and people actually follow them, you'll see greater consistency in software.
Re:And the heating system (Score:3, Insightful)
Re:And the heating system (Score:3, Insightful)
But I will add one thing - when will software developers start building better software? When the customer pays for it that's when. Most customers don't accept the schedule or budget for such an endeavor unless they are NASA or similiar organization that demands such high quality. Building such software takes resources, the customer has to be willing to give those resources (time, money, etc). Until that day comes where the customer is ready to give those resources we will not see much change.
Re:And the heating system (Score:5, Insightful)
You estimate it will take you 18 months to build the house. The "owner" comes back and says you have eight.
You say you need specific pieces of wood and nails to build the house with, however the owner tells you to use new unproven materials that don't even have effective methods of working with.
You say you need specific types of hammers, saws, cement mixers, etc. The owner says you can only use a rusty hammer with a broken claw, a dull saw, and you'll have to mix the cement by hand in a bucket to pur the foundation.
Your allowed to look at the location your going to build at, but you are not given the resources or time research the ground stability.
After you have rushed together a blue print, you're told to start. Halfway through, the owner changes the building materials, tells you that the utilities won't be there for another year, and change the complete layout of the house in the process.
In the last two weeks of frantic work, the town code person changes all the building codes.
So what kind of house do you get after this?
You don't.
And that's how a lot of software comes out.
~X~