Smithsonian Photostream

There's two things I like about the Smithsonian's copyright-free Photostream on Flickr.

First, as a minor history buff, I like the idea of access to these pictures for free. It feels like I have a greater democratic ownership of my own history.

Second, I'm glad the Smithsonian was smart enough to use a defacto public standard for sharing pictures on the web. A few years ago this would have been done with some very nice looking, but strikingly unusual Smithsonian website with its own user interface affordances, no RSS feed, and relegated to some musty corner of the internet. By using Flickr, the Smithsonian is injecting this history into one of the main arteries of the internet instead. Good work!

Depends on how you define "street"

Brent points out that Google's Streetview has arrived in (of all places) rural Kings Canyon CA. They have Streetview available for a a swath of 198 and 180 between Kings Canyon and Sequoia National Parks--along with an interesting collection of offshoot rural roads.

Here, for example is the turn off to the jeep trail I wrote about last summer, Defeat at Park Ridge.


View Larger Map

Here you can actually see a Giant Sequoia in the background as they arrived at the Grant Grove parking area in Kings Canyon NP.


View Larger Map

Simply amazing that Google's doing this.

Power of open vs simplicity of closed

An interesting article along the lines of my post yesterday about Gmail Lab's vs Apple.

.. how the power of open can be balanced with the simplicity of closed.

Two models for trying out new features

Google has their act together with this experiment in which they allow users to experiment with potential features of gmail. Participation is optional--so they're not going to force something on a user they don't want/need. They are demonstrating a degree of modularity in that individual features can be turned on/off. They're collecting feedback automatically and will let the users decide what's valuable to them. It's an extremely Agile method for rolling out software features. Google's leveraging the advantages inherit in being a provider of Internet web applications as well--this is much more difficult with traditional applications.

Compare this to Apple's methods.. The general public is kept completely in the dark about potential new features until some big-bang style roll-out. While they obviously do extensive usability testing, all the design, testing, and refinements are held close to the chest. Given Apple's design cohesiveness, it's obviously all managed by a fairly small group rather than through a lot of contributors. Apple's had some pretty good luck with this method--which is a stark contrast to Google's.

Practice

The teams we typically think of as models of teamwork have one thing in common--they practice. Sports teams practice. Navy Seal teams practice. Firefighters practice. Sometimes it's called "training" but it still involves fictional scenarios and some transient effort that isn't being applied to the real world. Its designed to hone the team's skills and provide a safe way to screw up and learn from their mistakes when the game, mission, or lives are not on the line.

It's one of the injustices in our business that we're not allowed to practice. We hire people, then immediately put them on the job and demand that they write mission critical code on a tight deadline. What they write (we hope) will be shipped to real live customers tomorrow.

The result is junk code. When I see this code, "the guy was practicing" is the first thing that pops into my head.

We do have one way to give people an opportunity for practice. It's called prototyping. It goes way back to Fred Brooks' The Mythical Man Month. He said "plan to throw one away; you will, anyhow." Your first attempt is going to be wrong anyway. Use it as an opportunity to practice, to learn, and make sure you throw it away before the real deal.

When building a prototype, use the opportunity to make it a full dress rehearsal. Treat it like a real development effort so that the entire team, tools, processes, etc, are exercised. The analogy to sports, military, emergency services still applies. They practice in realistic scenarios in which the entire team is involved and they use as many props to simulate the real world scenarios as they can.

Don't look at the time spent building a throw-away prototype as a waste of money. Prototyping has long term value not just to the product, but to the entire team.

Top 10 Rules of Technical Management

I've found these work for me. Your mileage may vary. :)

10. Ignore the backlog
Mary Poppendieck has a great discussion in this video in which she asserts that you should throw away your backlog: Competing On The Basis of Speed. I was once in a discussion with Werner Erhard in which he said that there are three kinds of things you're doing:
1) what you're doing now (the one thing you're doing right this second)
2) what you're going to do (the things you have scheduled on your calendar)
3) the things you're never going to do (everything else on your 'wishlist").
Don't keep a chain around your neck of things you're never going to do.

