Peopleware

One of the Great Books in the management-of-software-development canon is Peopleware. I’ve quoted lighty from it before, and wrote a column about the book for InfoWorld a couple of years ago. It still sits within easy reach in my home office. Kevin Kelly features Peopleware in his Cool Tools blog, and does a nice job of pulling out some of the most relevant passages from the book, a book that’s full of all sorts of nuggets you can use in your management life. Some of my favorite parts of the book describe the concept of the “jelled team,” the team dynamic that we all aspire to attain. Here’s an excerpt about that:

A few very characteristic signs indicate that a jelled team has occurred. The most important of these is low turnover during projects and in the middle of well-defined tasks. The team members aren’t going anywhere till the work is done. Things that matter enormously prior to jell (money, status, position for advancement) matter less or not at all after jell. People certainly aren’t about to leave their team for a rinky-dink consideration like a little more salary.

There is a sense of eliteness on a good team. Team members feel they’re part of something unique. They feel they’re better than the run of the mill. They have a cocky, SWAT Team attitude that may be faintly annoying to people who aren’t part of the group.

. . . .

Once a team begins to jell, the probability of success goes up dramatically. The team can become almost unstoppable, a juggernaut for success. Managing these juggernaut teams is a real pleasure. You spend most of your time just getting obstacles out of their way, clearing the path so that bystanders don’t get trampled underfoot: “Here they come, folks. Stand back and hold onto your hats.” They don’t need to be managed in the traditional sense, and they certainly don’t need to be motivated. They’ve got momentum.

There’s also a lot of mundane material about the design of your office space and other things you might not think about, all supported by the authors’ research. Check it out.

Link: Cool Tools on Peopleware

Blown away (again) by Hack Day

I organized the second Hack Day at Yahoo! this past Friday, and it was extraordinary (check out some of the Flickr photos tagged “hackday”). Rather than write a long post with my own analysis, I’ll leave it up to some of the participants (it was extraordinary because of them anyway — I just try to lend minimal order to the beautiful chaos of it all):

Ed Ho, “Hack Day 2 at Yahoo!”:

Today is one of those days that makes me proud to be a Yahoo. The sheer number of hacks was overwhelming (again) and the quality of each improved as well. What I saw today was nothing more or less than I knew was possible when I joined Yahoo!. Yahoo! has an incredible number of smart programmers, and they are full of ideas and energy. The spirit had even captured our offices around the world and we had multiple hackers in other countries who had stayed late into the night (past midnight their time) just to have the chance to demo their developments to the rest of the Yahoo world. It was magnificent.

It was clear this time around that people had been thinking long and hard about their ideas and they were ready to execute. It’s personally satisfying to see programmers execute on such innovative ideas without PRD’s, MRD’s, Functional Specs and those obsolete remnants of waterfall development cycles. Powerful wizardry was going on at Yahoo today and I’m happy.

Matt McAlister, “Top 10 Reasons why Hack Day rocks”:

How do you explain the benefit of Hack Day in one sentence? Hack Day bubbles up significant yet tangible product strategy advances from across the organization while simultaneously feeding all that workforce optimization and touchy feely crap without paying a team of expensive Stephen Covey robots to tell you what you already know. It’s also super cheap.

Be sure to read the rest of Matt’s post — it’s good stuff about what real hands-on innovation means. (I have always absolutely hated the usual corporate team-building activities. I was always the one quietly scowling in the background as my co-workers role-played irrelevant situations while a professional “facilitator” asked me if I was having “fun.” Hack Day is very intentionally the antidote to that sort of pointless corporate activity. Bonus link on this topic: Douglas Rushkoff’s Fun AT work vs. Fun AS work.)

David Beach, “More on Yahoo! Hack Day 2”:

It was a huge success. There were so many hacks. Way more than last time. The quality and thinking behind the hacks was also improved. This tells me the initiative is working. People see the value of this and are taking advantage of the opportunity to express themselves in this manner. I believe that it’s one of the best things Yahoo! has done. At least internally.

