Morning Runs and Requirements

December 29, 2007

I used to run at lunch, it was a great stress reliever. These days, it makes more sense to run in the morning, things get too hectic at work. It still relieves the stress, in fact I usually start the day much more relaxed after a good run.

Right now I’m spending a lot of time on my runs focusing on form, specifically leaning forward and picking up my legs. Leaning forward felt really strange at first, like I was sticking my butt out. I think that’s because I actually was sticking my butt out, bending at the waist. Now focusing on leaning my pelvis forward and moving my legs back has made leaning a lot more natural.

The other thing that I’ve been working on is picking my legs up instead of lifting them forward. This feels really weird, like I’m almost running in place, I’m still playing with this, trying to concentrate on not pushing off at all.

I’ve been trying to relax my breathing — not the frequency, but the urgency, if that makes any sense. I’m just trying to breathe in and out easily, and relaxing my upper body when I exhale.

Finally, I’ve been experimenting with my arm swing. Swinging back on level ground and downhills, swinging forward on uphills. Anything to maintain the forward lean angle with the ground.

One thing I havent been focusing much on lately is effort. When I start the run, I start as slow as I want to. When I pick it up, I go as fast as I want to. I haven’t been pushing the pace at all, but the strange thing is that I’m running as fast as I used to when I was pushing it. Runs have turned into a great meditation — I’m focusing on form and breath and all of a sudden I’m gliding. I think that this is all in my head — I’m no Kenyan when it comes to form or effort. But it’s been great to get out and look forward to long runs as a chance to unwind.

When I’m not focusing on form, I’m thinking about a problem at work, or the new project. Garmin has done a lot of the heavy lifting to enable uploading to a web site — initial investigation shows that they have plugins for mac and windoze, and provide javascript access to their API. So that side of the house looks covered. Which is fine, I don’t have any issues with accessing/uploading the data, I just want to remix it in a relevant way.

One thing I was thinking about this AM was that I like to do a lot of long runs or rides because they are adventures. Even the climbs I was doing, like Outer Space and Orbit in a day, were about having a great time on moderate terrain and covering a lot of ground. The North Ridge of Stuart was another grand adventure. Every 1/2 marathon I do is a mini adventure of one kind or another, and RAMROD was some of the most amazing riding I have ever had the fortune to experience. In 2005 we got blown off of Rainier’s standard route, but still had a blast.

The thing that is missing from all of these great memories is data — I would love to have seen a Google Earth view of all of them. I would have loved to be able to insert comments/pictures at any point in a map, for instance mile 60 of RAMROD when the previous nights dinner asserted itself :). That way these adventures can be stories that I can share with people, to give them a sense of what I was feeling/thinking at what point, and where these adventures actually took me. It would have been great to see what my heart rate was doing up Cayuse Pass or slogging up to Muir with a 50 lb pack on. It would have been great to show the turnaround point on Rainier and how far off of the standard route we were (hey, 2 feet of new snow buried the wands. You try finding them at midnight in a blizzard!).

