Archive for March, 2009

New media same as the old when it comes to getting facts wrong

Friday, March 27th, 2009

Once again “new” media reporters on blogs has proven no better at getting facts right than “old” media reporters.

Mike Arrington over at TechCrunch gets a cheap laugh at a proposal to “ban black cars” by the California Air Resources Board.

Of course the vast majority of the comments piled on with silly comments about the “left coast” and “nutty environmentalists”, but apparently no one bothered to actually read the proposal or understand the problem.

Except that isn’t at all what the proposal actually is.

Briefly, dark colors absorb heat. And take a long time to radiate. Go down to LA in July some time. 95+ degrees. In stop and go traffic, without an airconditioner, the car will never cool off.

And if anybody bothered to actually read the presentation it says:

data indicates 20-25%
more likely achievable range for dark
colors for automobiles ( page 8 )

By 2016, all colors must meet the 20%
reflectivity requirement” (page 9)

And the benefits are:

Reduced interior temperatures can reduce a/c capacity and likelihood of a/c use
Smaller a/c or less operation results in less
fuel used ( page 4 )

So in other words, by 2016 the paints must meet a reflectivity standard that is *less* than what is possible for dark colors (except for jet black). If a Jet Black paint can meet the standards, the paint is o.k.

So ARB made sure to set an achievable goal that would not “ban” a color. But Mike needs his cheap shot and nothing was going to stand in his way.

Posted in environment, political, random silliness, rants | No Comments »

Cry me a river

Thursday, March 26th, 2009