The room was packed. I don’t think I can discuss specific hacks, but there were very clever innovations presented. I believe there were many more search hacks this time. Upcoming, Y! Widgets, Flickr, Autos, Shopping, 360, Local, Travel, WebJay, Maps, Messenger, Mail, and more were all represented and hacked in one form or another. I’m sure you’ll be seeing many of them appear live on the site in the near future. Actually it would be cool to somehow identify the new feature or service as something that was developed through Hack Day when it goes live. At the very least the orgs respective blog should blab about it.

I don’t know when the next one will be, but I’m preparing. I said earlier that I’m going to learn to program and I meant it. I taught myself pretty much everything I know this far, so why should I stop now? I’m starting with Ruby on Rails, because I hear it’s elegant and simple, plus I believe I can understand object oriented structured. I’m also going to brush up on web standards, CSS, and XHTML. It’s been awhile and much has changed since I every seriously had my hands on the stuff behind the page. First I believe that this is the only way to get some of my ideas out there, and second, I fit in with nutty programmers and designers more than I do with PMs. I’ve done the design thing, so now I’m going to try the other side. We’ll see how that works. L8r

(You go, Beach!)

JR Conlin, “Past our prime? Bullshit.”:

Had to get out of the Hack Day Presentation show. It was a packed room, with nearly 100 hacks being presented. This is stuff whipped up in a day, folks. Viable products that seriously kick ass. Add in the 70 or so from the one last quarter and… well… anyone who thinks we’ve got a bunch of lazy dinosaurs working here needs to have their head examined.

Seriously. Cool. Stuff.

(Hopefully a bunch will be ready to roll out soon.)

The coolest thing about Hack Day is that it goes far beyond one day — the kind of inspired development that is showcased on Hack Day is happening every day now (Take it from me — I stay extremely busy curating just a fraction of it). Hack Day is a day for the celebration of hackerdom, a tip of the hat to the artists among us who express themselves in code, a recognition of the pure joys of creation. Yes, hackers are artists. As I wrote in one of my old InfoWorld columns: ” If art is making order out of chaos, then software developers are artists at the highest level.”

Something very special is going on at Yahoo! and I’m absolutely giddy that I have something to do with it. It’s a lot of fun being continually amazed.

Update: Found an interesting article in the Sunday NYT: “Here’s an Idea: Let Everyone Have Ideas.” That’s the spirit of Hack Day. Key quote from the article:

According to Tim O’Reilly, the founder and chief executive of O’Reilly Media, the computer book publisher, and an evangelist for open source technologies, creativity is no longer about which companies have the most visionary executives, but who has the most compelling “architecture of participation.” That is, which companies make it easy, interesting and rewarding for a wide range of contributors to offer ideas, solve problems and improve products?

Yep.

Ruby vs. the enterprise

The whole “what does it mean to be ‘enterprise’?” brouhaha (see posts from Dare Obasanjo and David Heinemeier Hansson) over James McGovern’s post “More Thoughts on Ruby and Why it isn’t enterprise ready!” grabbed my attention for a few reasons:

  1. I used to write for an enterprise IT magazine, InfoWorld
  2. I was also CTO and had real day-to-day responsibilities, so I couldn’t get away with too much b.s. I had to live with what I wrote in a real environment and therefore couldn’t coast along on pure pontification.
  3. The combination of my roles in #1 and #2 led me to believe that quite often, the use of the term “enterprise” alongside many product names was a label used to part fools from their money.

My feelings on the matter are pretty well summed-up by a feature story I wrote for InfoWorld in 2004, “Top 20 IT Mistakes to Avoid.” I described the problem with the “enterprise” label in mistake number 20: “being a slave to vendor marketing strategies”:

When it comes to network devices, databases, servers, and many other IT products, terms such as “enterprise” and “workgroup” are bandied about to distinguish products, but often those terms mean little when it comes to performance characteristics.

