I left because of a general lack of interest in doing anything substantial to improve the Triage process on BMO outside the QA community and a few others. Triage as we know it today is NOT ready to handle the Rapid Release process.

Tyler then points out that:

In Spring 2010, we hit roughly 13,000 UNCO bugs in the Firefox product on BMO. 13,000!!! We currently have 5934. This is several thousand contributors that we have told “Thank you for filing a bug report with us. We don’t really care about it, and we are going to let it sit for 6 months and just ask you to retest when you know it isn’t fixed, but thank you anyway. Oh, and Mozilla is run by the community.” Even though nobody means this, that is what we tell an end-user who just submitted their first bug and is ignored.[italics mine]

Mozilla behavior toward this ancient feature request is illustrative:

• The request was filed in 1999 (12 years ago)!
• Numerous offered patches,
• A plugin to workaround this issue,
• Accounts that offered patches are labeled as “Please Ignore This Troll (Account Disabled)”

Wow nothing says Go Away quite so effectively as being labeled a troll or being ignored.

Questions

1. How many reported issues are latent security problems?
2. How can Mozilla bug fixing keep up with the community’s bug reporting? The community is vastly larger than the Mozilla development team.
3. How can Mozilla truly leverage the community? And avoid having responsive, assertive community members being labeled as trolls?
4. How can anyone feel good about closing 1 bug out of 13000, especially if the incoming rate is greater than the fix rate?

Thoughts

This is something that every company or open-source project hopes to have: a community that overwhelms the product with love. Mozilla is doing the wrong thing if the love is unrequited.

With so many bugs churning in, developers are faced with a sisyphean task. The bugs represent community love, the developers have to view the love as not burdensome.

These thoughts really apply to every company, product and project:

Developer Bug Tool

A developer-facing bug database must only hold bugs (broken code that must be fixed),

1. NO Feature Requests
2. NO Project Plans
3. NO “technical debt removal” wishes,
4. NO minor bugs

Developers like all humans need to feel the progress, and accomplishment. Fixing one bug out of 13000 does nothing, fixing one bug out of 100 feels meaningful.

Feature requests and refactoring or changes for the future belong in a project planning tool.

Any bug, that cannot or will not be fixed immediately, must be documented in the code:

• TODO flag
• Date ( a TODO that is 10 years old not that useful – with a few exceptions )
• Person who added this comment (not necessarily a full-time developer)
• HACK flag if the code should not be an example of “how to do” things. This tells future developers to not use this bad code as a template to create more bad code.
• Discussions can happen in the code same as they would in a separate bug database

Documenting in the code not the bug database gives these benefits:

• Developers tracing a different bugs or adding new features are proactively notified without searching that:
  • the code is questionable
  • the code may be the source of the bug he is tracing
  • he may be able to immediately fix the bug documented in the issue
• If the questionable code is deleted as part of a later refactoring feature change, the bug report is also deleted.
• The bug database is not polluted with minor items that bury the truly critical issues.

Use Git

Get away from the Open-source Cathedral where only a few are blessed committers.

Avoid frustrating people who want to patch the product. Let them patch the product and share their patch. If the main official release doesn’t include the patch, at least the person reporting the problem can fix the problem for themselves and move on.

Prefilter bug reports

• Incorrectly formatted html: IE choose to format it one way, Firefox made a different guess. Just because FF made a different choice doesn’t make FF wrong, but that will not stop a bug report. FF should have a clear indicator that:
  

  The page in question has bad html and that it may not be displayed correctly. Click here to send a note to the webmaster about this page.

  Point the finger of blame at the webmaster so that FF does not get blamed (and avoiding the bogus resultant bug reports).

• Bad scripts: If the javascript is not functioning correctly announce it. Its not FF’s problem that the script sucks, don’t let Firefox get the blame.

Make it easy to report issues

• Built-in feedback tool
• Built-in screen capture (with redaction ability)
• Do not require registration in a bug database
• Do the bug reporting within Firefox don’t make people navigate.
• Ask if the last report by this person is related.
• Do the bug database duplication search for the user and ask if any of the other reports look similar.

Final Question

How can your product or service empower the community to self-help?

I was thinking about going out on top. So few manage to do it. Shaq is warming the bench in Boston. Brett Favre should have called it quits after he threw the pick in OT against the Saints. The Stones haven’t written a great song in thirty years. The money and the burning desire to “win another one” drives the great ones to stick around too long.

