Slashdot Mirror
If Bad Software Developers Built Houses...
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. "
Oh the irony.
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!
94% of Repubs and 21% of Dems voted to renew the Patriot Act
While moderated funny. I think I see the real point. A lot of the time of software failure is basicly management going to the development team and tells them to cut corners to get it done. So you could be the best interface developer on the planet. But if they tell you that it needs to be done now. when you are halfway threw. You end up breaking rules because it is quiker to program .
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
But if all the quirks are well documented and distributed to all members of the team, well by gosh this is quality work!!! And better yet, if you can trace all the requirements through to the test cases, we can even slap a CMM Level 5 on it!!!
"Well..here I am..." - Jubal Early
Perhaps part of a good user interface would be availability?
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.
Wer mit Ungeheuern kämpft, mag zusehn, dass er nicht dabei zum Ungeheuer wird. --Nietzsche
the way programmers wrote programs, the first woodpecker to come along would destroy civilization.
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.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
Building software is NOT like designing a house.
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, going with the analogy is that programmers are not architects.
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.
... people have been doing houses for several thousand years. We've got the basic idea down pretty well. We've been doing graphical computer systems for how long? 30 years, maybe? And computers, how long have we had those?
Not to excuse poor design, but sometime's it's easier to piss on stuff than figure out how to fix it.
http://www.welton.it/davidw/
I have a bit of knowledge in this area.
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.
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.
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.
Maybe I just went to a bad school (I wouldn't be too surprised), but it seems like Universities, Colleges, and technical schools seem far more interested in teaching the syntax of good code but never focus on the semantics of good code. I seriously think that most bad programs in the world are actually caused because, in school, their is a greater focus on the solution to the problem you're given rather than the method to get to the solution.
that we rarely design anything.
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.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
You are right in several respects: non-development management has screwed over more projects than it's ever helped. I've seen it and had my projects fscked many a time. One classic was the VP who wanted the acronym "API" removed from the help files for a developer kit. Reason? "We make solutions, not programming software."
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.
He forgot to add the price that they paid for this imaginary house: $2,000 with all of the appliances included. You can't complain about commmodity software development not being up to the standards of house building. You need to go to 5 years of school + an internship and then be licensed to build a house, you're paid hundreds of dollars an hour, and you generally are expected to go over budget and over schedule.
Ceci n'est pas un post
First of all, I'll be the first to say, UI design in a lot of software, free, shareware, or otherwise, is atrocious. But, comparing it to building a house... That's just stupid.
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.
When someone builds a house, they're given a blueprint, which lists the exact specifications for building said house.
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.
This is why building codes state unambiguously how thick joist must be, and how far you are allowed between them, how thick posts must be to hold up a deck of size WxD, how to anchor posts to foundation, what to use for foundation, how deep cement anchors must be embedded in the ground, etc.
"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.
How's my programming? Call 1-800-DEV-NULL
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Also, most of the other professions cited have about 1000 years of history leading up to their current state. Engineering and Architecture didn't just arrive in the 1950s.
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.
But let's turn the tables here. Let's give the home builders the usual specs that a software developer is given.
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~
~X~