Posted on

On the Merits of Bug Tracking

Yes, I wrote a whole blog post about bugs. Bugs are boring and managing bugs can be mind-numbing. However, all software has bugs and managing those bugs helps you understand the health and quality of your software, helps you understand the risk associated with new features, and helps you figure out if you’re ready to ship or not.

At some point in our careers, developers have a desire to fix all bugs before releasing. This might work for small projects or in situations where you don’t have a lot of testing. For larger projects, especially as projects mature, it’s just not possible to fix all the bugs before releasing an new version, so it’s time to manage your backlog. Creating good bugs helps reduce the time it takes to manage and fix bugs.

  • Summary – Be explicit and contextual. This is the text that shows up in bug lists. Something too vague, like “Crash when posting” will require people to always open the details to figure out the context.
  • Steps to reproduce – Be clear and precise. What was the expected behavior vs actual behavior? Does it happen all the time or is it intermittent and hard to reproduce?
  • Description – Is the bug a crash, broken behavior, performance or regression? Make sure you add these details. For UI related issues, add a screenshot or video. Can you provide a minimal test case for the issue?

You can’t fix them all, so it’s time to triage. Bug debt contributes to the risk of shipping, so you need to manage the set of bugs like many other aspects of your development process. Don’t be frightened by a large quantity of bugs in your backlog. It just means people are testing your software, which is a good thing.

Bug triage is the process of going through the list to find bugs that need assistance, escalation, or follow-up. This is usually done in a group, but sometimes individually to clean incoming bugs. Through this process the nastiest, riskiest bugs are identified.

  • Prioritize – Don’t guess. Use a decision tree, or some other system, to determine a real priority.
  • Estimate – Don’t guess. If it’s too hard to figure out, you should break the work up into smaller tasks. Link those sub-tasks back to the original bug.
  • Adjust – Bug metadata is not set in stone. Situations change over time, so can the bug priority.

Bugs have their own social networks. New code always spawns bugs so link those regressions back to the source feature or fix. Link duplicates back to the original issue. Sometimes those are not 100% duplicates and it’s good to verify all the duplicates are really fixed. Link code landings back to bugs. Code archeology is a real thing so make it easier by creating a map of bugs to code. You should be able to start with a line of code and easily find out why/when it was added. You should also be able to start with a bug and find the code used to fix the issue.

The bug metadata should be factual, but separate from the decision to ship. Don’t lower a bug priority just to make the decision to ship easier for someone else. Let those people own the decision to ship with a known level of quality.

Triage helps keep bug status up to date, which is how real-time roadmaps are created. In a time-oriented release schedule, release roadmaps can change because some features aren’t ready to ship. When the enough code lands and regressions that need to be fixed are fixed, a feature is ready to ship. Triaging bugs and managing feature status frequently allows you to be proactive about changes in roadmaps, not reactive.

Posted on

Pitching Ideas – It’s Not About Perfect

I realized a long time ago that I was not the type of person who could create, build & polish ideas all by myself. I need collaboration with others to hone and build ideas. More than not, I’m not the one who starts the idea. I pick up something from someone else – bend it, twist it, and turn it into something different.

Like many others, I have a problem with ‘fear of rejection’, which kept me from shepherding my ideas from beginning to shipped. If I couldn’t finish the idea myself or share it within my trusted circle, the idea would likely die. I had most successes when sharing ideas with others. I have been working to increase the size of the trusted circle, but it still has limits.

Some time last year, Mozilla was doing some annual planning for 2016 and Mark Mayo suggested creating informal pitch documents for new ideas, and we’d put those into the planning process. I created a simple template and started turning ideas into pitches, sending the documents out to a large (it felt large to me) list of recipients. To people who were definitely outside my circle.

The world didn’t end. In fact, it’s been a very positive experience, thanks in large part to the quality of the people I work with. I don’t get worried about feeling the idea isn’t ready for others to see. I get to collaborate at a larger scale.

Writing the ideas into pitches also forces me to get a clear message, define objectives & outcomes. I have 1x1s with a variety of folks during the week, and we end up talking about the idea, allowing me to further build and hone the document before sending it out to a larger group.

I’m hooked! These days, I send out pitches quite often. Maybe too often?

Posted on

Firefox on Mobile: Browser or App?

It seems common for people have the same expectations for browsers on Mobile as they do on Desktop. Why is that? I’d rather create a set of Mobile-specific expectations for a browser. Mobile is very application-centric and those applications play a large role in how people use devices. When defining what success means for Firefox on Mobile, we should be thinking about Firefox as an application, not as a browser.

Navigation

Let’s start with navigation. On Desktop, navigation typically starts in a browser. On Mobile, navigation starts on the device home screen. The home screen holds a collection of applications that provide a very task-based workflow. This means you don’t need a browser to do many tasks on Mobile. In fact, a browser is somewhat secondary – it’s where you can end up after starting in a task-specific application. That’s the opposite of Desktop.

