What's to SMIL About? 
SMIL is the acronym for "Synchronized Multimedia Integration Language" and it's pronounced "smile" by those in the know. SMIL is an Internet Standard XML-based language that is HTML-like. It's purpose is to enable the simple authoring of interactive audiovisual presentations. SMIL is for "rich media" presentations where there's a need to integrate streaming media with images and/or text.

In the past gathering information about SMIL required web searches and wading through a bunch of older pages, 'page not found' errors, or digging through the W3C reference pages and specifications. That's changed. There's now a fantastic book on SMIL 3.0 available.



This book has plentiful examples and explains SMIL in a clear and straightforward way. It's unusual in that it's in full color, which makes it much easier on the eyes.

Like HTML, SMIL controls the layout of the display - the spatial element of a presentation. HTML provides ways to do that - especially with CSS. Where SMIL shines is in the temporal control - the timing of video, graphics and text elements. SMIL provides ways to control the timing and synchronization of the media elements.

Adobe, Apple, RealNetworks, and Microsoft are all using at least parts of SMIL in their products - all around playlists and media playback control. SMIL is finding it's way into many products (like the Zune) as well. But one area that is really embracing SMIL is the field of Digital Signage. Several players in that space support now SMIL. For example, the Grass Valley/Canopus MediaEdge system and the IAdea XMP-300 both support SMIL. Premier Retail Networks (disclaimer: I work for them) operates one of the largest signage networks in the world and adopted SMIL as their playlist format several years ago. The POPAI Digital Signage Standards Group is considering SMIL as the basis for a common playlist specification.

SMIL is a foundational technology for tomorrow's media world. It's well worth learning about. The SMIL 3.0 book is a great way to get up to speed. I highly recommend it. This book is not cheap, but I promise you it will put a smile on your face about SMIL.




[ 1 comment ] ( 9 views )   |  [ 0 trackbacks ]   |  permalink  |   ( 3 / 140 )
The Power of... Saving!!! 
I broke my cardinal rule of saving my work every few minutes. The blogging software I use is nifty and all, but evidently does not save in process. I was editing in it's tool (being lazy instead of doing it in emacs like I normally would) and did not click the 'preview' button to cache it. Something odd happened and... lost.

So I'm sitting here feeling bemused since I know better. I lost 45 minutes of effort on a carefully crafted review of my new Blackberry Bold phone. I'm out of time now and too frustrated to re-create it, so I have to chalk this up to experience and move on.

Word to the wise - always save your work in process! Don't trust the tool to auto-save (emacs has spoiled me) - some tools won't.

On another note, I might be delayed in my trip to China due to new policies on getting a travel visa. I was supposed to pick my visa up today. We'll see if it's ready or if the new policy applies to applications in process.



[ 1 comment ] ( 16 views )   |  [ 0 trackbacks ]   |  permalink  |   ( 3 / 178 )
How to Build Fantastic Engineering Teams 
I'm very lucky to manage two outstanding Engineering teams. But it's not an accident that they are outstanding - it was the result of following some basic practices (and a bit of good luck). Here's what I think lead to success:

- Hire people smarter than yourself
- Let the team participate in the hiring process
- Set the bar high - demand excellence
- Don't keep a bad fit
- Share as much information as you can
- Look out for your staff

Hire people smarter than yourself

I'm a generalist and I do admit that I think I'm brighter than average. In a few areas I'm an expert. In others I know enough to be dangerous. But I'm seasoned enough to be completely convinced that there's a LOT of people much smarter than me. I try to hire those folks. And I have to let them be smart - which means listening to them and trusting them. Not blindly trusting them - I certainly challenge them to defend their opinions and designs... but I have to trust. Sometimes I have to make the command decision and over-rule them, but when I do I try to make sure I'm clear in my own head about my reasons. If my ego is involved I'm probably making a bad decision.

Let the team participate in the hiring process

Our interviews last at least 4 hours long. We're up front with candidates to expect that, and if it's going to go through lunch we feed the candidate too (more on that in another post). Each of my senior staff get 45 minutes to an hour with the candidate, and I try to make sure I get coverage across the two teams. We ask hard questions, of course, but we're just as interested in communication skills as we are with coding and analytical skills. There really is only one of two answers from each interviewer: yes or no. The key criteria is 'can this candidate carry his/her weight on the team?' If someone on the team is thumbs down about a candidate I have to seriously agonize if I decide to hire that person. I have done that - and almost every time it did not work out. I usually justified it with the notion that some productivity was better than none but that's not all that true. When it did not work there was usually a clean up of some kind or another that wiped away the apparent gains. As the team gets experience interviewing and seeing the results over time they get pretty good at it. And they gain good skills for their future careers (see about taking care of staff below).

Set the bar high - demand excellence

