June, 2006

Posts
  • Eric Gunnerson's Compendium

    Seven Deadly Sins of Programming - #4

    • 21 Comments

    Our next sin is the one that I've certainly been prone to.

    Long ago my wife and I owned a house east of Renton, Washington (those who know about Renton at that time can probably understand why one would say "east of Renton").

    Like many homes, this one had had various indignities committed on it by the previous owners. One of the most obvious was what can only be described as a "lean-to", constructed out of surplus Boeing shipping containers and shielding the washer and dryer from the rest of the garage.

    After dealing with cold and dirty feet for a few months, we decided to convert the space to a real room, with features such as a floor, a laundry sink, a ceiling that was actually attached to the joists, etc. The framing went quickly, but when it came to the point of finishing the drywall, we ran into a problem.

    My wife and I had very different ideas of how smooth a wall should be before it was painted. She wanted it to be mostly smooth, while I spent a fair amount of time with a light at an oblique angle, trying to get it really smooth.

    I did the bulk of the drywall finishing myself in that room.

    And after it was all painted, it turned out that it didn't really matter. Her standard was fine.

    Which leads us, in the usual roundabout way, to our destination:

    Sin #4 - Premature Optimization

    Or, in other words, spending time on things that don't really matter in the end.

    It's happened to all of us. You're in the middle of writing a class, and you think "a linear search of an array just isn't going to be fast enough here". So, you spend some extra time, and you use a hash table, or a tree, or a binary search, or something like that, and when you're done, you say to yourself, "now *that* isn't going to cause any problems".

    And then later, when you're getting close to done, you run your code through a profiler, and you find that a) the array never has more than 3 elements and b) the code is spending a ton of time elsewhere in the code.

    You wasted the time that it took you to do the optimization (bad), and you may have ended up with code that is considerably harder to read (worse), depending on how much optimizing you did.

    How do you avoid this? I have two bits of advice:

    1. YAGNI came out of XP, and it's a good dictum to follow. If you are doing TDD, this is easier to do as you are more focused on making one small change and not on "finishing the class".
    2. Go read what a wise man has said about performance, and work on creating a performance culture in your group.
  • Eric Gunnerson's Compendium

    Seven Deadly Sins of Programming - #5

    • 12 Comments

    [Several readers pointed out that I made a mistake in phraseology, and didn't say the thing I meant. Thanks to them for knowing what I wanted to say more tha I did.]

    Thanks to all who have commented on the previous sins, and to those who have written their own lists. I have avoided reading them, but I will take a look when (if...) I get done with my list, and I'll write a summary post linking to them, and likely listing the ones that I would have put on my list if I'd only been a bit smarter and a bit more thoughtful.

    Back when I was a pre-teen, I thought I really knew what was going on. I didn't need my parents advice on what to eat, or who to hang around with, and I *certainly* didn't need their advice around oral hygiene.

    So I didn't brush my teeth. Oh, I'd rinse my mouth out, but no actual brushing.

    This didn't cause any problems - my teeth were fine when I went to the dentist. No worries.

    For a year or so. Then I had to have 4 cavities done in one fall. Big cavities. Cavities that weakened my teeth enough that I'm slowly buying my dentist some nice accessories for his boat, as they start to crack and I get crowns put on.

    Code hygiene is also important.

    Back when I started coding, my teacher (who I am in debt to for being at least 10 years ahead of his time and setting up a real programming curriculum (no, we didn't use abacuses...)) made us write down our programs on paper before we were allowed to use computer time. Not only did you have to write it down, you had to show it to him, and if it wasn't good enough, he'd make you copy it from scratch with the necessary changes.

    When I got better, I got introduced to my first text editor. Line oriented, a real improvement. Rather than typing a line over, you could make changes to it.

    Then, the fateful day came when I got to use a screen-oriented text editor. You just used the arrow keys, and you could make changes *right in your code*.

    Very powerful. And very dangerous, because it supported

    COPY AND PASTE

    (Cue emphatic and scary music).

    Copy and paste is not a sin - it's actually quite a useful thing, but features like it make it far too easy to do bad things. Need a function that's almost like the one you have? Copy and Paste. Need to add another conditional into that double-nested loop? Just insert it in there. Need a class that's almost like what you have? File copy, then search and replace to change the names.

    Which leads to too much function complexity and duplication, and to our fifth sin:

    Sin #5 - Deferred Refactoring

    Once you start deferring refactoring, things get bad. Even if you have good intentions to come back and "clean that up a big", you often don't.

    That's why I find agile methods and shared code ownership so interesting. If there are good tests in a codebase, I can find the ugly code that a coworker has written and refactor it into something nicer rather than just trying to get picked to work on "the new codebase"...

    Now go brush your teeth, and it wouldn't hurt you to floss sometimes...

  • Eric Gunnerson's Compendium

    A single programming language?

    • 4 Comments

    I've been reading Good Math, Bad Math for a while now, and it has a fair number of interesting posts on it.

    Today I read Why so many languages? Programming languages, Computation, and Math. (a followup to Type Checking in Programming Languages)

    As a former semi-professional language designer (involved closely in the C# language design), and develop whose written in a fair number of languages, I think that Mark is missing part of the point.

    At a high level, languages have different kinds of abstraction *and* different levels of rigor.

    Mark's discussion seems to be about the former point. And it's true that that kind of abstraction means something - functional languages are inherently better at some sorts of problems, and worse at other sorts of problems.

    Now, could you design a language that incorporates features of functional languages and procedural languages? A combination of Haskell and C#?

    I think you could. Whether it would be coherent and understandable (ie usable) is another matter - I think you could easily end up with an awful mess. And even if you didn't, it could easily be so big conceptually that it would be hard for many developers to get their minds around it. Compactness and simplicity have big benefits as well in programming languages.

    Those who have been following the LINQ project may have noticed an obvious parallel - LINQ is precisely about taking two different languages and figuring out how to join them in a rational way. I don't think it's going to be a mess, but whether it adds too much complexity

    The second point - which Mark doesn't cover - is one of rigor. Different application spaces require very different levels of rigor. Or, to put it another way, the amount of rigor that it makes sense to pay for is different from application space to application space.

    For what professional developers think of as "real projects", rigor - in the form of strong type checking, contracts, things like that - is a very useful thing, as it helps achieve the target quality.

    But for what I'll call casual software - which encompasses a really broad range, from scripts to hobby programs to web pages on up to some departmental apps - that amount of rigor isn't required, and sometimes the cost isn't worth it. I could write a short script to launch my profiler and do something with the output in a high-rigor language, but it's probably faster to write it in Perl, or some other scripting languages.

    I do a fair amount of carpentry and some woodworking in my spare time. The question "why is there more than one programming language?" is akin to asking "why do you own more than one saw?"

    Different tools for different jobs.

     

  • Eric Gunnerson's Compendium

    Eric's Tips for a Happy Marriage

    • 19 Comments

    As you get on in years, you feel the need to pass on your accumulated wisdom to the younger generation, which they will promptly ignore until they're as old as you are, at which point they'll admit that you were right all along and their lives would have been *so* much better if only they'd listened rather than listening to that crappy music of theirs (why oh why can't they have any taste in music?)

    So, at the risk of repeating the Miss Manners incident, I hereby present the following list, in no particular order:

    Eric's Tips for a Happy Marriage

    • Check for religious compatibility. This may not seem like a big deal, and many couples are able to be happy despite differences, but if children show up one day, it can be a big source of friction.
    • Recreate together. No, you don't have to do everything together - in fact, you *shouldn't* do everything together - but spending time having fun is a great way to stay connected. If it's something exercise-related, all the better.
    • Kids. It's helpful to have some agreement about the number, timing, and species of any offspring.
    • Don't get married too early.
    • A sense of humor, for both you and your wife.
    • Taste in furniture. I have a friend who has a wife who likes the country cottage style, and he is destined to sleep in a room with a 4 poster bed, lacy pastel canopy, numerous stuffed animals, and a slightly illegal number of pillows.
    • Would it kill you to learn how to cook something? Not only is this a nice way to share the tasks, depending on your choice of wife, it may turn out to be an important survival mechanism
    • Random Acts of Giftitude
    • Compromise
    • *Both* toilet seats go down.

    Why should you listen to me? 7300 days, baby!

  • Eric Gunnerson's Compendium

    Bavarian Sounwerks - Speakers for BMWs

    • 5 Comments
    I've been unimpressed with the sound on my 328i since I got it. I have the Harmon-Kardon system, and like many factory "premium" systems, it really doesn't deliver. Which is really putting it mildly. The bass is muddy, and the tweeters don't.
     
    This weekend, I spend some time putting in a set of replacement speakers from Bavarian Soundwerks. I've probably replaced around 10 factory systems (sometimes speakers, sometimes whole systems) in my time, and the improvement this time is the most I've seen. Well, heard. The clarity and depth is so much better not to mention actually being able to *hear* the cymbals. The bass is tight (though not deep - you can only get so much from 6 1/2" drivers), and the factory amplification can produce reasonable (but not truly rockin') sound levels.  Apparently Harmon Kardon did a decent system design but BMW didn't want to spend the money for decent drivers.
     
    If you've done stereo or speaker installations in the past, this is fairly straightforward stuff, but I'm not sure that I'd recommend it for a beginner. The instructions are pretty detailed (though they miss a few things, and my wiring and other stuff varied from the directions a bit), but you still have to pull off door panels, carefully pull out speakers, put the new ones in (some bolt in, some are installed with hot glue. (no, really, and it works quite well)).
     
    The appearance is unchanged.
     
    For replacing all 10 speakers in my system (four 6 1/2" bass drivers, two 2 1/2" midranges, and four 1" tweeters), the cost was around $500. You have a few options for drivers - the base system drivers are from CDT, but you can upgrade to MB Quart (my choice), or Rainbow for a little more money.
     
    If you want the deep bass, they also sell easy-to-install subwoofers.
     
    Definitely recommended.
  • Eric Gunnerson's Compendium

    Rule #1 of Regex debugging

    • 3 Comments

    Rule #1 of Regex debugging

    The regex engine isn't hung. It will finish eventually.

    However, "eventually" may not until after the heat death of the universe.

    You either didn't anchor your string, or you didn't think clearly about how the quantifiers "*" or "+" work. Or both...

  • Eric Gunnerson's Compendium

    A close escape, and more on inappropriate cleverness

    • 6 Comments

    Monday I went on the 7 hills ride.

    Wednesday night, I wrote a long and detailed post about it, and hit the "Post" button.

    In a fit of editorial brilliance, my blog server chose that exact moment to experience a problem, and the post vanished into the ether.

    Few will quarrel that that event was a net positive for western civilization as a whole.

    So, here's the short version.

    HomeDownPauseUpDownUpDownUpDownUpDownUpDownPauseUpDownUpDownStrawberryShortcakeUpHome

    Now, that that's out of the way, there were a few comments on the 6th deadly sin post that I'd like to comment on:

    (BobHy) "Inappropriate" is relative to time (as your first story illustrates) and point-of-view ("cui bono").  Would you agree that cleverness which benefits the user who runs the code (efficiency) or the team who maintains it (maintainability) is appropriate?  And if the clever bits trade off one of these against the other, who gets to decide the direction?  

    Inappropriate is obviously a value judgement. Who decides? Well, I do, since it was my post. In general, I'd expect that the team would decide, though in my experience there aren't that many teams with the sort of culture that allows this.

    But, yeah, I agree with this.

    (BobHy) OTOH, even when we consider cleverness whose only benefit is to amuse its author, it's fair to ask whether the author's happiness is itself a benefit to the user community ("a happy programmer is a cooperative, bug-fixing programmer") or to the team ("a happy programmer remains on the team and trains his/her successor").  

    An ancient Chinese programmer once said,

    I pity the fool who has to maintain or extend the code of a programmer who wrote clever code because it made him happy.

    I've experienced many cases where a developer writes code that is clever, moves on to another job, and then the people who have to deal with the code have to deal with that cleverness. My current team is dealing with this now, and it's a big problem for us.

    If you want to amuse yourself writing clever code, do it on your own time. But don't make your team deal with it.

    (BobHy) I'm beginning to think "inappropriate cleverness" may be a vacuous term. But there certainly is "incorrect" cleverness, where the claimed benefit of the design is refutable.

    You are obviously not a long-term reader (assuming, for the sake of argument, that such a person exists) if you find the presence of a vacuous term in a post of *mine* surprising.

    The difference between inappropriate and incorrect seems mostly one of semantics. I chose inappropriate because I think it's more of a judgement call, while incorrect implies a black and white choice.

    (Tomer) It's funny, I keep running into arguments as to the pros and cons of the sort of "codespace-optimized" loops you mentioned. I'm actually very much for them - they're usually used where the algorithm is very simple (for example, when writing to a frame buffer and adding a stride value to your target pointer) and tend to make the code "look" a lot more elegant.

    I will confess to being somewhat of a code aesthete in my earlier days, looking for more compact expressions. I got started in that back when I was writing games in interpreted basic, and the size of your code could have a big impact on how fast your program ran.

    Over the years, writing a lot of code and trying to understand other people's code, I realized that the #1 most important feature of well-written code is clarity. And for me, the two most important facets of that are:

    1. Predictability (the code in method a looks like the code in method b)
    2. Simplicity

    The world where for loops just do looping is a conceptual simplification over the world where they sometimes do additional things. In the first case, I read the for statement once, and then concentrate on the loop body. In the second case, I read the for statement, read the loop body, but have to remember that there's something else going on that I have to go back and refer to later. When you write that, you're making me work harder, when you simply could have put "j += stride;" as the last statement in the loop.

    That's why foreach is such a useful construct. It's not that you type less. It's that it's conceptually simple - you know that there's no funny business going on, and all you have to worry about is the loop body.

    (Shahar) We used to have a dev in a previous company I worked at (circa 2000) who had his own special way of doing HRESULT-COM error checking..

    Shahar goes on to detail what the practice was, which I agree is bad, but it's a matter of degree, since all HRESULT handling techniques suck.

    *****

    Most code is read far more times that it is written. Go read this post by Peter Hallam, one of the C# compiler devs.

  • Eric Gunnerson's Compendium

    FIFA Fussball-Weltmeisterschaft 2006

    • 10 Comments

    The World Cup is once more about to commence.

    During the 1998 World Cup in France, we were in Europe, and the Europeans take their football very seriously. Buildings in the Netherlands are covered with the orange. No matter where you are and who is playing, 30 minutes after a match is over you will hear people driving around honking their horns and waving flags (well, that part you see rather than hear) in celebration. And it's common to see the police in riot gear in preparation.

    During the time that was there, we watch 30 some games of soccer. Which seems a bit excessive, but it's so rare to see good soccer in the US, and to be able to contrast the attacking style of the Europeans vs the more possession-oriented game of South America.

    It can be confusing, however, to watch European TV, especially since the broadcasts were from various countries. In the US, we learn the names of countries, but we don't learn the names in other languages (except, perhaps the home language of the country).

    For example, in the US is would be Germany. In Germany, it would be Deutschland. But there's also:

    Duitsland (Netherlands)
    L'Allemagne (French)
    La Germania (Italy)
    Alemania (Spain)

    So, when you see a three letter code, it may take you a bit of time to figure out who you are really watching. They may use the standard euro codings for country names, but I don't really know those.

    And, the US may show up differently. USA (Germany), Etats-Unis (France), Estados Unidos (Spain)

    US Television looks pretty good, with HD broadcasts of all 64 games.

    Finally, go watch this cool Nike Video...

  • Eric Gunnerson's Compendium

    MSDN Wiki now open for comments...

    • 1 Comments

    I'm happy to be able to announce something that has been in the works for a fair bit of time.

    MSDN documentation is generally pretty good, but it sometimes misses some important information, and it's hard to get that information where people can see it, and back to the authors.

    MSDN Wiki allows comments to be added to msdn topics. I just added one to the main page for the Regex class.

    Kudos to the team for making this happen.

  • Eric Gunnerson's Compendium

    Improving the user experience...

    • 11 Comments

    Most bugs that I fix in the DVDMaker UI are fairly benign, but yesterday I fixed one that could have had more severe consequences, as noted in my checkin mail:

    Problem Description:
     
    Stanley was in his study that night. He knew that he should be getting some sleep - especially with what he had to do in the morning - but he was playing around on his computer, and came across a program titled "Windows DVD Maker".
     
    His hands trembled as he launched it. A window appeared, and then this message:
     
    ---------------------------------------------------------------------------------
    DVD burner not found
    If you have a DVD burner installed on your computer, make sure that it is connected properly and turned on, and try running Windows DVD Maker again. Learn more about this problem
    ----------------------------------------------------------------------------------
     
    Stanley peered at the message. He took off and cleaned his tortiseshell Valentino eyeglasses, replaced them, and looked at the message a second time.  The first part of the message made sense. He didn't have a DVD burner. But the second sentence just ended. Was there something else that he needed to know? He sat and pondered the situation...
     
    Sleep came with difficulty that night, and throughout the night he was tormented by the spectre of rogue punctuation.
     
    The next morning, he was met as he came into the office by Nicole, his underhanded and overachieving assistant of the last 3 years. "You look tired. Are you sure you're up to this?"
     
    Stanley nodded, and proceeded to get ready for the procedure. He thought he was okay, but the lack of sleep combined with the mental anguish of the previous night conspired against him, and instead of removing the mole from Mrs Slater's right forearm, he instead removed the one from her right bicep.
     
    Mrs Slater looked down, noticed what Stanley had done, and said, "Yeah, you can do that one, too, as long as your there".
     
    Solution:
     
    Add the period to the end of the message, okay?
  • Eric Gunnerson's Compendium

    Microsoft Robotics Studio

    • 0 Comments

    Microsoft Robotics Studio.

    Looks interesting. Uses a CLR 2.0 base, though it's not clear to me yet where the MS part runs on the robot or whether it runs on a separate windows computer.

     

  • Eric Gunnerson's Compendium

    Eric's tips for a happy marriage

    • 7 Comments

    As you get on in years, you feel the need to pass on your accumulated wisdom to the younger generation, which they will promptly ignore until they're as old as you are, at which point they'll admit that you were right all along and their lives would have been *so* much better if only they'd listened rather than listening to that crappy music of theirs (why oh why can't they have any taste in music?)

    So, at the risk of repeating the Miss Manners incident, I hereby present the following list, in no particular order:

    Eric's Tips for a Happy Marriage

    • Check for religious compatibility. This may not seem like a big deal, and many couples are able to be happy despite differences, but if children show up one day, it can be a big source of friction.
    • Recreate together. No, you don't have to do everything together - in fact, you *shouldn't* do everything together - but spending time having fun is a great way to stay connected. If it's something exercise-related, all the better.
    • Kids. It's helpful to have some agreement about the number, timing, and species of any offspring.
    • A sense of humor, for both you and your wife.
    • Taste in furniture. I have a friend who has a wife who likes the country cottage style, and he is destined to sleep in a room with a 4 poster bed, lacy pastel canopy, numerous stuffed animals, and a slightly illegal number of pillows.
    • Would it kill you to learn how to cook something? Not only is this a nice way to share the tasks, depending on your choice of wife, it may turn out to be an important survival mechanism
    • Random Acts of Giftitude
    • Compromise
    • *Both* toilet seats go down.

    Why should you listen to me? 7300 days, baby!

Page 1 of 1 (12 items)