To sum up as more requirements:

  1. the application should allow me to inject pictures/comments into a map of the event.
  2. the application should show me my speed/heart rate/average pace/average hr when I roll over the map. (Ooh, that’s going to be a tough one 🙂
Advertisements

Time to stop talking and start coding

December 23, 2007

I was in the middle of a lengthy blog post on Java complexity when it hit me: I’ve been opinionating this whole time, with nothing but vague references to my work to back it up. So much for credibility 🙂

Obviously I can’t spill the beans about work, other than in very specific instances of technology use, like I have been. But that is of limited interest. Who really cares what I think about technology X , or that I got in a flame war about Code Coverage? I think more people would be interested in what I’m using for code coverage, how I’m using Spring, or Rails, or Ext or {insert technology x here}.

Something that would be even better would be to document an actual application, one outside of work that I can be completely transparent about.

So…I’m a data geek. I love data, and I love the way it has become so easy to mash up. For me collecting and exposing data is what motivated my early involvement in the project that eventually became a real company. While Evri has a noble mission statement that is applicable to data in general, an itch I have that is not getting scratched right now is the juxtaposition of exercise data with geoloc data in a way that is actually useful to me.

When I strap on my Garmin 305, I want to be able to:

(1) Track my HR, speed and location for any activity that I happen to do outside.

(2) Upload my data, and with little to no extra configuration

(3) View/Pivot on the data in the following ways:

  • I want to be able to view my stats — specifically, how hard am I working over the course? What is my average HR, average pace, average elevation gain, etc, for that run ?
  • I want to see that run/bike/run on the richest map UI possible. Right now that’s Google Earth, tomorrow it might be something else.
  • I want to be able to track those stats over a specific segment of my bike/run/ski. I want to break them out per mile, but also be able to be able to select a segment of my bike/run/ski and view them.
  • If the route I have just run correlates (within an adjustable delta) to a route I have previously run, I want those two to be grouped together.
  • I want to be able to view my progress (or lack thereof) over those routes by graphing the stats over time. If I run course X on week Y, then run it on week Y+1, I want to see how my average HR compares. I want to see how my average pace compares.

That last point was the important one to me. One way to measure fitness is Actual Effort Expended — how hard did I work vs how fast did I go? Ideally, if E = effort and P = pace, you would want E to drop while P increases. In other words you want E/P to go to zero. I might graph it the other way so that it looks good on a graph (going to infinite instead of zero.

Every solution I’ve looked at so far does (1) and (2) above, but they don’t quite do (3). If they do,

(1) they charge you for that kind of calculation.

(2) they make you do the calculation.

First of all, I don’t think that anyone should be charged for that. I think that the ability to mash up and pivot data is very close to being commoditized, and that the cost of that should be underwritten by ads. Additional services, like personal training, should be subscription based. But the ability to view and manipulate your data should be an inalienable right, goddamnit.

Second, I want to be able to view and pivot on this kind of data with little to no effort. I don’t want to do anything more than adjust standard defaults if and only if needed. I don’t want to have to create or update or enter new routes, I want them to emerge from the data. I want my data to tell me when I’m in shape, when I’m out of shape, when I’m having a bad day, when I’ve got a new favorite route, when my route starts to change, etc.

I dont want to think too hard about manipulating my data. I may be a data geek, but I want to have a low to no barrier experience once I upload the data.

Over the next year I want to treat this like a real software project. I want to

  1. determine feasibility
  2. evolve requirements
  3. evolve user scenarios
  4. build a data model that supports those scenarios
  5. start implementing trace route prototypes of the software using things that I want to, and processes I want to.
  6. move the app off of my box to an EC2 stack.
  7. point my friends at it (and make them write their own filters if they use some other kind of GPS).

I want to have some fun, on my own time, with something I might actually use, and sharpen up my total stack skills on the way. Stay tuned fearless reader (even if that fearless reader is the fearless writer 🙂 This one actually excites me.

The first step in the feasibility process is to make sure I can actually parse Garmin 305 data….I’ll update when I get some more details.


Code Coverage, and false quality assurance

December 21, 2007

Today I got into a flame war after sending out an email asking the engineering team to look at integrating code coverage into their daily builds. Instead of rehashing the entire thing, I’m just going to cut and paste the emails that went back and forth…

Me:

Since we are discussing code performance metrics a lot, I would like to also bring up code maintenance/quality metrics as something that we have collectively failed to address. I would like to get an idea of our unit test coverage — code coverage is an oft abused metric, but it does provide a good starting point to measure how good of a job we are doing writing self testing, self maintaining code. I would like to address code coverage in the following areas: ..

Uber Developer X:

I think that is a great exercise for our two SDETs … I don’t really want to waste any
of my time with it.

It’s easy to do, however of questionable benefit. The people that are
able to interpret the numbers right already know their coverage and
those that aren’t will simply misinterpret them. Net gain: 0 .

WTF? I didnt know where to begin…after some time to calm down, I decided to write a calm, rational response:

{Name of Uber Engineer X},

Wow. So after my jaw bounced off the ground, and I involuntarily lost control of my leg muscles, and after my vision cleared up, and _only_ after I edited all of the initial four letter words out of my response, I can only say that I am in complete disagreement with your conclusion, and quite frankly I’m just stunned — and disturbed — that you, who are as metrics and measurement driven as anyone I have met, who I have a great deal of respect for as an individual and as an engineer, can take such a dismissive attitude towards code coverage.

Test coverage, as I’ve noted below, is an oft abused metric. In fact, there is enough evidence in the industry to show that 100% code coverage doesn’t actually prove anything about the quality of the code. So I’m not beating that drum.

However, code coverage is definitely relevant when the generated metric is being tracked — relative to itself — over time. In other words, seeing a drop in code coverage over time is worth investigating at the very least. Knowing where you have no coverage is useful information. NOT KNOWING any of the above is voluntary ignorance, and reduces the utility of any unit tests written.

So the sooner we start, the sooner we know if we have a gaping hole in test coverage, and where that hole might be, and the sooner we can determine where holes might be emerging (and address them). Again, for someone as fixated on performance and metrics as you are, it floors me — I am literally getting off the floor as I type — that you don’t see the benefit in starting to measure test coverage over time, immediately.

Because running test coverage tools is easily automatable, it seems to be very useful to take the time to do this between iterations, because it only needs to be done once to measure repeatedly. Net gain = very high.

What I really felt like saying was: hey, am I in a bad 80’s movie? Is it the distant and murky past, where testers are a lower form of life, suitable only for automating the works of the almighty software engineer? Or maybe I’m delusional, and I have been fantasizing that it’s actually 2008, and testing isn’t just for SDETs anymore, in fact the best unit tests are being written before the actual code gets written. That’s right, in this mythical shangri-la, software engineers actually take pride in writing and running unit tests, not leaving the testing to someone else. Because at the end of the day, it’s better to know you suck than to pretend you dont.


Leaning vs Bending

December 19, 2007

So, I just got to the part of the Chi Running book that says “Form before Distance before Speed” last night. Which means that I went ahead and did a tempo run yesterday at noon, trying to apply the principles I learned in a crash course.

I started out slowly, because I can’t start fast, but noticed I was running with less effort than I usually do. So, feeling good, I decided to pick it up. Pretty soon I was in a world of hurt, trying hard to hang on to the basic Chi Running principles: lean forward, land on my midfoot, pick up my legs, relax my arms.

It was very hard to do this while trying to run at a decent (7:30) clip, I started feeling like I was working way too hard. But one thing I did figure out was that instead of leaning I was bending at the waist. The way I figured out how to ‘lean’ correctly was to focus on bringing my pelvis forward instead of my chest. When I did that, I literally felt like someone had stepped on the gas. Of course, I was still not exactly loping along — right now that pace is hard for me to keep — but it did feel like the start of a good thing.

While I like to run fast, I don’t like doing so in pain. That was what drove me in the direction of easier running in the first place. Fortunately for me the whole Chi Running approach advocates ‘form intervals’, where I focus on one specific aspect of form for one minute, then take a 1 minute breather.

I don’t have anything major planned for the winter months other than just getting outside and enjoying movement, so this is the perfect time to work on form. Then I want to build up the amount of time I can hold that form, and when I’ve got it down, I want to try to go faster. It’s a different approach than my usual he man suffer fest.


Running with less effort

December 17, 2007

As a software engineer, I try to get the most done with the least amount of effort. That approach has bled over to other things I do in life, including running. Ten years ago when I wanted to run  I would lace up the shoes, head out the door, and give little thought to form, perceived effort, recovery — I just ran as fast as I could, for as long as I could.  This stopped working about five years ago, when I started to get all kinds of running ailments. Plantar fascitis, hip/back problems, shin splints, etc.

This made me pretty sad because (a) I love to run, and (b) I love to eat even more. Without running, I was on my way to blimpdom, joining a long line of pasty geeks who started to resemble trapezoids as the years went on. Fortunately, before I threw in the towel, I decided to see if there was something I was doing wrong, biomechanically speaking.

Turns out there was quite a lot I was doing wrong. First of all, I was landing on my heel and rolling through to my toe. As powerful as that felt, it was actually slowing me down and stressing my lower legs. In addition to slowing myself down, I was also holding my arms out to the side as I ran, which would pull me off center because the swinging motion generated a lot of momentum, and it literally moved me over to the side that was swinging.

In short, I moved down the road like a slow, angry duck. Again, this didn’t significantly bother me until the injuries started mounting.

I stumbled on Pose Running checked out some of the videos, and decided those guys were freaky. I really think they’ve got something when they talk about form, but then they advocate running in extremely thin soled shoes to ‘feel the road’. I even read that one guy ran a 3:31 marathon in crocs claiming that it ‘wasn’t about the shoe, it’s about the running technique’. Maybe he’s right, but right now I have a hard time believing that I can run fast and injury free without some kind of padding…then I started reading about chi running. Normally I run away screaming from anything vaguely mystical/new agey due to having to deal with too many New Age people in Santa Fe, but the biomechanical advice Danny Dreyer was giving in the book was consistent with pose running and actually sounded like sound structural advice. Basically, he advocates (as do the pose running guys) landing on your mid to fore foot and maintaining a forward lean, so that you are essentially falling forward all of the time.  The leaning forward and midfoot strike have the effect of distributing the shock through your skeleton instead of your muscles/ligaments.

I ‘ve started to apply some of the drills from the book in my daily runs, and I’m finding that (a) I’m not getting injured like I used to, (b) my heart rate is lower when I run the same perceived pace, and when I run at the same perceived effort, I’m running faster, and (c) I’m enjoying the movement of running much more than I ever used to. Today I went out on a 6.5 mile run and just enjoyed the movement, kept my pulse in the recovery zone, and focused on leaning forward, striking in the midfoot, and letting my arms drop to my sides. This is the first time I’ve actually thought it might be possible to run a marathon, but I want to see if I can comfortably get some high mileage in w/o injury first. I’m going to target the usual Mercer Island 1/2 marathon in the spring — last year I ran it sick and averaged 169 bpm over the course, for a (very sad) time of 1:50. This year I would love to crush my pr on the course — 1:45 —  by running ‘easier’ :). Then maybe I’ll check out some of those shoes.


Software Design Lessons from the School of Hard Knocks

December 12, 2007

For the first ten years of my software engineering career, I was really into ‘being creative’, using cool and complex data structures, multithreading for the hell of it, in short reveling in complexity and that I was one of the few people who could understand what I was doing. In other words I was making mountains out of molehills and enjoying the resulting drama. That went on until I really began to not enjoy the drama of memory leaks that take 3 days to manifest, complex infrastructure (EJB 2.0, anyone?) that it took large tomes to master, and the joy of having to remember the inspiration behind some arbitrarily complex code while at a customer site with a very angry customer looking over my shoulder.

I had an inkling that what I was doing was wrong, but only in a vague way. When I learned design patterns, I began to sprinkle them liberally through my code like a bad cook overuses oregano. When I wrote multithreaded programs, I waxed poetic in comments about the locking order of my mutexes. All the while I wrote hundreds of lines of code, as if I could overwhelm any problem domain with sheer volume.

There were some telltale signs that this approach wasn’t working. I’m not proud to have introduced a memory leak in Java by getting cute with multiple references to the same object. Spending more time looking at the code, trying to understand it, than actually implementing a bug fix. Having a project canned because no one else could ramp up on the infrastructure, let alone the business logic.

That was what finally broke me — the sheer cost of making small changes in the code I had written. I was spending inordinate amounts of time working with brittle code and making it do things that should have been easy but felt unholy — and I had no one else to blame.

So I did a reset, and started hanging out with people who talked about red-green refactoring and what that actually implied. I started coding in iterations instead of death marches, and stopped trying to create the ultimate solution.

The other day I was telling a friend about this enlightening experience, and over beer we distilled it into a set of lessons:

(1) The first design is going to be chucked, so don’t spend so goddamn long trying to get it right.

(2) Its OK to not know what the ultimate long term design is — If you think about it, there isn’t an ultimate long term design for any piece of software that actually gets used — requirements always get changed, different solutions emerge. Flickr was originally a gaming startup.

(3) Premature optimization is evil. OK, that’s a Knuth-ism, but when I see code like this:

if(condition met) {

synchronize(some object) {

if(condition met) {

}

}

}

and the explanation is “I put the if statement outside of the synchronize because synchronize statements are expensive” I have to ask why? Specifically :

  • how expensive is the synchronize statement? Did you quantitatively prove that this was the biggest bottleneck in your code? Really?
  • Can a redesign be done in some other way that avoids this kind of obfuscation?
  • If not, can you comment the complexity so that the next poor bastard doesn’t want to strangle you? I know you think he will want to worship you, but I’ve never seen that happen. Actually, I have seen people want to worship other developers, but only when those developers write easy to understand and maintain code.

(4) Failing a test is much better than not failing a non existent test. It’s better to know where you suck instead of pretending that you dont.

(5) If you believe (4), then try this on for size: it’s easier to write a test first than it is to write code and then write a test. Why? Because you are limited to validating the interface signature, and you know nothing about it’s implementation. So you then test as if you didn’t know that args are being checked, return values will never be null, and pre-conditions and post-conditions will always be honored. Then, when you write the code, and it fails those specific tests, you get those tests to pass. And you know something about the quality of your code.
(6) You dont know squat about your system until it goes live. Let me take that back. If you have unit and integration tests, you know it passes those, and thats about all you know. If you’ve done load testing, then you have validated your system under a specific load, and that’s it. No one has the time to accurately simulate live traffic, so stop pretending.

(7) Because of (6), you need to instrument any system bound for production so that you see when your system is failing and actually do something about it.

(8) Less code = better code. The happiest part of my job is deleting lots of code that I had just written because I realized there is a simpler way to do things. Today I nuked 4 classes and replaced their functionality with about 10 lines of code. That I can understand.