9. Prioritize ruthlessly
We've got too much stuff to do. We've got too much stuff we could do. We've got to get our priorities straight. We have hard choices to make. What do we do right now? What do we do next? What are we not going to do and what will that cost us? What's more important? Try this: take your list of todos and cut it in half. Make an ordered list and share it.

8. Define, clarify, and redefine goals
Those who work for me can attest to this scenario. They have a problem and they come to me and explain the problem at length. I interrupt them and say "remember, the goal is blah blah blah." If they have good management skills, they can find their way around the obstacle and get on track for the goal. If they don't, they probably need help. But the goal is the point of conversation, the obstacle is not the point of the conversation.

7. Manage Expectations
"Announce results, not expectations." That's one of Rudy Giuliani's rules of leadership. Don't let expectations get out of control. Spend the time to make sure people's expectations are in synch with your goals and plans. Over communicate this point. If you suspect the customer thinks they're going to use your system in some way you don't intend, let them know about it. When in doubt, ask them what their expectations are. A lot of technical people make the mistake of asking what the customers "requirements" are. This is usually not productive because the customer doesn't understand the formalism of "requirement." Ask them what their expectations are and they'll gush about all their hopes and dreams. Those are the expectations to you need to worry about.

6. Define standards, and use them
Standards aren't just for ISO or the United States Navy. They don't have to be a big musty pile of books on a shelf nobody reads. Standards are your definition of how you're organized and how you do what you do. For any group of two or more people, some form of standards are necessary. Are you going to use source control and CI? Are you going to make unit tests? How are you going to deploy changes to your server farm? Start by sitting down and asking yourselves how you're going to work. Then do it. Are there industry standards or defacto standards that already meet your needs? Good--use them. Hold yourselves accountable for living up to your own standards.

5. When Possible, Let Somebody Else Do It
Too many technical people spend way too much of their time reinventing a wheel that's already been invented for them. It is known as "Not Invented Here." This goes for expertise as well. People attempt to do it themselves when they really should be letting somebody with more expertise and experience do it right the first time. This principle is in conflict with "when practical, do it yourself." There is a healthy conflict between these two rules. You should constantly be asking yourself, is it better to buy vs build?

4. When practical, do it yourself
I value generalists more highly than I do specialists. In technology, things change over time, and specialists tend to get stuck in a rut and then run over by the next big thing. Nothing beats "doing it yourself" to force you to learn something new. Don't know how to deploy a database? Do it. Don't go look for a DBA. Don't know how to work with mime types? Try it, don't just rely on the library that will do it for you. This is in contrast to another rule, "When possible, let somebody else do it." There is a healthy conflict between these two principles. This is because "buy vs build" is something you should always be dealing with.

3. Quantify
The cliche is sound: "If you want to manage something, measure it." Quantify your work to ensure that you measure your productivity and 'find the lever' to pull. Quantify your results to evangelize. Quantify your problems to see where to put your efforts for improvement. Quantify your results to see how your improvements are paying off, etc. Don't let quantification and measurement turn into your own private bureaucratic hell--often measurements are disposable. Know when to make quantification a recurring thing or simply a transient way to solve a problem.

2. Demand plans
The only real weapon we have against the swirling complexity of technical work is the principle of "divide and conquer" Any task or assignment you have should result in a plan that breaks the issue into manageable chunks. You and your group should be disciplined enough to plan your own work, and well trained enough to know how/when to do it.

1. Demand excellence
I gave a talk a while back on Software Testing and used this list for some ideas. I presented a Top 10 list of things I wanted people to keep in mind when testing software. And I ended with "#1 Demand Perfection." I used a picture of Steve Jobs in the slide as an example of a notorious perfectionist who's doing pretty well right now. Here's the deal: technology is about thousands and thousands of details. If you're sloppy, one of those details is going to sink you. Demand excellence in everything related to your technical work. Demand good people, demand good work. Don't settle for sub-standard work (have standards!). Communicate what's expected of your people (and yourself) and hold them (and yourself) to it.

Tickr by Dipity

Check out this cool tool by a childhood (okay college) friend: Dipity.

(BTW, love the RESTfulness)

Help promote it by using the Digg It button in the upper left.

Also go here: Dipity.

it's as easy as this for a Dipity view of this blog

Good stuff.