Skip to main content

Chapter 9: Taste for Makers

15 replies [Last post]
johnm
Offline
Joined: 2003-06-06
Points: 0

How much does taste really matter in the software industry?

Do you evaluate your code in terms of taste (or "smell" or "style")?

Do you evaluate potential employees for their sense of taste? If so, how?

Do you work on e.g., open source software so as to scratch that itch that "There must be a better way"?

Graham ended with: "The recipe for great work is: very exacting taste, plus the ability to gratify it." Is there any great work being done in software?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
mthornton
Offline
Joined: 2003-06-10
Points: 0

> There are no good technical reasons why
Comments are the main remaining problem, and that could be reduced/eliminated if they were all presumed to be in html (like the javadoc comments) and thus could also reformatted to suit the context.

gary_kephart
Offline
Joined: 2004-03-04
Points: 0

One of the cool features of Eclipse 3.0, as I found out just a few days ago, is to be able to define a coding style and then export it to an XML file. Others on the project can then import the file and with a ctrl-shift-F, format the code.

johnm
Offline
Joined: 2003-06-06
Points: 0

> One of the cool features of Eclipse 3.0, as I found
> out just a few days ago, is to be able to define a
> coding style and then export it to an XML file.
> Others on the project can then import the file and
> with a ctrl-shift-F, format the code.

A corollary to Greenspun's Tenth Rule is that all "modern" IDEs eventually implement stuff (usually poorly) that's been in Emacs for ages. :-)

bondolo
Offline
Joined: 2003-06-11
Points: 0

It's unfortunate that the Code Formatting problem still exists. There are no good technical reasons why everyone's editor shouldn't just display all source in their preferred style.

Compilers and version control systems can happily eat some normalized format that may be nobody's preference. Logical "line numbers" for applications which need them can be derived from the normalized format or better yet, eliminated entirely in favour of using statement counts or per method function points.

It sure would be nice to see this "problem" finally go away.

johnm
Offline
Joined: 2003-06-06
Points: 0

> It's unfortunate that the Code Formatting problem
> still exists. There are no good technical reasons why
> everyone's editor shouldn't just display all source
> in their preferred style.

But that's the point... It's not a technical problem -- it's a question of humans imbuing and expecting tacit and implicit information in the code.

mthornton
Offline
Joined: 2003-06-10
Points: 0

I don't think anyone at my company is fussy about which style we use so long as we all use the same. Using two different styles within a single file (or worse within a method) invariably looks messy. So if we have to maintain a file that is in a different style we have some unpalatable choices:
1) reconfigure our IDE to match the existing style
2) reformat the file to fit our preferred style (not hard with a good IDE)
3) Turn off the IDE formatting support and manually make our corrections using the existing style.

You don't have to be autistic to dislike these options. Perhaps the file could contain a header referencing the style to be used which the IDE could recognise and thus automate option 1.

johnm
Offline
Joined: 2003-06-06
Points: 0

> Perhaps the file could contain a header
> referencing the style to be used which the IDE could
> recognise and thus automate option 1.

There are some Emacs editing modes which support that.

One of the reasons that Python has become so popular is that its (insane :-)) whitespace-based indentation-is-significant model makes the formatting style of all Python code basically the same. This reduction in variability feels refreshing as it removes most of the variability in that dimension.

jonathansimon
Offline
Joined: 2003-06-07
Points: 0

One of the biggest one here is the visual layout of code. I have met few developers that aren't really picky about how their code is formatted. And I have seen more than one team get very agitated over disagreement with others code styles. (code braces, carriage returns, spacing ...)

Maybe, since our code runs in the visual ether, this is so important to us.

johnm
Offline
Joined: 2003-06-06
Points: 0

> One of the biggest one here is the visual layout of
> code. I have met few developers that aren't really
> picky about how their code is formatted. And I have
> seen more than one team get very agitated over
> disagreement with others code styles. (code braces,
> carriage returns, spacing ...)

Indeed, the whole code formatting religious wars will never be settled. This is, IMVHO, partly a manifestation of the mildly-autistic, obsessive-compulsive nature of most developers. A bigger part for most people is that people's brains process information differently -- especially visual information (which is pretty much all we software folks have). Look at all of the ways that people have come up with to try to add in other sense modalities into the software process (both consciously ("code smells") and unconsciously ("structured programming")).

> Maybe, since our code runs in the visual ether, this
> is so important to us.

