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????

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?

Calacanis goes on to examine the three categories of that mistakes and employees can fall into and discusses his thoughts on who and when to fire:

1. A great team member who makes a big mistake

   Verdict: Don’t fire them. Talk about the mistake, and brainstorm ways to fix it and to make sure it doesn’t happen again.

2. An average team member who makes a big mistake

   Verdict: Fire them. In fact, Calacanis makes the argument that you shouldn’t hire average employees at your startup in the first place.

3. A great team member who makes multiple mistakes

   Verdict: It’s complicated, and unfortunately, it’s all too common. Calacanis says that when faced with this, he does try to work through the person’s problems. And while he notes that founders might not have the time or the training to do this, he stresses its importance. “When you try to save a flawed, yet at other times effective, team member, you send the other members of your team a positive message: loyalty.”

Seems reasonable doesn’t it? But lets break this down from the perspective of the employee.

Flaw #1: Employee does not know where (s)he stands.

Does the employee know that he is an “average employee” or is a “great team member”? From earlier in the post, clearly in this case the employee responsible for the problem in question thought that he was an average employee living under the one strike rule:

And according to Calacanis, the individual responsible was apologetic, fearing that he’d be fired.

Flaw #2: “Great Team Member” Employee does not know when their chances are used up.

In the case, in question the sysadmin who screwed up and let people post the the jason-list discovered he was a “great team member”. This mistake did not mean his job. whew…. however, if that sysadmin makes another mistake – how much time has to elapse before he is in the category #3 – “great team member but multiple mistakes”? Is he allowed 1 per month? one per quarter?

Flaw #3: Inconsistent response

Human beings as a rule do not respond well to perceived inconsistently applied punishment. Having the “great team members” not get fired for a mistake that got a “average” employee fired does not create loyalty – just fear.

Flaw #4: Dependency on above average employees

A business owner should be creating a reproducible process that drives repeated high-quality execution. Relying on above average talent to sustain the business is simply bad practice that results in inconsistent and high-stress environments.

Flaw #5: Blame

Failures are always a sign of a systemic problem. When the B-17 (Flying Fortress) was developed there were several crashes traced back to pilot error. “Some newspapers had dubbed it[B-17] as ‘too much plane for one man to fly.’ . The Air Force’s solution was not to find better pilots but rather to develop the checklist.

My summarized counter suggestions:

1. Look for and reward passion – passionate people will self-correct each other
2. Define a fireable offense, in advance and apply consistently
3. Expect better – Put everyone on a Performance Improvement Plan including the CEO – Performance improvement plans should be a plan to raise the organizational execution level.
4. Expect Greatness – Drive a plan to get people to “hit above their weight class” – in other words exceed their personal best. Read the book Moneyball to understand this idea applied in baseball.
5. Create Checklists – Use the above average people in the organization to create a process that does prevents mistakes. In other words, the creative great people should not necessarily be promoted to managers but rather be put in charge of formalizing their “above averageness”. Internally, I am working on having a great contributor (“Bill”) formalize his current responsibilities. This formalization will enable another contributor (“Peter”) with a significantly lower skill set to take over the tasks. Because of the formalization of greatness, “Peter” will operate at Bill’s higher skill level. Bill can now move on to other new challenges.

Update: Read ben horowitz’ post

I ran into Ari Krupnik at the Hacker Dojo job fair. I have constantly beaten my head against the wall trying to get other developers to understand that most people are not interested in technology for technology’s sake. Most people outside Silicon Valley has a life that does not revolve around technology but rather uses technology as an expression of “self” (“iPhone gets me the girl”). Non-techie types are anti-RTFM. Developers as a rule don’t understand and think the users are eager to spend hours discovering how wonderful the program is.

Ari apparently does:

I notice that engineers who block specific emotions entrain drama that revolves around the very emotions they block. The drama seems to go away as soon as the engineer is willing to experience the feeling that he blocks. In the tribe, we help each other unblock feelings and experience them fully. The results seem to include better relationships with peers and customers, and improvements in code quality.

Rockets blow-up.
Servers crash.
Regressions happen.

How you handle the setbacks is critical. Blame is a useless response. Blame is negative. After blame has been assigned, the rocket is still in pieces, the server is still down, and the bug still exists.

Hire people that take RESPONSIBILITY for finding SOLUTIONS. Hire people that look to HELP others shoulder the RESPONSIBILITY to fire the problem. Hire people that look for ways to prevent a duplicate of the same problem.

Once the problem is fixed, do you and your company spend time praising the “firefighters” only? Do you spend any time praising the person who caused the fire but was RESPONSIBLE enough to step forward, admit the problem, and help fix it?

Do you take RESPONSIBILITY as a manager to give your people time to build a “sprinkler system” to put out a similar future fire?

The first “fire” might be caused by someone else’s carelessness. But the second fire is YOUR responsibility if you didn’t budget time and money for that “sprinkler system”.

If you work 100-hour weeks, no one (investors, co-founders, employees) can blame you if things don’t work out, right?

