{
Joel Spolsky, software pundit of Joel On Software is writing a series of articles on "Great Design." In his most recent article draft he talks about "star" products - his examples include Brad Pitt, the iPod, and the Herman Miller Aeron.
Here is my short rebuttle, not because I think he's wrong, but because I think sometimes good design is boring as ever:
>> It's interesting how iPods and Aerons always come up when it comes to "good design" but no one is crazy enough to talk about Wal Mart and design.
Joel asserted as much himself in his previous article describing design that as a discipline it's focuses on a lot more than the aesthetic.
But one of the things that is impressive to me about good design is invisibility.
Wal-Mart is a perfect, but scandalous example of this. No one wants to bring them up because it's not as chic as, say, an iPod, but when we are honest with ourselves it seems as though this "proletariet" design seems to contact us more than something like an Aeron chair.
How fashionable is it to talk about the design of throw aways, or the design of "just good enough?" I think Visual Basic and Wal-Mart have a lot in common: they touch *everyone* (have a look at the POS (no pun intended) system at the next store you visit and chances are it was written in VB), but they don't jump to the front of one's mind when they think of (capital D) Design.
Is the Wal Mart throwaway an excellent example of design?
Okay, how about this for a change of direction. What car do people pick out of a crowd for "great (capital D) Design?" Audi? BMW? But what car silently makes the profits of these vehicles like chump change (some boring car that *everyone's* got, like a Honda Civic). By design? <<
What is to be said of throwaways and invisible design?
I'm sure people are going to respond to my post here.
}
Monday, January 30, 2006
Sunday, January 29, 2006
Good Design is Hard
{
Joel Spolsky has begun a new series on design. I'm looking forward to it because I find myself having to refocus on the discipline of good design quite often.
The one thing I have begun to understand about design is that in order to do a good job you've got to be absolutely tenacious. If it means *exactly* 172 pixels, you use every means necessary to use 172 pixels. Not 171, nor 175, exactly 172.
His first article, "What is Design?", does a good job of dispelling the myth that design is something mystically done by "artsy" people. It will be interesting to see where he goes from there.
I managed to get the company where I did my last project to use Fogbugz, Joel's bug tracking software. At the time it seemed like simplistic software - I had a hard time believing that this "guru" of software development only had Fogbugz to show for himself. However, I've been able to understand more of the design behind Fogbugz now; we use Serena Teamtrack and although it *seems* like it has more functionality, it's missing a lot of the ease, flexibility, and philosophy of Fogbugz. The best designs are like the best special effects in a film; they are so good you don't realize they are there.
}
Joel Spolsky has begun a new series on design. I'm looking forward to it because I find myself having to refocus on the discipline of good design quite often.
The one thing I have begun to understand about design is that in order to do a good job you've got to be absolutely tenacious. If it means *exactly* 172 pixels, you use every means necessary to use 172 pixels. Not 171, nor 175, exactly 172.
His first article, "What is Design?", does a good job of dispelling the myth that design is something mystically done by "artsy" people. It will be interesting to see where he goes from there.
I managed to get the company where I did my last project to use Fogbugz, Joel's bug tracking software. At the time it seemed like simplistic software - I had a hard time believing that this "guru" of software development only had Fogbugz to show for himself. However, I've been able to understand more of the design behind Fogbugz now; we use Serena Teamtrack and although it *seems* like it has more functionality, it's missing a lot of the ease, flexibility, and philosophy of Fogbugz. The best designs are like the best special effects in a film; they are so good you don't realize they are there.
}
Wednesday, January 18, 2006
10 years, not 10 hours
{
Most programmers hope they are smart, myself included. Especially at the chastisement of Joel, or some other pundit, we bristle defensively or let it go to our heads whether we meet the criteria of "smart" for the day.
What's even more taboo is to say "I don't know" or "I don't understand." To avoid this many people broaden their exposure so that they can claim they know something of HTML because they've written a tag in notepad, or they claim they "know" C++ because they've written a Hello World.
Out of this a whole cottage industry of 24 hour / 21 day books have flourished to mock what it really means to know something technical. I'm sure the authors of such books aren't claiming to transmit a full understanding of thier topic but that's irrelevent here; it's how books like this are used.
I read an excellent essay by Peter Norvig which confirms an intuition that I had: it takes many years to really know a programming language. For the last five or so years I don't think I've gone more than a week without writing something in C# and I still learn knew things all the time about the language. If someone asked me if I "knew" C#, it would be awkward; I know the answer they'd be looking for is the simple yes or no, but I wish I could stop them and say, "hey, I've been programming the .NET Framework for a while and I feel like I'm getting there with C#."
Norvig's challenge to "know" a dozen programming languages is a formidable one.
I'm a few languages short but that's where I'm headed.
}
Most programmers hope they are smart, myself included. Especially at the chastisement of Joel, or some other pundit, we bristle defensively or let it go to our heads whether we meet the criteria of "smart" for the day.
What's even more taboo is to say "I don't know" or "I don't understand." To avoid this many people broaden their exposure so that they can claim they know something of HTML because they've written a tag in notepad, or they claim they "know" C++ because they've written a Hello World.
Out of this a whole cottage industry of 24 hour / 21 day books have flourished to mock what it really means to know something technical. I'm sure the authors of such books aren't claiming to transmit a full understanding of thier topic but that's irrelevent here; it's how books like this are used.
I read an excellent essay by Peter Norvig which confirms an intuition that I had: it takes many years to really know a programming language. For the last five or so years I don't think I've gone more than a week without writing something in C# and I still learn knew things all the time about the language. If someone asked me if I "knew" C#, it would be awkward; I know the answer they'd be looking for is the simple yes or no, but I wish I could stop them and say, "hey, I've been programming the .NET Framework for a while and I feel like I'm getting there with C#."
Norvig's challenge to "know" a dozen programming languages is a formidable one.
"Learn at least a half dozen programming languages. Include one language that
supports class abstractions (like Java or C++), one that supports functional
abstraction (like Lisp or ML), one that supports syntactic abstraction (like
Lisp), one that supports declarative specifications (like Prolog or C++
templates), one that supports coroutines (like Icon or Scheme), and one that
supports parallelism (like Sisal)."
I'm a few languages short but that's where I'm headed.
}
Painful Growth
{
Raganwald has an excellent essay on failure in software development. In a world where everyone seems to be talking about how programmers ought to be smart, this is a dose of reality in which we realize that the line between success and failure depends on so much more.
I've been on two failed projects. Each time there's a bit of painful growing. I know I'm not alone; there's that statistic of the majority of software projects failing; but I like honesty and candor with the attempt to become better.
}
Raganwald has an excellent essay on failure in software development. In a world where everyone seems to be talking about how programmers ought to be smart, this is a dose of reality in which we realize that the line between success and failure depends on so much more.
I've been on two failed projects. Each time there's a bit of painful growing. I know I'm not alone; there's that statistic of the majority of software projects failing; but I like honesty and candor with the attempt to become better.
}
Monday, January 02, 2006
Rumble in the Jungle with Joel
{
In his latest essay, Joel Spolsky has taken the gloves off for a rant against what he calls "Java Schools"; schools that use Java as the implementation language for various Computer Science courses.
Joel's always been a point of love/hate for me: I love his writing style, his lack of fear in pointing out what's wrong, and how he's been a good model of the loud programmer that pisses people off, but who is, more often than not, right. I've taken a bit of pleasure exposing his venture capital articles to business types around me.
It's a bit different when you're at the end things. I lack a formal computer science degree from even the likes of a "Java School" and he seems to sneer at those of us who weren't part of the brotherhood at Yale or MIT. He didn't even spare Penn, which in it's own right is a pretty good school.
It's been interesting to see the responses come, some which look past the vitriol and point out the truth of what he's saying, as well as others I've enjoyed which involve people as educated and smart as Joel putting many of his comments in their place. My favorite thus far has been one from a UPenn professor delivering a bit of a lashing in Joel's direction.
The real question is what I do with what Joel says, which in essence is that good programmers understand recursion, algorithms, and pointers extremely well, and that the best languages to cultivate that understanding are C++ and LISP.
On the first point I agree. I use recursion on a regular basis (lots of XML and heirarchies with my work), but instead of pointers I've been the user of references since I've been using C# and Java. Although I've implemented lots of my own data structures and applied a few well known algorithms, they've been within the safety (and usefullness) of my non-C++ language pool (C#/Java/Javascript/Visual Basic/SQL/Perl etc... ). Maybe there is some reason for me to revisit some of these concepts in the "harder" language of C++ with the use of pointers. And perhaps it's time for me to pick up that dusty copy of LISP, by Patrick Henry Winston, with a compiler and a notebook. I'll never be able to claim that I went to MIT, or Yale, or even a Java School. But I'll be a better programmer for it.
However, there's another thing that all the good programmers I know of seem to understand well and that is regular expressions. And, another thing that intuition tells me is that to learn them well I need a language in which using a regular expression is as easy as a breath of air.
}
In his latest essay, Joel Spolsky has taken the gloves off for a rant against what he calls "Java Schools"; schools that use Java as the implementation language for various Computer Science courses.
Joel's always been a point of love/hate for me: I love his writing style, his lack of fear in pointing out what's wrong, and how he's been a good model of the loud programmer that pisses people off, but who is, more often than not, right. I've taken a bit of pleasure exposing his venture capital articles to business types around me.
It's a bit different when you're at the end things. I lack a formal computer science degree from even the likes of a "Java School" and he seems to sneer at those of us who weren't part of the brotherhood at Yale or MIT. He didn't even spare Penn, which in it's own right is a pretty good school.
It's been interesting to see the responses come, some which look past the vitriol and point out the truth of what he's saying, as well as others I've enjoyed which involve people as educated and smart as Joel putting many of his comments in their place. My favorite thus far has been one from a UPenn professor delivering a bit of a lashing in Joel's direction.
The real question is what I do with what Joel says, which in essence is that good programmers understand recursion, algorithms, and pointers extremely well, and that the best languages to cultivate that understanding are C++ and LISP.
On the first point I agree. I use recursion on a regular basis (lots of XML and heirarchies with my work), but instead of pointers I've been the user of references since I've been using C# and Java. Although I've implemented lots of my own data structures and applied a few well known algorithms, they've been within the safety (and usefullness) of my non-C++ language pool (C#/Java/Javascript/Visual Basic/SQL/Perl etc... ). Maybe there is some reason for me to revisit some of these concepts in the "harder" language of C++ with the use of pointers. And perhaps it's time for me to pick up that dusty copy of LISP, by Patrick Henry Winston, with a compiler and a notebook. I'll never be able to claim that I went to MIT, or Yale, or even a Java School. But I'll be a better programmer for it.
However, there's another thing that all the good programmers I know of seem to understand well and that is regular expressions. And, another thing that intuition tells me is that to learn them well I need a language in which using a regular expression is as easy as a breath of air.
}
Sunday, January 01, 2006
New Year's Day for my night language
{
Each year, as many people gear up for their New Year's resolution that they will ultimately fail, I make my own doomed promise that this will be the year that I become proficient in perl. As the year wears on I get more engrossed in project work and "lose" time. Or I work on my own pet projects which I can prototype and finish so much more quickly in C#, or whatever else I know well.
But my encouragement for the upcoming year's attempt is coming from all directions.
One is YAPC, which will be in Chicago this year. That's within reach, and it's not so expensive that I can't afford to be there.
Another has been Josh McAdam's perlcasts. While I'm at work moving pixels or writing C# I've been listening to quite a few prime hackers in the background.
The second encouragement came from a post on Joel On Software about having a "night time" language:
Long live the night language.
}
Each year, as many people gear up for their New Year's resolution that they will ultimately fail, I make my own doomed promise that this will be the year that I become proficient in perl. As the year wears on I get more engrossed in project work and "lose" time. Or I work on my own pet projects which I can prototype and finish so much more quickly in C#, or whatever else I know well.
But my encouragement for the upcoming year's attempt is coming from all directions.
One is YAPC, which will be in Chicago this year. That's within reach, and it's not so expensive that I can't afford to be there.
Another has been Josh McAdam's perlcasts. While I'm at work moving pixels or writing C# I've been listening to quite a few prime hackers in the background.
The second encouragement came from a post on Joel On Software about having a "night time" language:
"For the purposes of this argument I am assuming the programmer uses the language he likes best at night, and maybe not his favorite during the day. If you wish to debate this, start another thread and I will. Why does the programmer like the language that he likes at home so much? I would argue that it is largely about efficiency in the language. If you can do something quickly in a language you get that feeling of control that I think most programmers enjoy. " - threaded hereIt's nice to know that other people out there feel as I do, and have their own "night" languages.
Long live the night language.
}
Subscribe to:
Posts (Atom)
Posts