In terms of code formatting, part of the reason is that people imbue the format of the code with tacit intention and implicit meaning. This is one of the key reasons that most programmers can't stomach the syntax of the Lisp family of languages.

Of course, this level of "taste" is, IMHO, relatively unimportant -- the key is mostly just pick one style and be consistent. Much more critical are the more abstract levels such as design and architecture. If you're particularly interested in the design level, you might like reading Don Norman's latest book [i]Emotional Design[/i].

jonathansimon
Offline
Joined: 2003-06-07
Points: 0

This is where life gets interesting...

I spend a lot of my time considering data visualizations and interaction. Code has a definite lacking in this respect. There are a number of reasons for this including that fact that developer personalities tend not to want it. This is from back in the day when developers were the people who didn't need visual reinforcement of application models (check out Alan Cooper's books for more on this). This is why most programmers tend to be happy working at the command line -- fast interaction, mental application model.

I happen to not be one of those developers. And I wonder what the future holds.

Code formatting, and code in general is in some ways like ASCII art. Visualizations of the machine code it implies.

I think there is a lot of room here in the future, for not graphical programming as we think of it now (drag and drop boxes), but more visually rich "code". Visual feedback to help us visualize the code better, to help us understand what is going on and interactions between components. Debugging in this kind of environment could be easier as well, watching the app execute and so on.

Another place I see this as being a huge help is code repositories and merging. Small graphical components, with the ability to compare and combine visually, rather than manipulating ascii bits.

Someone at the Media Lab at MIT wrote a graphical turing language. I'll see if I can find it...

jonathansimon
Offline
Joined: 2003-06-07
Points: 0

I thought this chapter was really cool. I don't know if I would consider it complete (good designs are classified in several ways throughout the chapter, I may have added some categories), but I thought there were a lot of great points.

This one was my favorite (if that's possible).

[i]Good Design is Often Slightly Funny[/i]

Graham gives the example of the Porsche 911 as being slightly funny as an example of good design. Graham related this principle to strength -- I relate it to new thought.

Frankly -- as an interaction designer -- it's ever evident that the word is filled with bad design. And when you see an example of good design, it's so unusual, it seems funny. That's because we're not necessarily used to well designed things. And when we see them, we are sometimes taken aback. Or, they seem so out of place among the rest of the poorly designed world, that they seem funny.

johnm
Offline
Joined: 2003-06-06
Points: 0

> [i]Good Design is Often Slightly Funny[/i]
>
> Graham gives the example of the Porsche 911 as being
> slightly funny as an example of good design.

Bah! That's a great example of people buying into bad design and wretched architecture. If anything, the 911 is a testament to the fact that relentless engineering can (more or less) overcome inherent, fundamental flaws. Driving a 911 (especially close to the limit) requires learning to drive differently than in all of the rest of the cars in the world. In the new generations, they've done a lot with various kinds of driver aids to make these issue fade into the background as much as possible.

For a good example of design from the high-performance auto world, check out the Ferrari 360 (both the coupe and the convertible).

> Frankly -- as an interaction designer -- it's ever
> evident that the word is filled with bad design. And
> when you see an example of good design, it's so
> unusual, it seems funny. That's because we're not
> necessarily used to well designed things. And when we
> see them, we are sometimes taken aback. Or, they seem
> so out of place among the rest of the poorly designed
> world, that they seem funny.

Well, there's funny as in "odd" (aka "not normal") and funny as in "amusing". In terms of the funny as in odd, I totally concur with you that there's something striking about well-designed things. They often feel refreshing to me. I think Graham's comment at the end of that section (that the humorless would be hard pressed to also be good design) is focused on the funny as amusing point: there seems to be a quantum jump needed to get the joke.

jonathansimon
Offline
Joined: 2003-06-07
Points: 0

I'm assuming the man was referring to the exterior design of the car (since that what the picture was of).

I can't speak of the ease of use -- I've never had the pleasure of driving a 911 myself :)

johnm
Offline
Joined: 2003-06-06
Points: 0

> I'm assuming the man was referring to the exterior
> design of the car (since that what the picture was
> of).

Ah, so for all of that chapter on taste, do you really think that "beauty" or "taste" is really just skin deep?

johnm
Offline
Joined: 2003-06-06
Points: 0

Hmm... How much does the fact that large portions of our industry use terms like "scientists" and "engineers" affect our views of ourselves, each other, and what we do?

Or to ask it another way... Is there an objective measure of taste?