Mt. Evans (14er #10, Front Range finisher)

Yesterday Ryan and I finished our first ascents of the Front Range 14ers by going up Mt. Evans from Guanella Pass. For those not familiar with Colorado, Mt. Evans has a paved road to the top, but with the road closed for the winter we hoped to avoid the zoo scene we found on Pikes last summer. That goal was definitely accomplished (we were the only ones on top once we made it), as was reaching the summit (and more importantly, successfully descending to the Jeep). We also extended our streak of never being denied a summit when attempting just the two of us (doesn't include getting the Jeep stuck for La Plata, where we didn't even set foot on the trail). I wouldn't give us any style points though... due to the willows, a steady diet of ice cream, a steep gully and a fair bit of class 2 scrambling, we barely beat dusk getting back to the Jeep(!).

I had read and heard nightmares of "those awful willows" and thought we would have a solid freeze / snow to our advantage. [Me: "Yay, there will be a well defined trail on snowpack through the willows!" Willows: "Haha, sucka, you still screwed!"] It turned out that although we weren't sinking knee-deep in mud and getting into turf wars with beavers, we did end up doing a fair bit of route discovery and willow-wrestling. It seemed at times we were following tracks of folks who had no better idea of where to go that us, as was probably the case. I am really surprised that there isn't a better marked or official trail through that mess, because it increases the difficulty by an order of magnitude (if such a thing is possible, but I'm pretty sure I just made that up). At any rate, this hike seemed like it had 4 phases (which may fit since it's about 4 miles each way):

1. the willows
   
2. the gully (far easier than it looks)
   
3. exiting the gully and bonking before lunch
4. scrambling about a mile to the summit
5. enjoy a familiar view (having driven to the top several times)
   
6. scrambling back to the gully
   
7. running out of water
8. descending the gully with tired legs
9. getting horrible cottonmouth (note: eating snow doesn't help much)
   
10. trying to keep up with Ryan while we both race the sinking sun
    

That was more than 4, but you get the idea. I don't want to overdo it here, but this outing makes the Mt. Elbert outing a few months back seem like ginger beer (any Hunter S. Thompson fans out there?). It wouldn't seem as challenging if you could break off a mile or two easily here and there, but you just can't. Once you overcome the willows, you are faced with a gully, then altitude and scrambling. I was disgruntled like a freaking Michigan football fan (couldn't help myself there) after that ridiculosity. I believe we started some time around 10am and didn't get back to the Jeep until almost 7pm. 9 hours for "just" 3100' of elevation gain over 8.5 miles. Wow. Yikes. Dude, that guy who told us we should hurry up was a real jackass considering we beat him back to the parking lot. Damn, that pizza and beer tasted fine. All of the above.

Enough ranting. We did have several high points to speak about on this occasion.

1. There were far fewer people on the trail than last summer's Bierstadt outing. We kept commenting on how quiet it was, which was nice.
   
2. We saw a very beautiful alpenglow sunset on our way back to the Jeep.
   
3. We saw more wildlife than we have on previous 14er outings, including 3 Bighorn sheep, 3 mountain goats, and 2 foxes. (I'm pretty sure the 2nd fox, which we saw within eyesight of the Jeep on the return, actually spoke to us and welcomed us back to the trailhead... then again, I could have been hallucinating.)
   
4. We also completed our first range on the 14ers to-do list, which was a nice milestone. We have yet to set foot on a San Juan, Elk, or Sangre de Cristo range 14er summit, but hopefully there will be days ahead for that.
5. We completed our first 14er in the month of October. (October now joins June, July, and August for that distinction.)
   
6. Personally, I also put my new mountaineering boots, Scarpa Triolets, through their first day and they passed with flying colors. They kept my feet dry, blister-free, and warm all day long. I'm excited to use them for hopefully many snow hike/climbs in the future.
7. The views of Bierstadt and the Sawtooth ridge were very nice.
   
8. We camped at a great spot Friday night well below treeline on the south side of the pass in Park county.
9. The weather was ideal.
   

I would rate this as my 2nd most difficult 14er hike, only exceeded by Longs last summer, and honestly not by much. The huge difference between Longs and this, though, is that I was very satisfied with the accomplishment on Longs. The main thing I was satisfied with here was filling up on pizza and getting back to Boulder for a nice hot bath. (Yeah, that's right... I took a bath. My hot tub was closed.) Neither of us were terribly happy with the day, and honestly questioned why we subjected ourselves to those sort of days. While the obvious answer is Mallory's famous "because it's there" I was void of a good reply at the time. I think I'll just spend the next several months skiing instead :)

Photos: http://flickr.com/photos/brett_burch/sets/72157608181341572/

Am I excited for Microsoft TFS 2008?

**Warning: this post is work-related and probably going to be boring to most people.**

After loudly complaining about TFS 2005 today (for the n^th time I got an error while checking in new files that ultimately unsafely killed the devenv.exe process, thank you very much), our QA manager asked me if I was excited about our future upgrade to TFS 2008. That's a good question because I know nothing about TFS 2008 and how it's different from TFS 2005. My initial thoughts:

1. It can't possibly be worse, so bring it on!
2. I'm excited about the .Net framework 3.5, but that says nothing about TFS.

I took it upon myself to find a better answer to that question, and here's what I found:

I am slightly disappointed in what I learned about TFS 2008 because it seems the main thing they focused on is CI and build automation. At first this sounds like a good thing, and it might be, but honestly it just shows me Microsoft is still the same stubborn behemoth that refuses to recognize the open source community despite the press they'd like you to believe. There are a hundred build automation tools out there that other shops have been using since .Net 1.0 came out in 2002. Why we need another (buggy) one from MS is beyond me, except to satisfy the "it's open source so I can't call support so my manager won't let me use it" crowd. I'm not suggesting that all open source is good and MS / profit hungry corporations are evil, but attempting to compete in a free wheel segment by reinventing said wheel in an inferior manner and adding a price tag on it is insane. If you're going to be a fast follower at least be a good one, ok Zune? I can only hope they fixed the bugs in the current "RC" version.

I just don't believe Microsoft knows anything about agile or CI in particular (would they have released TFS 2005 without it if they did?), and their reputation of not listening to customers has been proven fairly true in my experience, so I frankly don't expect their CI product to actually satisy our CI needs. No CI shop is the same, so we'll need to customize the process. Hopefully that will be less painful than checking in a file in TFS 2005, and won't require a PhD or a 900 page book to do successfully. I personally would like to see us keep the CC.Net implementation we have been working on. CC.Net has been around forever, is free, has good community support and decent documentation, is built by smarty pants nerds who update it regularly, and just works. It's simple. So, for that matter, are NAnt, JIRA (not free), Bugzilla (free but I prefer JIRA), CVS and/or Subversion, and Basecamp from my experience with them. Which leads me to my next point...

I'll stop complaining about MS the company now and shift my attention strictly to the TFS product / concept. Note that this isn't necessarily specific to TFS 2008, but nonetheless is part of my exploration for an answer. Q: What is TFS and why would anyone buy it / what is the competitive advantage? A: TFS exists, in a broad generalization, because Microsoft thought it would be smart to give their customers (software shops with more than 1 developer) the ability to have one mecca uber-place where

1. their customer support / product teams track bugs and new features,
   
2. their developers store code which implements said features and bugs in a team-friendly fashion without leaving their IDE,
   
3. their QA teams pass or fail the items created in step a,
   
4. their build manager can compile a version of the product containing the new feature or bug fix to be pushed to somewhere, and
   
5. to a tiny degree, project managers can oversee this entire process from start to finish.
   

In short, the entire software development process under one roof. What a huge undertaking. That's all well and good, but means TFS essentially then acts as a bug tracking system, a source control repository, is integrated well with Visual Studio (a huge product in its own right) as a plugin, and acts in a minor way as a project management tool. As far as I'm concerned, TFS 2005 only satisfies 1 and 3 in a halfway decent way, and didn't even attempt 4 (kudos to TFS 2008), which means all Microsoft did was recreate JIRA or Bugzilla. What strikes me as especially bizarre about TFS as a product is that there are already free products out there that satisfy the 4 bullets above and cost nothing. What's the competitive advantage then? Only that it's all in one mecca uber-place. Hmm... I honestly don't mind having more than one application open at one time on my machine, and would happily trade 5 tiny-footprint apps that function well for 1 giant, slow, buggy one. It seems to me TFS is suffering from a severe lack of competitive advantage... certainly not enough to warrant the licences, extra SQL servers, CPU and RAM rape, etc. If they actually do manage to jam the entire software factory under one roof then it'll probably just remind people of how over-complicated their jobs are, but we'll see.

A few other bones to pick as a developer using TFS:

• My entire team regularly experiences bugs which crash Visual Studio while checking in code. If they fixed any of those, then YES, I am excited about TFS 2008.
• Since TFS already knows which tasks are assigned to me (or anyone else if I happen to be working on a file for my neighbor), why can't I associate files to tasks before I check them in? This would eliminate the need to track that on a spreadsheet or text file (oops! that's another app I have open) until I check in. I would really like to be able to click a "Resolve a Task" button which lets me pick a task and knows which files to check in based on my selection. How about that for competitive advantage? As far as I can find on the web, TFS 2008 does NOT have this feature. Surprise...
• The way that TFS 2005 alerts you of file conflicts on check-in sucks. TFS should only fail a check-in if it can't merge and check in at the same time for all files being checked in. I constantly have check-ins fail only to be alerted that TFS can auto-merge all files for me. If you can, then just do it. If they fixed the check-in process, then YES, I am excited about TFS 2008.
• The TFS merge tool sucks. Me and most of my teammates have installed other merge tools (free, by the way) to do our merging outside of TFS (oops! that's another app I have open). If they improved the merge tool in TFS 2008, then... I really don't care because it probably still sucks.
  

I should stop now. Am I excited? Let's just say the jury is still out.