I also look around the venture capital business and I see investors who were at the top of their games in the 90s struggling to remain relevant. And I think about how I want to manage this issue myself.

1. “Hanging up your cleats” as in “retire” is wrong way to talk about a career change
2. Career change should be driven by internal issues (barring medical reasons, i.e sports injuries; economic, see the hollowing out of US manufacturing base )
3. Instead of being “pushed out” look for reasons to be “pulled out” of the current career. Create a passionate interest elsewhere
4. My rule is every new job must have 50% new things to learn.
5. The best career is one where you are *bad* at it but *love* to do it.
6. Variety is key. Voluntary career change is good because it is different
7. Don’t use outside metrics internally. Internal motivation is what counts the most, not anyone else’s opinion.
8. Stephan Covey’s statement applies “If you are green you are growing if you are ripe you are rotten”.

I have found no VCs interested in Amplafi, but every prospect that I talk to is interested. The prospects have experienced the problem personally and the VCs haven’t. The prospects can overcome my pitch’s weaknesses.

I think those VCs who have lost their edge need to do something completely different to get a completely new perspective on something outside their current fields.

Some suggestions for Fred:

• Start your own small business. Start a Subway franchise and work personally at it using funding it with no more than franchise fee plus minimum capital. Go through the bank loan process and artifically diminish your assets for loan purposes to experience the hassles. See what the problems are there for small business owner. Run this business personally for a year taking no additional capital. Just really get into this as if it was the way you were going to make it.
• Change people’s behavior and thoughts about the social contract of owing taxes

  Spend time and focused money people understand the tax structure. It would take relatively little money to help get local tax measures passed so that our government could function? Don’t focus on the state issues go ultra local so you can understand the issues.

  For example, here in SF the taxes are used to build stuff but no taxes are supplied to run things. The result is Caltrain ( SF Bay Area commuter train ) is in danger of shutdown. A primary cause is that poorly designed BART extensions are draining operating capital from the agencies that also fund Caltrain. Maybe in your area things are too expensive to influence, but what about in other areas?

• You are passionate about education. Sometimes technology is the anti-solution. Right now, the US despises teachers and educators. The unions are held up as this evil menace. But every teacher I know is there because she (still mostly women) cares. They work long hours just to handle the current class. This leaves little time for self improvement.

  Create and personally run a company that:

  • that frees up the teacher hours.
  • Maybe better grading systems?
  • Find time wasters in the classroom that keep teachers from being able to execute. Stay away from attacks on “evil bureaucrats” How about what Intuit did for checkbooks? Intuit didn’t blame the evil checkbook, they just made the task of managing the checkbook easier.
  • enables teachers to share best practices without being judged.
  • Preferably services that a teacher could use without having to persuade the school or district to buy-in.
  • Teachers need CPE hours maybe leverage that point?

  Make the case for education in the Deep South and the rest of the nation.

In it I had this table which showed things from the employers perspective:

	Good at doing	Bad at doing
Like to do	“Rockstar”	Sweet spot “future rockstars”
Hate to do	Short-timer	Stay away

The same table from the employee’s/job-seekers perspective looks like this:

My general rule of thumb is that every job should be ideally 50% in the “Bad at doing/Love” region. The only thing the other regions are good for is getting you that opportunity to do stuff in the
“Bad at doing/Love” region.

Now what goes in each region?

• Put all tasks or descriptions that are as fundamental as possible.
• Ideally, are not job- or position- specific.

For example, your chart may look like this:

Tailor your resume so that it gets you that learning opportunity that minimizes “Detail-orientated tasks” and leverages your ability with “Repetitive tasks” and “Communicating with people outside company” to get that opportunity to “Lead a team of 3 people”.

Obviously a quick post like this cannot be a detailed career guide, but I have found this quick-and-dirty matrix a good interview tool to help filter out jobs that are not a good match for me.

Notes:

1. this chart does not apply to self-delusional people who are “bad at doing” but think they are “good at doing” the task.
2. it is easy to be harsh on yourself so have some perspective about how bad you really are at something.
3. Ask others to add to the regions

However, many startups ignore the underlying reason and value for status updates and many big companies can easily avoid status meetings with a little bit of effort.

There is a value to status meetings!? What are you nuts?

Nope! Not talking about status meetings – status updates is where it is at.

Status updates can and should be sent by email every day. By everyone. Including the CEO.

For a status update to have value, it must:

• Be explanatory as to the reasons work was done. If the reason can’t be articulated — why was it done? (“Did X so that Y feature could be turned on in the next release”)
• Be forward looking. The status update must be usable as a planning document. When will the new feature be completed (in man-hours)
• Enable bad process to be discovered. Is something impacting all 10 developers 30 minutes/day? Solving that annoyance will save 5 man-hours a week!

The status email should have:

• successes (include “in progress” work): Brag. Celebrate successes. Explicitly indicate if:
  • work is completed as far as the sender is concerned
  • work is at a good resting point/milestone. Many times a task does not need to be “completed”, because “completed” means completely done as opposed to “major roadblock removed”
  • work still needs to be done on the task.
• planned work for next work period, with best guess time estimates/completion date. Include next time available (very important for part-time people). Plan out tomorrow today.
• frustrations arose that caused time to be “wasted” – use this to help spot problems with processes. The sender is NOT asking for help, but rather is calling out process issues.
• roadblocks that help is needed to solve. The sender must provide enough detail to form an actionable question or request. All details that the sender has discovered about the roadblock must be written. Writing out the problem with all the known information:
  • anyone trying to help does not have to duplicate already done research
  • sometimes leads directly to an “obvious” next step
  • might enable someone else to immediately provide an answer with little to no additional questions.

I had coffee last week with one of my ex students. 30 months ago he raised a Series A venture round from two name brand Silicon Valley VC firms. It was early in the day, but he looked tired. “I need some advice about my board. I get along great with one of the VC’s, but the other one, Bob, is making my life miserable. Nothing I do is right in his eyes.” He looked pained as he continued. “We never had any personal chemistry, and it’s gotten so bad in the last six months, our board meetings are just hell. They consist of Bob beating me up regardless of whether the results are good or bad. I can’t tell if he’s trying to get me to quit, fire me and bring on a new CEO or is just a miserable human being.”

I have some thoughts about the problem:

1. Document Bob’s behavior over the next 3 Board Meetings.
2. Document Bob’s assertions and suggestions in a neutral way IN THE OFFICIAL BoD MEETING MINUTES.
3. In following meetings, have the previous minutes available as powerpoint slides to instantly throw up on the projector.
4. Confront Bob with his agreement in previous BoD meeting about future goals. This prevents Bob from “moving the goal posts” about what is acceptable company performance.
5. When Bob offers a criticism avoid addressing the criticism, but require that Bob articulate why the issue raised is an important issue.
6. Agendize the meeting with allocated time for each discussion item. Timebox Bob’s ability to dominate the meeting. Require that any item that goes over time be deferred for further discussion until the meeting’s end.
7. Put controversial items at the end of the meeting. This avoids having the energy of the meeting be sapped by Bob’s negativity. Near the end of meetings, people want to leave and get on to their next appointment. The other directors are likely to excuse themselves leaving just Bob and the founder. This denies Bob an audience.
8. Schedule other meetings (preferably customer meetings) just after the BoD meeting so the founder has a graceful way to insist that the BoD meeting must end.
9. Privately, confront Bob about what he hopes to accomplish through his objections. If he can’t articulate a positive result if his “advice” is followed he can be diminished. Bob may have a valid issue that Bob is raising in a poor manner.
10. Reach out to Bob before the meeting and manage him privately and get him on board without the public confrontation at the actual meeting.

My hope is that this would turn a negative, destructive Board Member into a more positive contributor. Thoughts?

First Prize is an Cadillac El Dorado. Second prize is a set of steak knives. Third prize is you’re fired.

In my experience, the organizations that try to promote individual rewards and incentives destroy team cohesiveness.

For example, one company I know of was very proud of their individual reward mechanism. The problem was that:

1. “hard” work / long hours got rewarded.
2. only one person / dept. got rewarded.

So:

1. there is no incentive to spot a problem ( and proposed a solution ) before it was a crisis.
2. a winner-take-all mindset people were indifferent to trying to achieve a reward because the reward was like winning the lottery,
   1. there was little connection to effort put into reward achieved.
   2. Someone had to work harder than everyone else in a visible way
   3. work for a well-respected manager who could advocate for his person being rewarded.
   4. the reward was individual-based so heroics overcoming crisis were rewarded, not crisis prevention.

While firemen are important to put out the fires that occur, good organizations rely on the fire inspectors that look for problems before the fire starts. Once a crisis ( fire ) occurs damage is already being done.

