Random Thoughts on Management

I have ended up managing people at the last three places I’ve worked, over the last 18 years. I can honestly say that only in the last few years have I really started to embrace the job of managing. Here’s a collection of thoughts and observations:

Growth: Ideas and Opinions and Failures

Expose your team to new ideas and help them create their own voice. When people get bored or feel they aren’t growing, they’ll look elsewhere. Give people time to explore new concepts, while trying to keep results and outcomes relevant to the project.

Opinions are not bad. A team without opinions is bad. Encourage people to develop opinions about everything. Encourage them to evolve their opinions as they gain new experiences.

“Good judgement comes from experience, and experience comes from bad judgement” – Frederick P. Brooks

Create an environment where differing viewpoints are welcomed, so people can learn multiple ways to approach a problem.

Failures are not bad. Failing means trying, and you want people who try to accomplish work that might be a little beyond their current reach. It’s how they grow. Your job is keeping the failures small, so they can learn from the failure, but not jeopardize the project.

Creating Paths: Technical versus Management

It’s important to have an opinion about the ways a management track is different than a technical track. Create a path for managers. Create a different path for technical leaders.

Management tracks have highly visible promotion paths. Organization structure changes, company-wide emails, and being included in more meetings and decision making. Technical track promotions are harder to notice if you don’t also increase the person’s responsibilities and decision making role.

Moving up either track means more responsibility and more accountability. Find ways to delegate decision making to leaders on the team. Make those leaders accountable for outcomes.

Train your engineers to be successful managers. There is a tradition in software development to use the most senior engineer to fill openings in management. This is wrong. Look for people that have a proclivity for working with people. Give those people management-like challenges and opportunities. Once they (and you) are confident in taking on management, promote them.

Snowflakes: Engineers are Different

Engineers, even great ones, have strengthens and weaknesses. As a manager, you need to learn these for each person on your team. People can be very strong at starting new projects, building something from nothing. Others can be great at finishing, making sure the work is ready to release. Some excel at user-facing code, others love writing back-end services. Leverage your team’s strengthens to efficiently ship products.

“A 1:1 is your chance to perform weekly preventive maintenance while also understanding the health of your team” – Michael Lopp (rands)

The better you know your team, the less likely you will create bored, passionless drones. Don’t treat engineers as fungible, swapable resources. Set them, and the team, up for success. Keep people engaged and passionate about the work.

Further Reading

The Role of a Senior Developer
On Being A Senior Engineer
Want to Know Difference Between a CTO and a VP of Engineering?
Thoughts on the Technical Track
The Update, The Vent, and The Disaster
Bored People Quit
Strong Opinions, Weakly Held

Patterns of Effective Teams

I have been lucky to build software products for a few different companies, each with a distinct culture. It’s help me form opinions about people, tools and processes that make teams effective at shipping software products.

Who makes up a software product team? Mileage may vary, but I like to include:

  • Developers
  • Testers
  • UX Designers
  • Project Managers
  • Product Managers
  • Support

Lots of companies organize people into functional groups: All the developers in a group, all the testers in a group, all the designers in a group… and so on. This doesn’t make it easy to ship software. It can create walls and make it harder to communicate. You also lose the “team” feeling, as well as the focus and drive that comes from that.

Product-centric teams seem to be more effective at shipping. These multidisciplinary teams embed members from the various groups on the team, all working together to create and ship a software product.