Mediocrity breeds bugs. Seriously. Excellence is the best antidote. We create a culture where we expect quality code - as much quality as the time allows (sometimes schedule trumps quality). We have formal pair-programming code reviews every week where someone is assigned to look at someone else's code for that week and provide a written summary of what was good, bad and ugly. There's nothing like knowing that your peer - who you darn sure respect and admire because she's smart and skilled - is going to look at your code and share her thoughts with the whole team. We do design reviews (but not as many as I'd like - back to that schedule thing) and try really hard to get the patterns right. We encourage dissent and questions, and when the team members all respect each others skills it really drives a better product.

The important thing here is that while I as Management place high expectations that's NOT what is creating the results. It's the high standards the team is setting on each other that creates the results. I'm just the catalyst. The goal is to create a culture of excellence.

Don't keep a bad fit

It does not take long to figure out who's a bad fit. There's a lot of things that may contribute to the poor fit - performance, personality, external factors - but if someone is not working out you are not doing anyone a favor by keeping them. It's not the lost productivity of that person as much as it's the destructive force on the rest of the team. The culture of excellence and respect I discussed above depends on everyone carrying their share. When the team starts losing that because someone is not a good fit it's the sole job of Management to fix that. It's better for the person to move on to somewhere that they can be a good fit, and it's exactly what will tell the team that the high standards are being upheld.

Share as much information as you can

No one does their best work in a vacuum. A highly functional team must know about the business, the customers, and the strategy for closing the gap between those two. The more they know the better they can make good decisions. They can think 'hey, if I write this class to be extensible it will only take me a few more hours and it would make it easy to add that feature that the account team was talking about maybe needing.' If they are hidden from that information they tend to build things the simplest and fastest way possible - in ways that might not be as easy to extend later.

Some Managers prefer to not bother their teams with this 'extra' information. They think it's just distracting - or in worst case scenarios these managers think that information about the business is their currency of power somehow - as if information control was the key to how to manage. I'm the radical opposite, and I think that the more information a team has the better they perform (if used along with the culture of excellence).

A side effect of this is that I have to be radically involved in the business side of things. I have to visit customers and talk to real users. I have to listen to product management and compare what they are saying to what I heard my customers saying. I have to ask questions like 'what are your pain points and what feature would make that go away?' This increases my work, but I think it's a fundamental part of my job. Without this I don't have the information to share with the team that leads them to a clear understanding of the needs of the business.

Look out for your staff

Most folks can tell if you really have their interests at heart. I make it a point to know what the career goals of my staff are. Do they want to move on a technical track or get into management? Do they want to get a certain certification? Learn a new language? Build communication skills? It's usually possible to find assignments that will build folks towards what they want - and get them the needed exposure to the right folks in other departments in Upper Management - if you know what their goals are. I've promoted heavily from within and worked hard to build the skill sets of my staff through fomal training, paying for books, brown-bag lunches, and practical on-the-job training. Smart, capable people will respond this genuine concern in very positive ways. Today, for example, one of my staff was on PTO but he spent the morning troubleshooting a problem at a customer site. He figured he wasn't leaving town until later in the day and he wanted to see it fixed. We take care of him, and he took care of us. My staff has responded with this kind of professionalism and extra effort over and over. I believe they do it partly because that's the kind of people they are, but mostly because they believe it's a two way street.

None of this is new or unique. I've built these principles over my career both watching good managers and building other great teams (especially the one I built at Quicknet). But I've also read a lot of material, both in print and on the web. Joel Spolsky writes of some of this in his excellent Guerrilla Guide to Interviewing. I just read a short article about how Rockfish Interactive has created excellence. That's a company I'm watching closely.

I could spend 10 minutes and probably track down ten more good examples - but I bet you readers have some favorites to share. I'd sure like to read them.



[ add comment ] ( 2 views )   |  [ 0 trackbacks ]   |  permalink  |   ( 3 / 140 )
Oceanography, or, "You really lived on a ship?" 
I've had some really good gigs in my career. One that gets the second most comments is my year on the Research Vessel Atlantis with her usual cargo the famous research submarine DSV Alvin. The most comments is my time on a US Navy Submarine, but that will have to wait for another post.

I realized one day that I needed to find a new job. It was early 1996 and I'd been with PG&E for about 5 years. It was clear that deregulation was going to eliminate ratepayer funded Utility R&D - and since that was where I worked, if I wanted to avoid working with really high voltage (12000 or 21000 volts) I should probably look around. While out photo shooting day around the Benicia Bridge (where I got some shots of the Glomar Explorer - a subject for another post sometime) I had the realization that my Navy background and love of the sea - and my deep skills in software development, data acquisition, networking and instrumentation - made me ideal for work in oceanography.

When I went home I logged onto the Internet (dialup, 33kbaud, to crl.com) and did a search. I found a listing for a job with Woods Hole Oceanographic Institute on the brand new Research Vessel Atlantis. I was so excited I drove to Costco to buy a fax machine to send my resume right away.

