?

Log in

No account? Create an account
!("Shifting Requirements" => !("Elegant Code")) - Lindsey Kuper [entries|archive|friends|userinfo]
Lindsey Kuper

[ website | composition.al ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

!("Shifting Requirements" => !("Elegant Code")) [Nov. 27th, 2005|11:36 pm]
Lindsey Kuper
[Tags|]

A few days ago, terror_firma drew my attention to this technique for using defaults and special cases in CSS, and I've been thinking about it ever since.

Sure, CSS has enormous potential for DRY, but the drawback of that approach is that you lose flexibility on the level of individual items. For instance, suppose I'm working on some software for Mister Client Man, and I implement failure and confirmation messages as explained in the article. One day, Mister Client Man tries to use the software and gets a failure message, which he has to squint at. So he tells me, "Failure messages are too small and hard to read. Make them huge and blinking." (Okay, so he probably wouldn't suggest they be blinking, but bear with me for the sake of example.)

Because of the implementation, my first question would be, "Should confirmation messages be huge and blinking, too?" The response I'd typically get then is either "No, that would be bad," or "No, that's not necessary." (My DRY is screwed either way, but the latter is particularly maddening, because it's intended to save me work, but it's actually making things more difficult!)

I could explain to Mister Client Man that failure messages and confirmation messages are implemented from the same default, but really, I'm the only one who should have to think about the implementation details of what I'm doing; if other people have to care about that stuff, it's generally a sign that something's wrong, no? And moreover, if I were to explain that they were implemented from the same default, his response might well be, "Well, that's stupid. Failure messages and confirmation messages are the opposite of each other!" Which is not quite true, but it's certainly hard to argue with.

This kind of thing comes up all the time in my work. Every time I've ever written an beautiful DRY style sheet that takes full advantage of the cascade, I've ended up having to pay for it later.

So what can be done? Do shifting requirements preclude elegant code? I really don't want to believe that. Here's what I want to believe instead: Inelegant requirements preclude elegant code. I want to believe that someone familiar with the software -- not from an implementation standpoint, but from a user's standpoint -- would have noticed (in spite of themselves, maybe!) that confirmation messages and failure messages follow the same basic pattern, and would realize, perhaps subconsciously, that if we make one look different, we should make the other look different, too (and that if it doesn't make sense for the other to change, then maybe it didn't make sense for the first one, either).

For this to happen, of course, the people making the requirements have to be intimately familiar with the software from the standpoint of user experience -- familiar in a way that Mister Client Man isn't yet. After two weeks, once he's seen lots of error messages and lots of confirmation messages and knows forwards and backwards what it's like to use the software and which particular things about it drive him nuts, then I want to hear what he has to say. In the meantime, I want him to shut up and test.

As programmers, I don't think we would let anyone who isn't familiar with the code dictate changes to to the code. Why, then, as UI designers, would we let anyone who isn't familiar with the UI dictate changes to the UI? Is it possible that we're fetishizing the whole "sit down and have it work immediately" principle to the point that we scramble to do whatever it takes to make the user's first ten minutes slightly better, even if those changes make the user's next ten thousand minutes slightly worse?

Or am I just a lazy programmer who doesn't want to do anything that will result in more work for me?

LinkReply

Comments:
From: (Anonymous)
2005-11-28 02:19 pm (UTC)
Is this a problem of coding for consistency as a default, where the user doesn't "value" consistency? And probably because he doesn't think about the importance or usefulness of consistency throughout the design process (from coding to presentation)?

I guess if I were asking for a product, but had no reason to know that two things were linked in functionality I might be willing to accept that their design yeilds consistency if someone told me that they were linked, and delinking them would cost me money for little benefit aside from satisfying a whim.
(Reply) (Thread)
[User Picture]From: underwhelm
2005-11-28 02:20 pm (UTC)

oops that was me.
(Reply) (Parent) (Thread)
[User Picture]From: stingmeyer
2005-11-28 05:19 pm (UTC)
Not sure I understand the issue here. You have failure and confirmation messages implemented such that the common stuff is factored out, and the different bits are in their own special places. Then the requirements change ("d'oh!") such that there is another different bit. Why can't that different bit just be put where the other different bits are?

