Lake 22: Super Panorama

I created a nice big panorama photo of Lake 22 today. It's 15,919 by 7,495. Click the photo to get the full sized version. You can zoom in enough to see all the waterfalls off of Mt. Pilchuck.

Lake 22 Hike Trip Report

Last week, a coworker mentioned Lake 22 which is in the general vicinity of Lake Stevens and more specifically, about 12 miles east of Granite Falls, WA. The boy and I went up there this past Saturday and while it wasn’t an easy hike, it was definitely worth the trip.
It took us nearly 2.5 hours to get to the lake going steadily up the whole time.
Most of the trail winds through forest.
   
 
While in the forest, the trail follows Creek 22 and given how steep it is, there are lots of waterfalls. Here’s one of the medium sized ones if you combine the upper and lower parts. There a couple that are bigger than this but harder to photograph without getting all daredevil by the edge.

 
Eventually the trail ends up on a big bare section of the mountain that affords some nice views.

 
The trail at this point is over a whole lot of broken, loose rock.


Eventually we ended up hiking on snow which was interesting given that it was narrow in places and slippery.
 

The big payoff is when you get up to the lake. It’s pretty spectacular and my pictures do not do it justice.
 

This one has some teeny tiny people in it to the right of center, to give you a sense of perspective of how tall Mt. Pilchuck is:

 
The snow is still pretty deep up there:

The Hiking

Appropriate footwear is important for this hike. Hiking boots are best but a good pair if sneakers with an aggressive sole will work too. Flat sole shoes like Converse High-tops are a bad idea due to the loose rock, the snow, and how the trail takes across many a small brook.
Hiking poles could be handy for the snow parts. I picked up a 2 pair of carbon fiber poles from Costco after the fact for $24/pair. They’ll be useful the next time we go.
Cell phone coverage stops about 2 miles east of Granite Falls. That means you’ll need to check in with your loved ones before leaving town since there’s no reception anywhere near the trailhead.
There were plenty of people on the trail between 2pm and 6pm while we were there which I like in case something bad happens, especially when there is no cell reception.
Check out the WTA link at http://www.wta.org/go-hiking/hikes/lake-22 for more details.

The Photography

• An 18mm lens on my crop sensor 60D was too narrow to get all of Mt. Pilchuck.
• Around 4pm when we got to the lake, the sun was in just the perfect place to give that yucky washed out tone.
• A circular polarizer would be great with all the sky, water, and snow. I don’t yet have one.
• The canopy in the forest was dense enough to get reasonably even lighting at ground level.

Learn from your QA staff

In modern times, it is common practice for developers to write unit tests with their code. This is a great thing. But developers aren't practiced at writing tests, nor do they have that base knowledge that your QA team would have.

Why not start learning from your QA team and getting them to share their subject matter expertise? Your QA folks have many years of experience in how to find bugs in software.

Just for fun (to prove this to yourself), the next time you bump into one of your testers in the hallway, ask them to list the standard / rule-of-thumb use-cases for boundary condition testing. I bet they come up with a few you didn't think about. They know a lot of cool stuff like that, stuff that you need to know to write effective unit tests.

There is a lot of good that comes from this.

The developers will start writing better unit tests. That means they find more of their own bugs, the ones that are easy for QA to find. This reduces cycle time and makes better use of the QA folks time.

The test team will feel good and valuable and loved because you are highlighting the fact that they have knowledge to share and you want to learn from them. This is not only a morale boost, but a culture shift as well.

Having more interaction between the test team and the dev team, outside of the "your app sucks" and "why didn't you find this bug" meetings, will enhance that relationship making for better and smoother interactions on projects which makes for better delivered product.

Don't give your crap to your testers

If you're a developer with any kind of honor or pride what-so-ever, your goal is to have no bugs. And while all software has bugs, the bugs in your code that QA does find, should be so arcane and edge case-y, that they everyone is impressed that those bugs were able to be found.

Said differently, let's say you drop your car off at your favorite shop for a tune-up. How would you feel if your car won't start when you go to pick it up, as if the tune- up had made your car worse and the mechanics didn't notice?

You'd be the indignant kind of mad. You'd think that those mechanics had no sense of pride in their work and didn't care about you the customer.

So how do you think it reflects on you when you give something to QA and in the first 5 minutes, running through the basic smoke tests, the app fails? Do you like like looking like a dolt? Don't you want to be able to find the bugs in your code before they do? Sure you do, because you have pride in your work.

Test your stuff before you give it over to QA. Don't waste their time and yours by giving them stuff that fails on the easy tests. Test their mettle. Make them stretch to find the good bugs because you've already squashed the easy ones.

Not me, not me

I heard from a few friends of mine, that I'm wrong about software owners choosing to ship untested software and I thought I'd drop a quick note about that.

Does QA actually release the software themselves when they feel it is ready?

If not, then whomever owns the software and decides to ship is overriding the QA group.

It happens when QA's schedule is nickel and dime'd up front. When the QA schedule at the end of the project is compressed because dev teams slipped. When the software is released with known bugs. When the QA team isn't given an equal voice and influence at the triage table. When time for building automated test suites is cut.

The only time QA is really in control is when they have total go/no-go authority _AND_ they aren't being pressured by one manager up who is vested in the date.

Mind you, I don't think the QA group should be given total go/no-go authority. That is a business decision that needs to take a lot of factors into account. I wish I could say that it was only about "quality" but it isn't. Besides, what is "quality" anyway and who's requirements define the quality of the software product? Is the QA team incented to follow the business goals (which always include quality) or to let no bugs get to production? The two are very different.

I just bring this up because the conversation gets easier when we own up. You own the software, you decide when to release. If you can accept this fact it clears up a lot of other confusing issues.

I own the software and am responsible for it working or not working.

I own the test rigs and test environments since those things are critical to my knowing that my software is going to work. Just as I use testing to verify the work of the developers, I use the developers to verify the work of QA. I leverage the QA team to develop some components of that test system along with my dev team but I am still responsible for the test team's output even though they report up through a different chain. They are essentially loaned to me as part of my team for their expertise. All of the test environment code is reviewed by someone from the dev team as we may have to modify it, fix it, extend it while they are doing other important work, just like inside the dev team.

If you can own-up to this state of mind, your interactions with your QA team _will_ change as now you are working together on your own thing -- the thing that you have vested interest in.