[Crossposted from my comments over on Fred Wilson's blog]

Sorry Fred — “Financial McCarthyism” ?

McCarthyism was tarring the innocent with innuendo to ruin the accused lives.

What is happening now is anything but. AIG, Merrill Lynch, Bank Of America, et.al. are NOT innocent victims. They are the perpetrators of the biggest heist of all time.

These financial “wizards” have demonstrated that the only financial knowledge and ethics they have is that of a swindler.

This is a perp walk for a reason. They are the criminals – not victims.

Read Jack deSantis’s sob letter. My answer is …. so?

AIG is bankrupt. At a bankrupt firm, bonuses aren’t paid, contracts are torn up – usually by bankruptcy court. Look at the UAW, GM, GM’s creditors, and bondholders – pennies on the dollar for them.

AIG should be in receivership. Instead, we the sheeple taxpayers, *paid* for the privilege of declaring AIG bankrupt. Instead of dumping billions down the AIG rathole in the first place, AIG should have just been seized like a bank in a similar situation would have been.

My wife and I both at various times were promised bonuses at startups that went through an asset sale and shutdown. Not always were those bonuses delivered. Should we have have been able to write such a letter to the NYT.

Some more points:

  1. The letter writer (Jack) claims he had nothing to do with CDS. How do we know? Was he in meetings when the issue was brought up and went along with/and or encouraged CDS? We only have his word on this.
  2. How do we know that his work didn’t “blow up” in later years? Only his word on it.
  3. “$742,006.40, after taxes”. As a bonus. In a bankrupt firm. “$1″ annual salary. Show me many people who could take that kind of salary cut. My wife who is a tax accountant has some people coming in with $300K+ in W-2 wages crying about how much taxes they have to pay. A client who makes more in tax-free California muni’s than my wife and I have all year. I am sorry, cry me a river. The *average* income for a family of 4 in the San Francisco Bay Area is about $85,000. Cry me a river.
  4. Jack claims to have suffered as a result of the economic downturn. Oh really? Is Jack being foreclosed on? Are his kids having to pass up on dreams of going to college? Is Jack looking at his medication and deciding which prescription he isn’t going to renew? Or maybe its powdered milk this month, or a trip to Second Harvest. Are creditors calling him? Considering that Jack’s firm helped with the 2005 bankruptcy law re-write, that helped result in so many foreclosures — cry me a river.
  5. When deciding to hold out for the bonus, he should have factored in the possibility that AIG wouldn’t be able to pay up on the promises. Are GM and Chrysler execs writing such letters? Probably not. Would a UAW member looking at a slashed pension get the same sympathy?

Once again, Jack is not an innocent victim. Jack may not be a criminal. No one is talking jail for Jack (yet). But Jack just learned a hard lesson in not-counting-chickens-before-they-are-hatched, and he is “upset”. I bet half the country would switch places with Jack and not be upset at all. Maybe Jack needs to step back, clear his head, and go work at a homeless shelter for some time to get a proper perspective.

Final question — how come is it that people like Jack who don’t actually make anything, who don’t actually increase the value of the world are so highly compensated? Jack is just a fancy pants banker. Fred, you as a VC add value. You help create companies and bring new ideas to fruition. My wife makes sure that her companies spend their money wisely. I am building a company, Amplafi. What did Jack and his ilk build or create? Near as I can figure, they built a fancy casino.

Posted in political, rants | No Comments »

Code Review #8: When to comment

Monday, March 16th, 2009

The last ? in a series of posts about commenting. See “the why”. See “not commenting is career threatening”. And the comment that started this off!

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.

Posted in code review, management | 1 Comment »

Why and when to wrap external library classes

Monday, March 16th, 2009

At some point, every developer starts using an external library. They then have to decide if that external library should be wrapped in their own custom interfaces and classes.

If the external library would be pervasively imported in throughout the code then the answer is empathically YES — the external library should be wrapped.

At Amplafi, hibernate is just such a library. Without wrapping every time the hibernate library changed its structure or behavior, the change would have a large impact. However, by wrapping the libraries hibernate became loosely coupled.

This also enabled us to solve other more major issues with Hibernate Query and Session.

Specifically:

  • control when a transaction could be committed. We wanted to count how many times a tx was “started” and only commit when the tx was “ended” the same number of times it was started. Useful for code that doesn’t know if it needs to start a transaction. Now any code that needs a tx just “starts” one and ends it when done.
  • Performance metrics gathering.
  • Delaying starting the transaction until it is known that something will actually be done.
    More gentle behavior for query.uniqueResult() ( default Hibernate behavior is to throw an exception if there is more than one row returned. Amplafi’s wrapper logs the non-uniqueness + ids of the extra rows. )

How we did this:

  1. Create an interface (AmplafiQuery) that extends Query
  2. Create a class (AmplafiQueryImpl) that extends AmplafiQuery and wraps a org.hibernate.Query
  3. Create a Txmanager that returns a Tx.
  4. Tx has the various createQuery methods and returns AmplafiQuery

We also took the opportunity to add to AmplafiQuery:

  • a “asList()” that is a generic enabled version of Query.list()
  • a “unique()” that is a generic enabled version of Query.uniqueResult()

Posted in code review, hibernate, technical | No Comments »

Interfaces vs. abstract classes

Saturday, March 14th, 2009

Sigh … some people just don’t get it…. :-P

Interfaces rock! Below is my comment from stackoverflow.com, a question about how to handle the “interfaces v. abstract classes” interview question in an interview.

  1. First, the “only one super class” answer is lame. Anyone who gave me that answer in an interview would be quickly countered with “C++ existed before Java and C++ had multiple super classes. Why do you think James Gosling only allowed one superclass for Java?”

    Understand the philosophy behind your answer otherwise you are toast (at least if I interview you.)

  2. Second, interfaces have multiple advantages over abstract classes, especially when designing interfaces. The biggest one is not having a particular class structure imposed on the caller of a method. There is nothing worse than trying to use a method call that demands a particular class structure. It is painful and awkward. Using an interface *anything* can be passed to the method with a minimum of expectations.

    Example:

    public void foo(Hashtable bar);

    vs.

    public void foo(Map bar);

    For the former, the caller will always be taking their existing data structure and slamming it into a new Hashtable.

  3. Third, interfaces allow public methods in the concrete class implementers to be “private”. If the method is not declared in the interface then the method cannot be used (or misused) by classes that have no business using the method. Which brings me to point 4….

  4. Fourth, Interfaces represent a minimal contract between the implementing class and the caller. This minimal contract specifies exactly *how* the concrete implementer expects to be used and no more. The calling class is not allowed to use any other method not specified by the “contract” of the interface. The interface name in use also flavors the developer’s expectation of how they should be using the object. If a developer is passed a

    public interface FragmentVisitor {
    public void visit(Node node);
    }

    The developer knows that the only method they can call is the visit method. They don’t get distracted by the bright shiny methods in the concrete class that they shouldn’t mess with.

  5. Lastly, abstract classes have many methods that are really only present for the subclasses to be using. So abstract classes tend to look a little like a mess to the outside developer, there is no guidance on which methods are intended to be used by outside code.

    Yes of course some such methods can be made protected. However, sadly protected methods are also visible to other classes in the same package. And if an abstract class’ method implements an interface the method must be public.

    However using interfaces all this innards that are hanging out when looking at the abstract super class or the concrete class are safely tucked away.

Yes I know that of course the developer may use some “special” knowledge to cast an object to another broader interface or the concrete class itself. But such a cast violates the expected contract, and the developer should be slapped with a salmon.

Posted in code review, technical | No Comments »

Third person in the room

Saturday, March 14th, 2009

Passion is a wonderful thing.

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.

Posted in how to, management, marketing, political, starting a company | No Comments »

Code Review #7 – Comment the “why” not the “what”

Wednesday, March 4th, 2009

[This post continues the response to Mike.]

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

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.

Posted in code review, management, technical | 6 Comments »

Not commenting code is dangerous to your career

Wednesday, March 4th, 2009

There is this myth that code can be self-documenting and that comments are not necessary in good code. Michael recently comment on an earlier blog post advocating the idea of self-documenting code.

“Self-documenting” code is a career-damaging concept, because:

  • Your “manager” (person who decides you stay employed) is an “idiot”,
  • Your co-workers are “idiots”,
  • You are an “idiot”
  • The product manager is an “idiot”
  • Your client is an “idiot”

Your “manager” (person who decides you stay employed) is an “idiot”

That’s me. The guy who has 6+ people to manage has to figure out business plans and a much of non-technical stuff that has no doubt resulted in permanent brain damage.

Your manager is code reviewing all the changes by his direct reports. A task that takes a few minutes every day… unless there are no comments. I know that your manager should be able to immediately see what the code does. But remember your manager is an “idiot”. Unfortunately for you, he signs your paycheck.

Also unfortunately for you, if your manager doesn’t immediately understand your change — you are an “idiot” in his eyes.

You have also just turned a 15-minute task into a 2-hour task. He didn’t really want to be home with his family.

Your co-workers are idiots

Lets agree, your code was stellar but then your co-workers came in and mucked it up. They did a stupid refactoring and broke everything.

The code was “obvious” but not to them.

You are an idiot

Your manager returns from a two-week vacation and is code reviewing 2 weeks of changes. Your manager is asking about a “odd” change that you did 14 days ago.

  • Can you explain it clearly?
  • Do you remember your thinking at the time?
  • Alternative solutions that you tried and failed?

The product manager is an “idiot”

  1. Your stellar (comment-free) code is deployed into production.
  2. The product manager changes the product definition and a new feature is born.
  3. One of your (“idiot”) co-workers makes a change (but not to your code).
  4. The tests pass and 2am this Friday, the code is to be deployed
  5. You go out drinking.
  6. Your (“idiot”) manager deploys the code to production and it breaks.
  7. Unfortunately, it breaks in your code.
  8. Your manager looks at your code and can’t figure out why you wrote the code a certain way.
  9. Its 3am now. He calls you up. Are you going to remember why and are you going to be able to help him?

Lets pretend that the test coverage is better and the problem is discovered before deployment. But your change was made 3 months ago, are you going to be able to explain the thought process for the change?

Your client is an “idiot”

You are independent and you take on clients. Your new client is a non-technical person who needs your awesome coding skills. Now you are in trouble. A non-technical product manager and a non-technical manager (they are paying you!).

But your code is self-documenting right?

Not to them. The product is late. The doubts grow in their head. They ask a friend to look at your code. Their friend (“another idiot!”) says the code looks like garbage and he cannot tell why you wrote the code a certain way. The client starts to push back on paying your invoices. Things get ugly.

Posted in code review, management | 3 Comments »

Grow your own rockstar

Wednesday, March 4th, 2009

I have interviewed hundreds of people, technical and otherwise. I have managed a few as well.

Most interviewers do not realize that there is no “best” candidate on an absolute scale. The rockstar at Google may absolutely fail to fit in at the interviewer’s company.

For most companies, even most start-ups, the rockstar is not interested in the company because the company itself is not a “rockstar”.

  • Do you have Dave McClure or Seth Godin as advisors?
  • Is Reid Hoffman on your board?
  • Are you working on cutting-edge projects?
  • Are you using the latest technology?
  • Are you willing to let the rockstar do things his/her way?

Why would a rockstar be interested in your company? If you don’t know then your company will never attract and retain rockstars.

Look for the budding rockstar

Instead of looking for the proven rockstar (who has 10 offers; all of them better than yours) — create one!

Ask every candidate to bucket their skills into one of these four buckets. For good measure also ask about key “task types” (for example “debugging performance issues” ):

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

“Rockstar”

Interviewers are told to look for the person in the “Rockstar” bucket. The candidate that is good at what you need and loves to do it. When looking for a brain surgeon, this is the doctor you want fiddling with your gray matter. However, when hiring for other positions you (the company) are asking this talented person to do exactly the same thing that they have already done.

So in effect you are asking them to tread water in their career and not grow. The company will have to offer higher salary, huge stock options, or enough “sweet spot” opportunities. Without one of these, it is quite likely that after a few months the new-hire (and you!) will discover that the rockstar has drifted into the “Short-timer” bucket and is now job hunting on the side.

However, in the absence of “sweet spot” opportunities and if the prospects of the company turn south — this “rockstar” is the first to bail. They are good, they know it, and they are heading for greener pastures.

“Short-timer”

The person is good at the job but they hate to do it. They will do the minimum necessary and no more. Late nights and long hours will quickly be resented. This person is job hunting ( or should be). Try to find a “sweet spot” for them fast to take away the pain.

“Stay away”

The person is bad at something and they hate doing it. If you hire this person you are an idiot. Enough said.

“Sweet spot” ( future rockstar )

This is the person to hire. They are bad at the skill but they are motivated to get better because they love doing it. They will stay up late figuring things out. They will think and breathe the technology or the skill and try their damnedest to become that rockstar.

They will be loyal because the company gave them the chance to learn and grow when no one else would.

Best of all the competition for the future rockstars is low. Everyone else is too busy looking for today’s rockstar.

Price of growing rockstars

However, growing rockstars is not cheap.

  • the company must be willing to mentor and guide the future rockstars.
  • Management and the rest of the team must tolerate failure and correct without punishment.
  • Labeling someone an idiot cannot be allowed. There must be a supportive environment.
  • the company must not have a consensus environment. Everyone is not equal in skills. The budding rockstars must not be deluded into thinking that they are rockstars.
  • Advancement and reward structure that recognizes supporting roles. This encourages others to help mentor the future rockstars.
  • Willingness to fire. Lets face it a company is not a school. There are certain people who will not work out. Fire those to make room to hire more future rockstars. And this includes your current rockstars!
  • Know the difference between “working hard” and “working smart”. Make sure the company rewards “working smart” not “working hard”.
  • Know when the future rockstar is in over their head and rescue them. (which may unfortunately include terminating)

Posted in management, starting a company | 1 Comment »