Quite often a product labeled as a “workgroup” product has more than enough capacity for enterprise use. The low cost of commodity hardware — particularly when it comes to Intel-based servers — means that clustering arrays of cheap, workgroup hardware into an enterprise configuration is often more redundant and scalable than buying more expensive enterprise servers, especially when it comes to Web apps.

I didn’t write about programming languages back then, but the same principles apply. In my opinion, choice of programming language has almost nothing to do with being “enterprise ready” or not. Take a tour through any “enterprise” shop, and you are likely to find at least a few ill-conceived Visual Basic or Lotus Notes apps (both on legitimate “enterprise” platforms!) quite literally holding back the business, just begging to be replaced by a well-designed web-based app built on Ruby on Rails or PHP. I’ll take a well-designed RoR or PHP app over VB or Lotus Notes any day.

But let’s be fair. As RoR and PHP grow increasingly popular in enterprise settings, expect some really poorly-designed RoR and PHP apps to stink up the “enterprise” joint. As Frederick Brooks noted twenty years ago in his famous essay on software, there is no silver bullet. So, RoR, Java, PHP. . . whatever. Just find me some talented programmers and we’ll figure it out (ok, the Lotus Notes and VB guys would be kicked aside quickly, but you know what I mean).

Unfortunately, despite the beating he is taking in the blogosphere, I think James is probably just providing a realistic (if somewhat cynical) view into how lots of “enterprise” IT decision-making happens: lots of vendor FUD being fed to timid IT staffers who outsource their strategic thinking to Gartner/Forrester/etc. It’s not a pretty picture.

Yahoo! User Interface Library: amazing and free

In my very first days at Yahoo! working with the team that made the Local Events Browser demo using a bunch of Yahoo! APIs, I was really amazed at the Javascript/CSS talent assembled at Yahoo! As of today, a huge chunk of it is out there for anyone to use and the people who created all of it have started a blog. By any standard of openness, you have to admit that the release of the Yahoo! User Interface Library is incredible:

The Yahoo! User Interface Library is a set of utilities and controls, written in JavaScript, for building richly interactive web applications using techniques such as DOM scripting, HTML and AJAX. The UI Library Utilities facilitate the implementation of rich client-side features by enhancing and normalizing the developer’s interface to important elements of the browser infrastructure (such as events, in-page HTTP requests and the DOM). The Yahoo UI Library Controls produce visual, interactive user interface elements on the page with just a few lines of code and an included CSS file. All the components in the Yahoo! User Interface Library have been released as open source under a BSD license and are free for all uses.

If the technology itself wasn’t cool enough already, check out that generous BSD license — “free for all uses.” Getting your hands on the Y! UI Library is incredibly straightforward, too. I just downloaded the zip file and the zip file unzipped with no funny business.

I always like playing with real examples, and there are plenty of those (these are just a few that caught me eye — there is much more and all these are backed up by detailed documentation):

Aside from the UI Library, there’s the Yahoo! Design Pattern Library and an article on Yahoo’s Graded Browser Support by Nate Koechley.

All I can say is: have fun.

A coding Christmas

The holidays make me a little reflective, and this year I realized something about my career that really blew my mind — for the first time since 1994, I am not directly responsible for production code or production systems! I can’t recall any particularly ruined holidays in the past (except a vicious DOS attack on July 4th one year), but in my past work, there has always been at least the possibility that a major system would have a problem and I would be responsible for dealing with it (or at least making the dreaded call to the person on my team who would have to deal with it). Right now (though I am super-busy), I don’t even have root on a single system at work. I might be lucky in that regard this year, but I will raise a virtual glass to all the people who keep the systems running during the holidays. . . . you deserve our thanks. Here’s hoping that your pagers and cell phones are silent during this holiday season.

I’ll be using the holiday opportunity to catch up on some non-tech reading, movies, guitar playing, etc., but Im also planning to get some hands-on time with some of the geek stuff I’m been too busy to play with lately, namely: Greasemonkey (using Mark Pilgrim’s Dive Into Greasemonkey), the super-cool new JSON stuff we’re offering at Yahoo!, and some miscellaneous blog tweaks. Yes, “fun” comes in many different forms.