Maybe you are referring to the discontinuous mapping from requirements to "elegant" code. If you have two similar things, it's best to implement them by factoring out the common stuff; but you have two different things, it's best to implement them more independently. Now, if you start with two similar things, and continuously change the requirements such that they gradually become more and more different, then at some point there's a discontinuous "jump" in the most elegant implementation. Is that it?

O~
(Reply) (Thread)
[User Picture]From: lindseykuper
2005-11-28 07:22 pm (UTC)

Nice metaphor.

Yeah. That's it. Up to a point, the implementation can accommodate changing requirements while staying pretty much the same, but once the requirements change past a certain point, the implementation has to follow with a sickening lurch.

And, yes, as I was putting together that particular example, I realized that the changes could just go in the appropriate "different bits" section, and it wouldn't be the pain in the ass I was making it out to be. Especially since that section already has to be there anyway. But I've felt that lurch enough times to know that it's real, even if I can't think of a worthy example right now.
(Reply) (Parent) (Thread)
(Deleted comment)
[User Picture]From: lindseykuper
2005-11-29 03:07 pm (UTC)

Re: Nice metaphor.

If they understood how interconnected everything is and how it all fits together like a puzzle, maybe they'd make sure that their requests make sense holistically and not just for one element on a page.

Yeah. I think I said something to that effect in my email exchange with you. The interconnectedness is the sort of thing that takes time to understand, because you might only be seeing one or two pieces of the puzzle at a time. So how does one build things so that each tiny piece by itself is as good as the whole thing? ;)
(Reply) (Parent) (Thread)
(Deleted comment)
[User Picture]From: lindseykuper
2005-11-29 10:11 pm (UTC)

Re: Nice metaphor.

It's like you're in my head.
(Reply) (Parent) (Thread)
[User Picture]From: royhuggins
2005-11-29 07:21 am (UTC)
Hmm, there is no such thing as an inelegant requirement. A requirement is a requirement. In my experience, the most elegant code is that which is both abstract and atomic. If I can make sweeping changes easily and also create specific changes at the most minute level, then my code is highly successful. If Mr Client Man wants his confirmation messages small and his warning messages big then that's what he wants. That specific example actually sounds totally reasonable to me, to be honest. :)

Sometimes you do need to say "well, the way I've set things up, your request would require this much time to implement which is probably more trouble than you actually wanted." If they still want it then you make some (annoying but necessary) changes. I've had many clients gladly back down from a request when I made it clear that the particular backend setup I created makes their request difficult and that it's set up that way because I didn't foresee them making such a request.

Programming theory, even when created by people working in the field, is usually impractical. Things get messy and you can't change that. :) I used to find myself getting very anxious about it and my anxiety would rub off on clients. When I just accepted that sometimes things get messy, I discovered that a) the messiness doesn't bite me in the ass as often as I thought it would and b) once I changed my attitude about it, I miraculously developed new insights about how to keep things from becoming messy. I had to give up on a goal before I could figure out how to attain it! It's kinda wierd. :)
(Reply) (Thread)
[User Picture]From: lindseykuper
2005-11-30 12:22 am (UTC)
When I just accepted that sometimes things get messy, I discovered that a) the messiness doesn't bite me in the ass as often as I thought it would and b) once I changed my attitude about it, I miraculously developed new insights about how to keep things from becoming messy. I had to give up on a goal before I could figure out how to attain it!

Yeah, I know what you're talking about...it's funny how that works. I think that sometimes, one has to do something the wrong way for a while before being able to understand why the right way is the right way. =)
(Reply) (Parent) (Thread)
[User Picture]From: royhuggins
2005-11-30 12:35 am (UTC)
Yes, that's true. Like when I used to try to drive everywhere in reverse and then realized that driving forward is better. But I wouldn't have really known why driving forward is better unless I'd tried driving backwards all over the place. So I'm wiser than everyone else now because I have that experience.

Maybe I should stop listening to Tenacious D.
(Reply) (Parent) (Thread)
[User Picture]From: lindseykuper
2006-03-17 05:23 pm (UTC)
I'm still thinking about this. I think that the point I'm trying to make is that there is such a thing as an inelegant requirement. It's a poorly-thought-out requirement. What I'm wondering is whether poorly-thought-out requirements necessarily lead to bad code.
(Reply) (Parent) (Thread)