In Founders At Work, Max Levinson talks about how Paypal survived because even before fraud was at crisis levels, Max started building systems to prevent and stop fraud. Paypal’s competitors were reporting fraud rates in the 20% range. Because of Max’s work, Paypal never had fraud levels that high. Max was not being “heroic” but his “fire inspector” work prevented a fire that consumed Paypal’s competitors.

Do you reward your fire inspectors?

1. they are paid enough to have a decent life
2. someone else is not paid much more than they are. (esp. if that other person is not as good technologically)

Human beings, are by nature, social. In fact, many of the best reward systems are structured around a non-cash reward system. For example,

1. a trip to Europe instead of a cash-equivalent
2. A speaking opportunity at a major conference.
3. Sabbaticals.
4. Cool gifts ( free iphone, high-powered flashlight).
5. Public recognition.
6. Opportunities to work on new technology.
7. Complements.

“Paying and rewarding” is NOT and should NOT be viewed in terms of dollars but rather in terms of raising social prestige. Money as a reward mechanism usually does not work for creative people ( or works poorly).

Watch Dan Pink at TED talking about motivation:

This is an example of egregious abuse of power by BurstNET against Blogetery.com. Blogetery.com hosts 70,000 wordpress blogs. Apparently, a few of those blogs had “an al-Qaeda hit list” and “bomb-making” instructions on them. So for the possible sins of a few, 69,999 innocent blogs are shutdown with no recourse.

You can read BurstNet’s lame press release here.

Any web service that allows user-generated content ( so pretty much any site that isn’t a static site) would be subject to a draconian response by BurstNET. What is especially egregious is that BurstNet is not letting Blogetery get access to any of Blogetery’s data!

Continuing, from the New York Times Bits blog,:

And Kurt Opsahl, a staff attorney for the Electronic Frontier Foundation, a digital rights group, said the “tragedy is that thousands of blogs will be taken offline for no good reason.”

Mr. Yusupov said he had backed up some of the blogging site’s data, but not all. And he said he was trying to negotiate with BurstNet to get the data so he could restart the blogging site with another hosting service. “This has been a big hassle for me,” he said.

In the New York Times Bits blog,:

Mr. Marr of BurstNet said the Blogetery server did “not get a lot of use or traffic,” suggesting the number of active users of the free blogging site was probably a tiny fraction of the 73,000 Blogetery claimed.

So basically, Blogetery is a small business and is therefore “not important”. Important news to any small business considering using BurstNet:

BurstNET thinks small businesses are not important

Stay away, stay away! You cannot run a business where at the arbitrary whim of the hosting provider you can be shutdown, especially if the hosting provider will not supply your data so you can go elsewhere!

For similar reason, I stayed away from GoGrid (and now BurstNet).

Update ( 28 July 2010 ) :

A last interesting point from CNET about how Burst.NET feels about their customers’ data (aka don’t use Burst.Net for mission-critical purposes):

Joe Marr, chief technology officer of Burst.net, stressed again that the reason for the service termination was that the materials the FBI alleges belonged to terrorists are a violation of Burst.net’s terms of service. He noted that typically, Burst.net does not return data to customers booted for TOS violations.

Violations of the Burst.NET Terms of Service result is losing all your data!

Excuse me????
Use Rackspace

Robert Cruickshank over at the California HSR Blog whines about Palo Alto’s “undemocratic” democratic process:

In short, it is becoming increasingly clear that Palo Alto’s planning and citizen engagement process is a failure, distorting true public opinion by favoring a small, vocal elite at the expense of a silent majority whose opinions are much more supportive of new density and new transportation solutions – but whose voices are rarely ever included in the city’s planning process.

Of course, our democratic process requires energy and participation. There are lots of people who chose not to vote because their vote “will not be effective”.

Most people are uninformed about this issue, do not ride transit, or have no idea how to build transit effectively. Their opinion should not count as much as the people who are taking the time to inform themselves and to be involved.

If someone is not involved, their opinion is probably uninformed and negative.

Meetings to planning a company project can be just as bad.

Uninformed people should not be part of the process(^{see below}). In
an old Inc. article, Joel:

When was the last time you scheduled a meeting and invited eight people instead of the three people who really needed to be there simply because you didn’t want anyone to feel left out?

When was the last time you sent a companywide e-mail that said something like, “Hey, attention coffee drinkers: If you finish the pot, make another!” even though there is actually only one person who violates this rule (and she’s your co-founder)?