Over the years, I’ve seen productive teams using a few basic concepts. Some are process related, some can be aided by tools, but most deal with relationships between people:

  • Trust each other: Each member has a role, and members need to trust in each other’s ability to perform.
  • Talk to each other: Lots of open communication is important. The team is a safe place, so there are no stupid questions. Meet as a group often to discuss progress.
  • Support each other: You win and lose together. Help others, even if not asked directly.
  • Be passionate: The team needs to be passionate about succeeding and hungry to ship a great product. There will be rough spots on the way. There always are, but the team needs that passion to be able to power through.
  • Move as a single, focused group: Speed is important. Decisions, implementation, feedback – all need to happen ASAP. Distractions kill speed.
  • Plan work as a group and document the plan: If everyone is part of the planning, everyone is committed to the plan. Keeps the team focused.
  • Create a roadmap: You need a Big Picture too. What’s the vision and strategy? It helps set the tone for everything else.
  • Break work into small tasks and track the tasks: Small tasks are manageable and trackable. Small tasks are easy to scope and keeps the team focused. Watch out for scope creep.
  • Create milestones and track progress: Deadlines are a good thing, even if just internal. Forward progress is essential for shipping and milestones are great for tracking progress.
  • Adjust as needed: Don’t be afraid to adjust anything: schedule, milestones, tasks. You are collecting data every day. Use it to make informed decisions ASAP. Triage your work often.

I like to keep things lightweight. This includes tools and processes. Focus more on your product and the work at hand. Processes and tools can be distractions. The best ones are those that stay out of your way.

Update: Taras reminded me indirectly about the importance of passion, so I added it to the list.

Perils of the viewport meta tag

Apple introduced the viewport meta tag in mobile Safari to help web developers improve the presentation of there web pages on the iPhone. We added support for the viewport tag in mobile Firefox for the same reasons.

The viewport tag allows web developers to set the width, height and scale of the browser area used to display web content. However, some websites are not doing a good job configuring the viewport tag and it affects the presentation in Firefox.

When setting the width or height, developers can use a fixed number of pixels or use the constants: device-width and device-height. The iPhone is 320px wide in portrait and 480px wide in landscape. Other devices have different screen sizes. It seems the “width=320″ is a popular fallback though. See how Facebook and DeviantART display in Firefox on the N900 (480px in portrait and 800px in landscape):

touch.facebook.com
fennec-viewport-facebook

deviantart.com
fennec-viewport-deviantart

Don’t get me wrong. I like “touch-friendly” web pages on my mobile device. However, the iPhone is not the only mobile device out there. If a web developer has gone through the effort to make a “touch-friendly” web page, please configure your viewport to work in other devices. It’s easy!

Day Dreaming about Web Storage

Recently, we have seen good discussion on the W3C Web Storage specification. There has been some recent push back on the use SQL, in particular “SQL as SQLite defines it”, in the specification. Counter proposals have been popping up using JavaScript-ish APIs, many using JSON. Some of the APIs store the data as a JSON document or blob, even using the HTML5 localStorage/globalStorage system to persist the data. BrowserCouch and TaffyDB are two nice examples. Both are very JavaScript-oriented, client-side and offer some very nice functionality.

I think the functionality of a good JavaScript storage API will always be the most productive approach to storage, in much the same way we see JavaScript DOM libraries used everywhere. At the same time, I don’t think we should standardize functionality that should be in a JavaScript library, just as jQuery, dojo, YUI or any other DOM library is not the HTML DOM standard. I like having the flexibility of using different libraries.

We already have document-style (blob) storage in a specification and we have JavaScript libraries to make using document storage easy and convenient. The question I see is whether we want relational (tables/records) style storage. Many new JavaScript libraries would blossom from such a storage system and developers would have more choice.

Document and relational storage each has it’s own pros & cons. I’d like to see more discussion about the pros & cons, about performance and about what parts of the storage mechanism browser vendors should be focusing on to make JavaScript storage libraries performant. I’d like to see less bikeshedding on JavaScript storage APIs. I’d really love to see less talk of putting features in a specification that should be in a JavaScript library.

Update: Chris Blizzard’s post discussing Google’s O3D & Mozilla’s Canvas3D is great comparison of high-level vs. low-level APIs. Just replace “3D Canvas” with “Web Storage”.

On Searching and Distributing

Searching

Adobe has been creating a buzz lately with the announcement that Google and Yahoo will be using a specialized Flash player to allow indexing Flash content. This is appears to be big news for the Flash world, even though Google was scraping text content previously (and this still only applies to text content). Now, search engines (or at least Google and Yahoo) will have more context for the text.

