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