And I like to think I’ve worked a lot smarter since then [missing dinner with spouse].

The life of an entrepreneur can be rough, but at least it’s a life of your choosing. The same can’t be said for your family. Give then a chance to make their own choice.

In other words, it is the default choice in the valley and in the technology sector. And its a stupid choice. 168 hours in the week. 100 hours at work. Allow 8 hours/day for sleep. Drive-time to/from work of 1 hour. This leaves exactly 13 hours for the employee to do *anything else*.

A few years ago, I had a job with the best work-life balance. This start-up had with only 7 engineers with 30-ish total people. Between November and January, we built a Paypal integration and a major piece of functionality that got the start-up their first bits of solid revenue. Everyone took their normal holiday vacation. Every programmer worked 9-5. No weekend work. We completed the project on-time.

The company is LinkedIn. We achieved this because Jean-Luc Vaillant was fanatically about knowing exactly what was to be built and automated tests so he knew exactly where the code was. Those tests had to pass each and every night. No new work was to be done until all the previous night’s failed tests were fixed.

Every later employer had to live up to this reasonable bar. Sadly most fail and most projects are late.

They fail because the managers listen to the siren song singing the lies:

• that says that automatic tests are optional;
• “trusting” the developer to adequately test by hand is good enough;
• that there is more time to do-it-again than to do it right
• that documentation is optional and it better to have team members figure out anothers work than it is to demand that the creator document;
• and that long hours are better than sane hours

While Chris does touch on the work-life balance with his wife, he misses some key points. If the team is working 100-hours/week:

• the team has no reserve capacity – if a short-term sprint is needed to wrap up a project – forget it
• the team starts to waste time at work: web surfing and game-playing. So while physically there, they are neither productive nor getting a break from the work environment.
• as soon as there is any corporate setback – moral collapses. When it looks like the company is going to be the next Google, employees will justify to themselves that working ridiculous hours will pay-off. This illusion is dispelled at the first severe setback.
• someone outside of work is always telling the employee how stupid they are to work such long hours. The wife, the husband, the kids, the mother, or just the friends who are going up for that most excellent ski trip to Lake Tahoe.

So my advice to employers:

• Get rid of the game room. Make employees have fun outside of the building.
• Cut the power to the employees computers at midnight. Make them sleep so they can think and not make silly mistakes.
• Do a postmortem on every crisis. Without blame and with automation ONLY, look for ways to make sure that the crisis can never, ever repeat. Working “harder” or requiring greater “perfection” is NOT the answer.
• Reward employees – not for working harder, freeing up ‘capacity’. Did some developer, IT person, or janitor do something or automate something that freed up 20 minutes/person/week? In a 30-person startup, those 20 minutes saved is the same as hiring a full-time person for 3 months! Get everyone to look for these “small” time-savers. Work now becomes less onerous, more enjoyable, and your headcount stays down.

Expanding on the last point with some examples:

• Automatic tests — avoids developers acting like monkeys do manual tests.
• Buy the absolute fastest machines. My latest machine took me from 15 minutes builds to 1m30second builds. I started running the tests all the time!
• Virtual assistants to handle the random shit that an employee might have to do during the day
• Every 6 weeks, a mobile oil change service so that no one needs to run to Jiffy Lube
• Outsourcing human resource issues

Spend the time to discover those “small, annoying” things that seem to petty to complain about — but that impact a significant percentage of the company.

Remember for a small 30-person startup saving 1hr20m/person/week ( i.e. 16min/person/day ) is the same as hiring another person. And in the process, enables everyone to step back from the brink.

Google has their famous 20% “free” time to work on new projects. Every startup should have 20% “free-up” time to make existing projects less painful.

While I am working hard at amplafi I am working even hard on making sure that my family knows I much rather be with them than coding.

Also read Steve Blank’s post on the Lies told Entrepreneurs.

Strongly, strongly agree with:

Ask me what I see lacking most in startups in Europe and I’ll say hunger, drive, and lofty goals.

For me my hunger and drive come directly from wanting to change the world for my children.

So I equally strongly DISagree with:

worked four jobs for the money to launch their venture, without giving a second thought to “quality of life” or “spending time with the kids.”

For me sacrificing the hours between 6:30-9:30pm that I spend with my kids is a false choice. I sacrifice that time only when absolutely necessary and never more than 2 days in a row. Once I have those 3 hours with family, I am emotionally recharged and able to focus completely on building my company, Amplafi.

I am not alone in this. Chris Yeh and Steve Blank : Lies Entrepreneurs Tell Themselves share my feelings.

My personal reality is the least successful company demanded the worse and longest hours. And the most successful startup asked the most reasonable hours. We work from 9-5. No weekends. No missed holidays. You might have hear of it. Its called Jean-Luc Vaillant did his job and managed his people well.

Shitty long hours is not a badge of honor. Its a sign of bad prioritization and resource management. Sure some times the long hours are necessary… just like a sprint is necessary at the end of a marathon. But you don’t sprint the entire length of the marathon. And unlike a marathon in a startup, there is no rest after crossing the first finish line – just another finish line in the distance.