I am left wondering if other search engine providers will get access to the proprietary, search-enabled Adobe Flash player? Also, even though some have stated that this new search capability puts Flash on the same level as HTML, I wonder how linkable the Flash search hits will be? Yes, I am referring to the Flash “Bookmark Problem”. Just because Google gives me a link to some text it found in a Flash application, can I jump directly to it? Without doing any special coding?

Distributing

While I am poking Adobe, I noticed that the new Adobe Reader 9 release will include Adobe AIR. Hmm, does Reader use AIR? or is this yet another attempt by a software vendor to stuff unwanted, unneeded software on my machine? Oh, I see. AIR is needed to run an AIR application to allow me to use the Acrobat.com website. I’m still calling shenanigans.

So, 33.5MB download (just download) for Reader 9. Goes up to 52.4MB if you choose to download the “eBay desktop” application too, and it’s checked by default. How about letting me skip the AIR download too? Didn’t we just go through this with Apple?

Do You Smell Something?

Oh yeah, it’s this crappy post from ReadWriteWeb on the new Google Maps Flash API. I have no problem with a Flash API for Google Maps. Power to the people! But I did have a massive gag reaction to the following fairy tale:

A substantial portion of the web’s creativity can be found in the Flash developer community. Adobe’s AIR platform is one of the hottest development environments in the consumer market today and is being deployed with increasing frequency in the enterprise as well. Live Google Maps in Flash are likely to be used in even more creative ways than the existing javascript API has been. Javascript can be used in AIR but it’s rarely used as attractively as Flash often is.

It doesn’t end there, although my ability to keep food down did:

Throw some Flash Google Maps into the mix and things are liable to really get interesting.

  • Are you kidding me? Hey, I’m glad Flash is open, but I have no love for an alternate Web.
  • More creative ways than the JS APIs? Haven’t seen any creative uses of JS have you?
  • One of the hottest development environments? For making Twitter clones?

The rest of the post is great!

RIA is Dead! Long Live Web Applications

RIA (the acronym) has jumped the shark. I find that I can no longer use RIA to describe anything anymore. The definition has been watered down and twisted to the point that nearly any application can be called RIA.

I first noticed this trend last year. Adobe and Microsoft evangelists started ping-pong blogging about what RIA meant. Scott Barnes of Microsoft even went so far as to redefine the acronym, from “Rich Internet Application” to “Rich Interactive Application“. That, along with some other “we can be better than the Web” posts caused Dare Obasanjo to create a great post: If you Fight the Web, You Will Lose. I also liked Anil Dash’s “ice cubes in water” analogy. I can see why Microsoft is pushing Interactive and not Internet, which would necessitate making Internet applications.

Fast forward to the present and Ryan Stewart’s post on the ever changing definition of RIA:

Let’s first bite off the question of what desktop applications constitute RIAs

None. RIA isn’t about desktop applications

I think things like Mozilla Prism, Adobe AIR, Curl Nitro, and Microsoft WPF are all examples of desktop RIAs.

Desktop RIA? WPF? WTF? Sounds like an oxymoron to me

In general, I think RIAs as a whole should be:
* Using web technologies

Wait for it. He’s softening you up for what’s next.

I also think that the best RIA platforms should have:
* A good designer/developer workflow story
* At a technical level business logic and user interface should be very cleanly separated so that the UI can easily be enhanced.

I fail to see how these relate to RIA, but I do see how it relates to Adobe products. Adobe products that “use web technologies”, but not the web itself. Maybe RIA means “Really, It’s Adobe”

It’s no wonder people are confused by RIA discussions. I think I’ll stick with web applications from here on out. RIP RIA.

Bubblemark is an RIA Benchmark?

The Adobe RIA crowd have been causing some echos in the chamber lately over Bubblemark, an animation benchmark originally released over a year ago. Personally, I have no real skin in the game, but a game it is. Some Flash developers were curious about variations in the results when run on different browsers, platforms and in the AIR runtime. It makes for some interesting reading and I came away with a better understanding the variations, browser limitations and timer mechanisms.