When was the last time you got into a long discussion over the color palette for the new brochure with a programmer, who has nothing to do with the brochure but sure knows that he doesn’t like orange?

These are symptoms of a common illness: too much communication.

(“below”)
However, I disagree with Joel’s assertion that only people whose vote counts should be allowed to attend meetings. Decisions with no visible process result in no buy-in. While a company is not a democracy, and a city is not a company both should learn from each other.

What a company can learn from a city:

1. Process does matter. Process means consistency and reliability in how decisions are being made. People know how to voice their opinion. They know that there is a means and method for voicing their opinion. Instead of voicing opinion in an adhoc, disruptive manner – they can wait until the allocated time.
2. Only some people get a vote. Many people can show up to a city council to express their opinion, but only city council members get a vote. In company meeting, discussion can include everyone – but predecided ( and preannounce! ) who’s vote will be counted. For example, if a developer is trying to decide who to best implement a feature. Only his/her, the CTO’s, QA’s and customer service rep’s votes are counted. Others who are not involved, do not get to vote. They can express their opinion but they are not a decision maker (for this issue). Only people expending effort or where the decision has a material impact on their job should be counted.
3. Representatives get “elected”. Allow some self-selection in the process. Try to allow the lead representative to be selected by people other than managers. If a developer selected to be the lead in a project makes a decision, this makes it easier for the decision to be respected.
4. Make the discussion observable and inclusive While only some people get a vote, allowing others to learn from the process of making a decision prepares those observers to step into their own decision-making role. It also allows them to take knowledge from one decision-making group to another.

What a city can learn from a company:

1. Require an energy expenditure to participate. A meeting should only be open to people who have attended the last 5 meetings.
2. Allow adhoc representation. Allow people to represent adhoc groups. For example, allow a person to collect 10+ signatures of his neighbors giving him/her proxy authority to voice their collective opinion. Require that this adhoc representative keep the people she is representing informed of the progress and results. (With power should come responsibility).
3. Allow weighted voting. In a company, the CTO’s vote counts more than a lowly developer. When voting for a company’s board of directors’, shareholders have a vote based on number of shares not a one vote per shareholder. In a city planning process, the “vocal” minority may represent no one other than themselves. Let the “vocal minority” collect proxy signatures to indicate how strongly their “silent” neighbors (who can’t participate) trust the “vocal” people to represent the “silent” majorities best interest. The more signatures, the more strongly a “vocal” representative’s vote/opinion should count. Allow certain signatures to be more valuable than others based on the issue. For example, distance to a housing project, transit user’s opinion on a transit project, etc.

Update:

Lastly, learn when you should not vote or participate.

1. If you personally do not have any direct, meaningful, unique knowledge: don’t participate. Observing is o.k. – voicing a “I agree” content-free vocalization is not o.k.
2. If you don’t have the time to stay involved: don’t sign up and then drop out.
3. If an issue has no one who cares: then the decision can be made by a single person. Others should insist that that single person make the decision. The sole decision-maker should not need the CYA of a “group vote”.
4. If you cannot expend effort on the solution, then don’t vote. Note that “effort” does not mean “coding” or “making”
5. If the decision will not effect how hard your job is, then don’t vote. If the decision does meaningfully effect your job then you must participate and must vote.

There is this temptation to dismiss the concerns of Customer Service or QA people as being less important than that of the development team. This is ass-backwards.

A Customer Service rep will have to deal daily with a bad development decision. Their job satisfaction, their ability to deliver happy customers is daily determined by developers decisions. They must be allowed to participate and must be given a strong voice.

One of my standard questions that candidates constantly struggle with is the most simple and yet the most subtle:

Teach me something you know.

If a candidate cannot teach “something”, then they have not completely thought through and learned the subject. Someone who claims to be “strong” in Java, databases, or cooking is only strong if they can articulate the core essence of their knowledge in a way that a beginner can understand.

When developing code at a startup, a good “teacher”:

• understands that it is the teacher’s responsibility to reach the student. If the student doesn’t understand, then a good “teacher” patiently retries until the student does understand. In a startup, the “student” is a new hire, a sales person or the customer;
• writes excellent code comments (for the student),
• is patient and not egotistic when others don’t “get it”;
• can articulate their own problems so that others can help;
• can give presentations to non-technical people;
• is empathic;
• is motivated to do their own learning.
• is enthusiastic

So what can you teach?