A startup that is sprinting constantly better hope that they get bought before exhaustion sets in. Otherwise their competitors that have paced themselves better will pass them up and their best people will burned out and quit. Any little stumble, any sign that success and glory are a few months away… and the startup starts spending time looking for fresh blood.

This post should have really been the second one I wrote. The first post was about who a developer needs to keep happy – the client or the manager.

But commenting everything is both hard, excessive, and wasteful of time. In “the why” post, I cover what should be in the comments – implicitly I was limiting comments to just the places where knowing “the why” is important.

However, still the question is “when” should a developer comment?

Here is my rule of thumb:

• Any developer had to spend time figuring out what the code did. Refactor it and if still not clear comment the code with questions and assumptions. (Just in case the refactoring introduced a bug or caused an existing bug to appear.)
• Another developer asks the implementing developer (or the current “owner”/responsible developer) about the code, interfaces, package. The developer asking the question copy the explanation into the code, cleaning up the chat log/email response and adding further edits and explanation as needed.
• The code is not going to have further development for a while. Comment the code enough so that when development is resumed, the restart is faster.
• The code is being handed off from one developer to another.
• Key interfaces that are used by multiple groups.

And managers give developers time to wrap up and add these comments.

Conversely, what is not worth commenting:

• Code that is actively, daily, being changed rearchitected. Every developer already knows what the comments would say and the structure is changing fast enough that the comments would become outdated.
• Code that does not impact data integrity and end-user experience in a horrid way.
• Utility classes/ methods.

When someone is “wrong” about a subject that you care passionately about, it is natural to argue with them and try to “prove” to them that they are wrong.

Don’t.

Mentally step back. Look around. There is always a third person in the room. Even if that third person doesn’t look like they are paying attention; they are.

Are you at a party arguing in a corner? The tone of your voices will reach others. The facial expressions will reach others. What are you saying to those other people?

If this is a subject that you really do care passionately about, and the second person also cares passionately, diametrically-opposite opposite to you, neither one is likely to convince the other to change their mind.

The person’s mind you can change is that third person. The person who is casually observing. The person on the fence who hasn’t yet made up their mind.

Take the time to use and channel your passion to reach that third person to your side. That is the person you need to persuade.

Focus on being pleasant and reasonable sounding. Not argumentative. Don’t be dismissive of the person you are directly disagreeing with.

Use curiosity to counter their points. “I am curious why you feel this way, when …” (h/t to Genie Z. Laborde, Ph.D. )

Your curiosity conveys open-mindedness to that third person. Your curiosity will persuade that third person.

Clean “good” code is good but not enough. Code needs comments — but the right kind of comments.

“What” comments are useless and the most quickly out-dated. An example of a what comment is: “add the suffix path to the end”.

However, the post “Thoughts on how to evaluate code” was very specific referring to “why” comments.

Code no matter how “clean” can not self-document. Excellent comments are “why” comments. “Why” comments talk about :

1. the assumptions / program state the code is expecting. (For example, the user is logged in, premium membership, or admin privileges )
2. other code affected if this code is changed (For example, setting up a language default for the session, a default that another piece of code is expecting to be set.)
3. if something is being done in a non-standard way – why it is being done that way (for example, iterating through a loop from high index to low-index rather than the standard low to high)
4. should the code in question be used as an example pattern of how to do similar operations elsewhere in the code – or should a developer instead use a different pattern elsewhere.
5. list the assumptions or conditions that require this implementation (with timestamp) so that it is easy to spot code that is present to handle conditions that no longer exist. For example, a comment like this: “12/20/2007 – yahoo’s open id implementation is using the openid 0.8-proposedspec.” Its pretty likely that the the spec has changed as has yahoo’s implementation. This wasn’t a HACK but knowing that reason behind the code is invaluable.
6. Future work planned.
7. Alternative solutions that were rejected (and why).
8. Performance considerations – this code might be special because it executes millions of times a second. So there is good reasons for some “ugliness”.
9. Update: Why the code was NOT done in a certain way.maybe the usual way to do a certain operation has resulted in a bug (reference the bug number in the comment! )
10. Update: You, as a developer, are confused by the code. Document your confusion! You may have just discovered a bug.
11. Update: Document other code looks related for a possible later refactoring.
12. Update: Document code that should be removed ( Java’s @Deprecated is very useful in this regards because IDEs can mark references to the deprecated code )

The developer, at the moment they are writing the code, must be able to explain why they are writing the code a certain way. It is a red flag to any developer if they cannot explain the why. They should double-check to make sure they understand the requirements. Chances are they don’t and they are doing the wrong thing.

I started requiring developers to clearly document the “why” in their code. I discovered developers that were doing things “wrong” because they were unaware of the correct solution. I discovered that I was not as clear in conveying the requirements as I really thought. Without the developer’s “why” comment, it is easy to get frustrated with developers for the wrong reasons.

Parting thought

Why should the developers that come after the original developer have to spend any time ( and money! ) figuring out the previous work?

You may be the next developer.