What caused me to gush milk out my nose was reading that this benchmark appears to be some kind of de facto standard for RIAs. No way! Someone is going to have to explain, speaking slowly and using big letters, to me how rendering an bunch of bouncing balls and calculating a framerate from the bouncing balls is a benchmark for RIAs. I guess if your RIA is an animation of bouncing balls (or non-balls too, I guess), this test has you covered. Thankfully, I’m not the only one. The Flash guys have more than a few gripes with the test. Sean Christmann sums up my biggest gripe:

The test just moves balls around! This is my biggest beef with the benchmark because it only tests one simple aspect of the rendering engine in these technologies, which is bitmap translation. How do bitmaps moving around the screen tell you anything about the capabilities of the respective technologies? Do the JavaFX guys really think optimizing this usecase will make their technology relevant? The only thing Bubblemark will tell you is which runtimes might best handle bitmap particle emitters….thats about it.

Instead, I’ll offer that the Bubblemark test has value in that many different technologies have implemented the test. Therefore, it provides some level of benchmark for how different technologies can be optimized to implement the test. Of course, I could be way off base here and the RIA of which they speak is actually “Really Interesting Animations.” If so, whoops, my bad.

I Call Shenanigans!

Zoho’s recent blog post about why they used JavaScript and not Flash when building their offline version of Zoho Writer has led to some interesting but somewhat predictable responses [1] & [2]. I could have fallen into a predictable (but not necessarily interesting) response myself, but didn’t. Until I saw Ryan Stewart post the following:

I don’t think it’s an accident that Zoho and Buzzword have such different design goals or that Flex applications generally tend to look more sophisticated than Ajax applications.

That quote (and the post) seem to suggest that AJAX webapps are less usable, less sophisticated and, generally, not as pretty as their Flex counterparts. Likely not Ryan’s intent and I did say “seem to suggest” right? I usually don’t define usability based on how an application looks, but on how productive I am using the application or how easy I can learn the application. Unfortunately, some applications try to get by on looks alone. I try to see the inner beauty.

Of RIA, Open Web and Plugins

Adobe’s Ryan Stewart has a post on the friction between Open Web advocates and “RIA vendors”. I think Ryan does a good job describing the work being done at Adobe (and Microsoft) to become active in a larger ecosystem, namely open source and cross-platform. There are a couple bits I want to respond (emphasis mine):

I think it’s indicative of wider problems between the “open web” and RIA vendors. The basic issue is that everyone’s too combative. I wish more open web people would look at what both Microsoft and Adobe are doing and see that all in all, the RIA solutions are becoming more open, not less. In fact, I’d argue that RIAs have moved the entire web in a more open direction.

I think Ryan’s use of the term “RIA” to indicate a “proprietary vendor plugin” will cause confusion. Rich Internet Applications can be created without the need for proprietary vendor plugins. Also, what Adobe has done around open sourcing parts of their plugin system has been welcomed by everyone. However, there are still large chunks of closed source and encumbered file formats that work against the Open Web.

I’m not sure if RIAs will ever be as fully open as the open web advocates want, but think how far applications in the browser have come (as far as openness) since the days of ActiveX enhancements in IE.

As I have stated, RIAs can be fully open and, as a card carrying Open Web advocate, those make me happy. However, how far have Adobe and Microsoft come from the days of ActiveX vendor plugins? Last time I checked, ActiveX was still the technology of choice for Flash and Silverlight on IE. Honestly, even if Flash and Silverlight were completely open source, the fact they are plugins and not native Web standards will be a stumbling block for many Open Web folks.

They’ve [Flash and Silverlight] pushed the web forward in a way that it seemed the open web groups couldn’t (video, vector graphics, easy cross platform/browser development).

Yes, they have pushed the Web forward, I’ll admit that. The resurgence of SVG and the new <video> & <audio> elements are evidence of that. But then Linux is a platform too, and I suppose that Mozilla could market Firefox as the one, true cross platform Web platform – but we don’t. We encourage choice and competition. We want developers to have choice too and not be locked into a single stack. Let me know when Flash can run a Silverlight application.

Mike Shaver responds in a comment to the post.