A few days later they called me and set up an interview with the Director of the Deep Submergence Lab Barry Walden. The interview started unlike any I have ever had.

"Are you any damn good?" he asked. His first words to me, literally.

"Yes, I am" I answered.

"OK, you're hired."

I was a bit stunned. I was silent.

"Oh, I guess I better ask you some questions" he continued. He grilled me on Linux, RS-485 communications, networking, data acquistion, and on some oceanographic equipment that I'd read up on but had to admit little practical experience (we'd used some of it on my Navy submarine, but that was not my specialty). He commented that HR would be in touch and that they would probably fly me out for an in-person interview. We cordially ended the phone call and I felt good about it.

A few days later I got home late and found a large manilla envelope in my mailbox. Inside was a ticket to get me to Pascagoula Mississippi - 15 days later! And a nice letter with "Welcome to Woods Hole" kind of language.

I woke up at 5am to call the East Coast when they opened. "Are you offering me a job?" I asked, stunned.

"Oh yes, can you meet the ship when it leaves the shipyard?" she asked. I mumbled that I would try.

Of course, I did. I sold everything I owned except what would fit in a 5x5 foot storage unit and two huge duffel bags. I sold my car, found a tenant for my condo, gave my cat back to my ex-wife, and got on a plane.

And began a great year of adventure. When I got to the ship all the computers were still in their factory shipping boxes. Huge unterminated cable bundles were looped on the floor spooling up into the overhead (ceiling for you landlubbers) in every space (room). Nothing was hooked up. I was deeply involved in every aspect of the bring-up of the entire data system. I was in heaven.

I lived onboard for 4 months, then got 2 months vacation. Then repeat. I went from Missippi around Florida, to New York Harbor (sailing past the Statue of Liberty was HUGE life thrill), to Alexandria (where I got to see the Picasso exhibit at the National Gallery and then bar hope through Georgetown until far too late), a month in Woods Hole, Bermuda, the Azores, Barbados, a trip through the Panama Canal that I took vacation during much to my regret, San Diego, Manzanillo Mexico, Astoria Oregon... and I was in the water ever day helping to launch the Alvin. I wrote code to make science gear work. I ran the ships network. I made the Linux boxes sing. And most importantly, I ran the system that got email across the Inmarsat Satellite. I owned everything on the ship that a normal sailor would not. If it didn't look like it belonged on a ship, I was probably the guy who had to make it work with whatever funky gear the monthly science team would bring on-board.

I met amazingly fascinating Scientists who are digging into the puzzles of alien life on Earth. Entire ecosystems live around underwater volcanoes - no light, therefore no photosynthesis. Temperatures above 500F. Pressure that would crush a human. But life thrives there - crabs, tube worms, clams, shrimp, on down to bacteria. How? It was fascinating. The amazing Scientists studying the geology, biology, chemistry... they were fascinating themselves. They were all among the very elite of the smart Scientists that had those interests - they had to be. Competition for time on Alvin was intense.

It was one of the best years of my life. If we ever have an adult beverage together I can tell you more stories - especially about the large amount of adult beverages I consumed that year (merchant marines and the Alvin crew - two groups who definitely know how to PARTY). But then I met Erin, and fell madly in love, and walked away from all that... and now we have two great kids and a great life and I make a LOT more money than they pay for research science. I'm happy for both transitions: that I got to experience it, and that I found my next life and family.

But it was a great year, and it's a great story. I hope it made you smile. It sure made me smile remembering it all.





[ add comment ] ( 4 views )   |  [ 0 trackbacks ]   |  permalink  |   ( 3 / 177 )
Wasted Opportunity 
The Giants lost a stinker to the Dodgers tonight - and they deserved to. You can't load the bases that many times, fail to score, and expect to win. You just can't. And the bullpen collapsed again in the 9th. I just hope this isn't a sign of how the season will play out. I'm an eternal optimist though. I still say good pitching will beat good hitting.

On a different note, I'm using Twitter now. I'm a johnny-come-lately to that too, but for the longest time I just didn't see the point in sending text messages to the world that I was going to get a coffee, or head home, or whatever. For one thing, why pay for all those messages? But twitter can be a form of an alert service of sorts - you can choose how often you send tweets - and send them from a web-enabled device or your PC and not via SMS. I think it's becoming a key part of the new Internet.

I've used LinkedIn for quite a while now. It's been more than useful to stay in touch and make contact with folks I needed in business. It's to business what Facebook is to friends.

These three - Twitter, LinkedIn, and Facebook - seem to me to be the bases loaded. Blogging is the base hit that brings those runs home. Unlike the Giants tonight, I'm not going to waste the opportunity.







[ add comment ] ( 3 views )   |  [ 0 trackbacks ]   |  permalink  |   ( 3 / 153 )

<<First <Back | 1 | 2 | 3 | 4 | 5 | Next> Last>>