The efficacy of time-constrained hacking

Friday’s successful “hack day” experience is still fresh on my mind and a couple of blog posts popped up on my radar today that
reflected some of the philosophical underpinnings of our event. A post from David Heinemeier on the 37Signals blog (“Constraints breed breakthrough creativity“) pointed me over to Kathy Sierra’s post entitled “Creativity on speed.” I’ll quote the same section that David did because it’s so on the mark:

One of the best ways to be truly creative — breakthrough creative — is to be forced to go fast. Really, really, really fast. From the brain’s perspective, it makes sense that extreme speed can unlock creativity. When forced to come up with something under extreme time constraints, we’re forced to rely on the more intuitive, subconscious parts of our brain. The time pressure can help suppress the logical/rational/critical parts of your brain. It helps you EQ up subconscious creativity (so-called “right brain”) and EQ down conscious thought (“left brain”).

I totally agree, and I’m glad that Kathy stated is so well. I feel fortunate that early in my engineering career (both as manager and coder), I worked in environments (like a big sports site that I and my team built from the ground up) where we weren’t shipping software as much as we were shipping experiences around very specific — and totally inflexible — events. When you’re dealing with sporting events, you can’t not ship. The World Series, Olympics, and Super Bowl happen whether your code to provide the experience is ready or not. In that environment, I learned that sometimes you really have to ship. Sometimes there literally is no more time — no one is going to postpone the World Series because your code isn’t quite ready. I also learned that if you have the right team in place, the team often does its best work under this intense time pressure. That’s why I had a strong hunch that some really cool things were going to happen at our hack day, and they did. As David writes: “Don’t worry about having more time, build less software.” If you can’t build less software (e.g. you have to have scoreboards for the World Series), build what you have to build in the simplest possible way — another practice that was clearly in effect at our hack day.

The end of Kathy’s post suggests a compelling structure for a two-day hacking event that I’m going to file away for future reference:

It would be fun to see a combination camp where the first half of the weekend was about actually making something, solo or collaboratively, and the other half was about exchanging ideas with the other participants (including the things you made during the first half, and lessons learned).

Sounds like a great idea. . . .

(Also, don’t forget to read Kathy’s “Build something cool in 24 hours“)

We're hiring: join one of the most innovative teams at Yahoo!

If you thought the Event Browser was kick-ass like I did, here’s your chance to actually work with the team that built it. Ravi Dronamraju is adding to Team Edison (a team he put together) and just sent this job description over:

Do you have what it takes to build, prototype, innovate? Are you the über-geek who can think in multiple programming languages? Do you write more lines of code than email? Well, come join Team Edison at Yahoo! As part of the Search and Marketplace organization you will get a chance to put your brain through daily exercise of creativity and innovation, laying the foundation for Web 2.0 and beyond.

Ideally you thrive in a team-first environment, enjoy problem-solving and learning new technologies. You should have MSCS or equivalent with 5+ years of experience in building Web applications. At the core, you can express yourself competently in any of the following: Perl, PHP, C/C++, JavaScript and CSS. Solid understanding of technologies like HTTP, Apache, RDBMS/MySQL, Unix is a plus.

I work very closely with this team, so if you’re interested in this role, send me an e-mail with your resume (and tell me what you like to do and why you want to join the team). Please put “Team Edison position” in the subject line. My Yahoo! e-mail is chadd -AT- yahoo-inc -DOT- com. (No recruiters or agencies, please.)

Job descriptions rarely do justice to a position, so here’s my informal scoop. . . this team is heavily-focused on API development, both internal and external, so the work itself really couldn’t be more fun. The team is also small and nimble (very much on purpose) — a great group to join if you want to have an immediate impact (just ask Ed, who started working on the Event Browser on his second day, I think). And Yahoo! really is a great place to work — I’ve been here barely over three months now and it’s a blast. Come join the fun.