|
Usability vs. Code More Complicated than Necessary
This thread fuses to recent threads: The thread about UI usability, and the thread about unnecessarily complicated code.
I find tons of stuff way more complicated than it need be. Lots and lots of code seems like it's been designed by people who don't really care to make its reuse intuitive. I didn't necessarily notice how counterintuitive some code was until, later in my career, I bumped into code that was elegant and easy to use.
The question I really want to ask about unnecessarily complicated code is related to the other thread about usability. I've heard a lot about usability at the interface between the app and the end user, but is there any serious work being done on usability at the interface between the application and the library/platform/package?
Adam N
Thursday, January 29, 2004
Oh, and every time I use another message board, I can't help but notice how insanely usable this site is. I haven't read the entire archive of this site, but I haven't seen any essays on code usability. Since the essays here are so insightful regarding UI usability, I'd love to know if you have any opinions/advice about the state of code usability, Joel.
Adam N
Thursday, January 29, 2004
Don't forget that coding is hard. Making something
simple is as hard as it gets. Most folks are just
happy to get something working.
son of parnas
Thursday, January 29, 2004
"is there any serious work being done on usability at the interface between the application and the library/platform/package"
Not that I know of. I thought about this years ago when I was studying. Software is full of interfaces (not just libs and so on, I mean right down to class interfaces, function interfaces, etc.) so why shouldn't one apply the same kind of theory to them as to the user's interface? *shrug* seems pretty obvious to me, but I've lived with the idea for many years so maybe I perspired, rather than was inspired, when I first thought about it (heck, maybe I even nicked it from someone else for all I know, though I've never found any reading material since which mentions it).
Maybe someone has done some work more recently - I mean, I am talking *mumble* years ago (sorry, don't want to give away how old and decrepit I am!) - or maybe it is just fscking obvious so it is not worth doing any work on it (though judging by the code we write, I doubt that). I kept meaning to write up my thoughts on it but just never got around to it.
Thursday, January 29, 2004
don't know if this is the sort of thing that you mean, but the book "code complete" is a pretty decent discussion of usable code, both for its own sake and in the context of large projects. It's kind of hefty, and I've never made it through in one go, but it's an interesting book to jump around in.
I think joel has it linked off of his list of books to read?
susan
Thursday, January 29, 2004
One of the XP methodologies is to code only what you need at that moment to fulfill the test cases you have written. Anything extra should be ruthlessly ripped out.
Once you start doing that, it's amazing how much cleaner the code is.
AC
Thursday, January 29, 2004
So before XP you wrote a lot of stuff
you didn't need and never used?
How come is that? I don't recall any
methodology saying to do that.
son of parnas
Thursday, January 29, 2004
"So before XP you wrote a lot of stuff you didn't need and never used? How come is that? I don't recall any methodology saying to do that. "
How many projects out there have carefully separated their code into presentation, business, and data objects (usually with another data/business layer in stored procs). In the _vast_ majority of cases that I've seen, the business layer is basically a containment of the data layer, with some extra marshalling and arbitration for good measure. The net effect is that changes often require the cascading change through a whole slew of layers (versus the oft stated benefit of isolating from changes), while performance and scalability has been devastated to blindly (and ignorantly) follow a design pattern.
NOTE: Before some "guide-my-way" whacko responds up in arms about the benefits of n-tier, note that I'm not saying that it is always inappropriate, but rather that it's sometimes inappropriate. In those cases it extends development timelines, makes the structure more error prone (which is the nature of the beast when you add links), makes the system less agile, all so someone with a inferiority complex built a system that would be without criticism from the mindless BigMac chefs that need to mindlessly apply generic patterns to all situations.
Dennis Forbes
Thursday, January 29, 2004
For instance:
float weight(float mass)
{
return mass*9.81;
}
versus
float weight(float mass, float g)
{
return mass*g;
}
If you stay on earth, you don't need the second one.
Uneeded code happens when you give a general solution to a particular problem.
Astrobe
Thursday, January 29, 2004
It's hard to know how much abstration to use. Too much, it's too complicated. Too little, it's hard to extend when you have to.
Either way, some person with 20-20 hindsight is going to say you are an idiot for doing it the way you did.
pdq
Thursday, January 29, 2004
"Either way, some person with 20-20 hindsight is going to say you are an idiot for doing it the way you did."
Let's be realistic though -- if you `under' abstract you're an easy target (crazy rebel lazy programmer) and will be targeted mercilessly by every BigMac chef. If you `over' abstract, your code might be bloated and overly complicated, your project might be months overdue, and performance might be subpar on massive clusters of expensive hardware, but few of your peers will dare defile your monstrosity because there's some paper somewhere that proclaims that all apps should be developed in such a way.
The easiest, politically safest, route for any developer/architect is to over-normalize, over-tier, over-develop and design.
Dennis Forbes
Thursday, January 29, 2004
This is a favorite topic of mine. Most developers are API consumers, not professional API developers. I see the following mistakes being made all the time:
- Overgeneralization. Developer is overoptimistic about reuse. Sees class as more important than it is.
- Virtual functions without an indication of when/where/why these would be overridden. I'm a fan of the override [always|often|sometimes|seldom] documentation syntax. Not perfect, but allows the reader to skim over calls that are likely not applicable to thier task.
- Coding for future expandability with no clear idea what that means. This is a noble goal and applies some of the time, but...
- Layering. And this layer exists, why?
- Bulk code. You see a lot of cases where a simple dialog with a few fields ends up being 1200 lines of code, much of it wrappers, getters/setters, etc. A reader doesn't know where to start.
- Lack of "why" comments. Why does this API call exist? When would I use it?
But the one that irks me the most is:
- Developers who think that other people will find their code as interesting as they do. No one cares about your custom iterators, container classes, or unqiue error objects. If someone can't sit down and have a basic understanding of your class in a few minutes, they're going to think about writing their own.
Thoughts?
Bill Carlson
Thursday, January 29, 2004
<quote> If someone can't sit down and have a basic understanding of your class in a few minutes, they're going to think about writing their own. </quote>
absolutely correct! entire post was on the nose. it's amazing to me that i looked at ADO for a few minutes and could use it without looking a documentation. (don't want to start flame wars --- ADO just was intuitive for me.)
there's kind of a tiny data access of thing written in-house here, that does 1/1000 th of what ADO can do, and it took me a week to get comfortable.
i'd like to know what other people think is well designed -- or not.
by the way, where the heck is joel?
mr. kibbles
Thursday, January 29, 2004
Joel is in Davis, CA or thereabouts
pdq
Thursday, January 29, 2004
> float weight(float mass)
> {
> return mass*9.81;
> }
No no no. The function should be:
float weight(float mass)
{
return mass*32.2;
}
Joel Buckley
Thursday, January 29, 2004
Hey, where'd that Mars probe go? :-)
Chris Tavares
Thursday, January 29, 2004
"Hey, where'd that Mars probe go? :-)"
Funny, but subtle. Wonder how many people got it.
888
anon
Monday, February 2, 2004
 Recent Topics
Fog Creek Home
| 