One way we started to optimize for this situation is Tab Queues: A way to send content to Firefox, in the background, without leaving your current task/application.

Another way to fit into home screen navigation is to launch favorite websites directly from home screen icons. On Android, Chrome and Firefox have supported this feature for some time, but Google’s Progressive Web Apps initiative will push the concept forward.

If the home screen is the primary way to start navigation, we can add more entry points (icons) for specific Firefox features. We already have a Search activity and we also have access to Logins/Passwords. Both of those could be put on the home screen, if the user chooses, to allow faster access.

Unsurprisingly, a correlation between applications on the home screen and application usage was a key takeaway from a recent comScore study:

“App usage is a reflexive, habitual behavior where those occupying the best home screen real estate are used most frequently.”

Content and Tasks

Creating a path to success means looking for opportunities that we can leverage. Let’s look at analyst reports for situations where browsing is used more than applications on Mobile:

  • Accessing news and information sources
  • Research tasks and cross-brand product comparisons
  • Retail, travel and shopping tasks

If this is the type of content people access using browsers on Mobile, Firefox should be optimized to handle those tasks and workflows. It’s interesting to think about how we could leverage Firefox to create solutions for these opportunities.

What if we were building a native application that allowed you to subscribe to news, blogs and articles? Would we create a view specific to discovering content? Would we use your browsing history to help recommend content?

What if we were building a native application designed to make researching a topic or product easier? How is that different than a generic tabbed browser?

Some ideas might end up being separate applications themselves, using Firefox as a secondary activity. That keeps Firefox focused on the task of browsing and viewing content, while new applications handle other specific tasks and flows. Those applications might even end up on your home screen, if you want faster access.

Retention and Engagement

Mobile applications, including browsers, struggle with user retention. Studies show that people will try out applications an average of 4.5 times before abandoning.

Browsers have a larger reach than applications on Mobile, while applications are awesome at engagement. How does a browser increase engagement? Again, we should think like an application.

What if we were building a native application that could save links to content? What other features would we add? Maybe we’d add reminders so people wouldn’t forget about those recently saved, but never viewed, links to content. Browsers don’t do that, but applications certainly do.

What if we were building a native application that allowed people to view constantly changing news, sports or retail content? We could notify (or badge parts of the UI) when new content is available on favorite sites.

Metrics

We should be measuring Firefox as an application, and not a browser. Marketshare and pageviews, compared to the OS defaults (Safari and Chrome), may not be the best way to measure success. Why should we measure our success only against how the OS defaults view web content? Why not compare Firefox against other applications?

Research tells us that anywhere from 85% to 90% of smartphone time is spent in applications, leaving 15% to 10% of time spent in browsers. Facebook is leading the pack at 13%, but the percentages drop off to single digits quickly. There is certainly an opportunity to capitalize on that 15% to 10% slice of the pie. In fact, the slice probably ends up being bigger than 15%.

time-spent-us-apps-2014

Treating Firefox as an application means we don’t take on all applications, as a single category. It means we take them on individually, and I think we can create a pretty solid path to success under those conditions.

Posted on

Is Ad Blocking Really About The Ads?

Since Apple released iOS9 with Content Blocking extensions for Safari, there has been a lot of discussion about the ramifications. On one side, you have the content providers who earn a living by monetizing the content they generate. On the other side, you have consumers who view the content on our devices, trying to focus on the wonderful content and avoid those annoying advertisements.

But wait, is it really the ads? The web has had advertisements for a long time. Over the years, the way Ad Networks optimize the efficiency of ad monetization has changed. I think it happened slowly enough that we, as consumers, largely didn’t noticed some of the downsides. But other people did. They realized that Ad Networks track us in ways that might feel like an invasion of privacy. So those people started blocking ads.

Even more recently, we’ve started to discover that the mechanisms Ad Networks use to serve and track ad also create horrible performance problems, especially on mobile devices. If pages load slowly in a browser, people notice. If pages start consuming more bandwidth, people notice. If you provide a way to quickly and easily improve performance and reduce data usage, people will try it. I’d even posit that people care a lot more about performance and data usage, than privacy.

Even if you don’t care about the privacy implications of tracking cookies and other technologies sites use to identify us online, you might want to turn on Tracking Protection in Firefox anyway for a potential big speed boost. – Lifehacker

Is there a way for Ad Networks to clean up this mess? Some people inside Mozilla think it can be done, but it will take some effort and participation from the Ad Networks. I don’t think anyone has a good plan yet. Maybe the browser could help Ad Networks do things much more efficiently, improving performance and reducing bandwidth. Maybe people could choose how much personal information they want to give up.

If you fix the performance, data usage and privacy issues – will people really care that much about advertisements?

Posted on

Random Thoughts on Engineering 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: Each Engineer is 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

Posted on

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.

Posted on

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!

Posted on

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”.

Posted on

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?

Posted on

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!