fitness 16 Sep 2008 07:20 am

today’s workout

forgot to write it down, so recording it here:

Warmup

  • 10 squat hip extensions
  • 3 inchworm
  • 10 rocker thingies
  • 200m run
  • 10 tuck jumps
  • 10 straight leg marches
  • 10 high-knees fast / slow
  • carioca

“Michael”

3 rounds of:

  • 800m run
  • 50 back extensions (alt - good mornings w/ unweighted bar)
  • 50 situps

30:28

Uncategorized 02 May 2008 04:18 pm

The facebook apps people use…

From today’s Silicon Alley Insider:

Everyone knows that most Facebook apps are time-wasters, at best. But here’s statistical proof from FlowingData: A breakdown of the service’s 23,160 applications, via Facebook’s self-selected categories.

I don’t think time wasting is quite accurate.  I think this is a better explanation for what’s going on over at Facebook.  

Uncategorized 17 Dec 2007 03:00 pm

notes on Clausewitz

I found an old notebook from 2001. I was flipping through it to see what I was doing then and found some notes from a book I was reading this book on Clausewitz — some really good stuff that applies in lots of domains outside of War.

  • Theory Shouldn’t be Dogma - The best theories guide analysis and aid in understanding.  The worst prescribe actions under specific conditions.  Interesting to note that Innovator’s Dilemma does the former, while Crossing the Chasm does the latter.   
  • Fog of Uncertainty - No decision is absolutely certain, nor is the knowledge its based on.  You should recognize the areas of uncertainty (rather than pretend they don’t exist) and understand the uncertainty.  But you should make decisions anyway.   Uncertainty creates opportunity.     Also, consider this: how can you increase your opponents uncertainty?
  • Friction - no plan is ever executed  exactly as written.  Unpredictable things happen to prevent this.  make allowances and pay attention to execution.
  • Overwhelming Force - always bring to bear an overwhelming force against your targets, to bring about a decisive conclusion as quickly as possible.
  • Minimal Targets - identify the minimal set of targets necessary to achieve your goals.   Bring your force to bear against those and only those targets.
  • Speed of Movement - the speed with which your forces can be redeployed against new targets can act as a force multiplier.
  • Don’t Rely on Surprise - too often strategies are built around achieving surprise.    Surprise is difficult to achieve and unreliable at best.
  • Defense is Neutral/Negative -  A defensive posture is easier to take, but usually doesn’t advance you towards your goals.
  • Never Leave Forces Idle - always make the most of your forces by pro-actively applying them towards your objectives.

Bay Area Housing 02 Oct 2007 09:44 am

um, that’s one interpretation

In it’s earnings report yesterday, Citigroup announced that it’s profits were down 60%. Apparently, this sent Cititgroup stock up because investors took it as a sign that the worst of the credit troubles might be over. Maybe the bad news is all priced into the credit markets now. Or, perhaps thats wishful thinking — after all, the worst of the mortgage rate resets are still ahead of us.

Business & Software Development 29 May 2007 01:02 pm

Making Sense of Agile for Management

From my very first corporate software development project, I can remember thinking that there was something profoundly wrong with the way the software projects were managed - trying to set your plan in stone at the front, then manage your work to that schedule just always seemed impossible. It was never clear what value we were getting from our estimates and schedules — they were never accurate until the end of the project, and, as a manager it seemed like inordinate amounts of time went to revising the schedule and to reseting expectations with customers.

At Salesforce.com, we’ve transitioned to Scrum in the last year. I’d dabbled with some of the Agile methodologies in previous jobs, but this is the first time I’ve been part of a complete implementation of the practices. I have to say this is also the first time I’ve ever felt that things we do for project management all make sense and really add value over the course of the project. It makes us better at shipping product.

In the process here, I’ve read several books, but the one that I have found most useful as a manager has been Lean Software Development, by Mary Poppendieck. It goes beyond the individual practices to give a framework for why Agile works and ties the framework back to examples from other companies and industries. I found that it really helped pull the big picture into focus - it helped me understand where to spend my energy during the transition to get the most of the practices.

Salesforce.com & Technology 07 Dec 2006 08:19 pm

blogging on ADN

As many of you know, I’ve been working at Salesforce.com for a year now as the product manager for the platform web services API. I just put my first post up on our developer blog about what’s new in our 8.0 release. Check it out.

Software Development 09 Nov 2006 08:57 pm

Zero Tolerance Manifesto

Based on some conversations at my present job, I decided to write up what I learned during my time at BEA. These are the things it takes to keep a large development team productive. It only really works when these things are built into the culture. You will need tools and infrastructure to make this practical, but if you instill this into your culture, your team will build what you need when you need it.

Just to be clear, the most important thing you do is check in new or improved code into the product. The things below are preconditions to checking in code, the things you do to be a professional developer. If you’re doing this right, these things will speed you up, not slow you down. These are not an excuse to decrease your sense of urgency about moving your project forward. Have you checked in code yet?

These are in order of priority:

  1. Don’t f’ing break the build. Ever.

    1. build your changes before you check them in. It’s hard to believe I have to say this, but experience says I do.   I know it can be tempting.  But don’t do it.   Make sure you sync up with product line before you do it — building against a month old copy of source doesn’t really tell you anything.
    2. stick around after you checkin and make sure the group build succeeds. if you broke it, DROP EVERYTHING AND FIX IT. Fix it like your job depends on it. Because it does.
    3. don’t check in to a broken build. the second you check in to a broken build, you become part of the problem — you better start looking for the solution. Everyone hates to wait, but that’s what you should do. Or better, start looking for the person who broke it or his friends and make them fix it. Or better still, figure out what’s broken and propose the fix.
  2. If you want to break the build in the privacy of your own machine, that’s your business. The second you break the group build, the morale and productivity of every person in the product group dives towards zero. Unacceptable.
    Here are the steps you *must* take in order to avoid breaking the build.

  3. Don’t break tests

    1. run the tests for all affected areas and fix any regressions *before* you check in.
    2. check the results of the group tests after you checkin — assume any failures are yours until you explicitly rule it out. If you broke tests, fix them before you work on anything else.
    3. broken tests are not an excuse to ignore the tests. be sure your change doesn’t make the situation worse. if the tests that are broken directly cover the area you are going to be working on, you should probably fix the tests before you make your change. If the product isn’t currently at 100% pass rate, then you’ll have to baseline the product before you make the product and compare it the results after your change. yes, this sucks, but do it anyway.
  4. Tests are the teams safety net. Having all the tests passing all the time makes it dirt simple to figure out if you’ve broken anything with a change. When it’s dirt simple to figure that out, you will have more confidence in your ability to make changes safely — you will write more code and won’t shy away from refactoring or taking on changes in new areas.

  5. write tests. lots of ‘em

    1. write unit tests for the public methods on all your classes.
    2. write functional tests to verify that the key requirements of your feature are working.
    3. write functional test to verify that your dependencies on other parts of the product are still being satisfied. think of this as writing diagnostics — when these tests break, you should know where to look to solve the problem.
    4. when something turns up broken without a test, write one. don’t let the same regression happen twice.
  6. Tests are your safety net, even for your own code. If you want to be productive, having tests that show something is working gives you a great sanity check on your code, but it also pays dividends over the long haul — your tests keep you from breaking your own code.
    Tests are also your shield. If you write a feature and someone later discovers that some part of the feature that didn’t have a test is now broken, guess who’s going to have to fix it? You. Even if it was someone else’s change that broke the feature. The best way to avoid this is to have tests for every aspect of your code that matters. Then it’s everyone’s responsibility to keep that test passing with every checkin and you don’t have to worry about someone else breaking our stuff.

  7. During parallel development, integrate changes early and often

    1. When you fix a bug or finish a feature in version X, integrate it forward to version x+1 immediately (apply rules 1-3 to integrations too). No sense waiting, it’s only going to get harder.
  8. It is inevitable that at some point you will have to work in two branches of the code at once, usually because one release is ramping down while another is ramping up. When this happens, it’s important not to let the backlog of differences between the two versions build up. The sooner you integrate a change forward, the more likely it is to work and the more likely you are to remember what you changed and why.

  9. Fix bugs right away.

    1. When a bug comes in, fix it. Whatever you’re working on, come to a natural stopping point, then set it aside and fix your bug. If a bug turns out to be too large to be accommodated in the slack of your current sprint, put it on the backlog — and do it first thing next sprint.
    2. Leave slack in your sprint commitments to accommodate bug fixing.
    3. Don’t defer bugs indefinitely. If a bug isn’t important enough to fix now, then you should consider closing the bug. This is especially true for large bugs or minor enhancements of marginal value. Keeping it around is a drain on your attention and it invites you to keep other bugs with it. Don’t be careless, but don’t be overly cautious either — if a bugs important, it’ll come back.
  10. It is inevitable that bugs will sneak through even the most exhaustive testing suite. The unfortunate part of this is that these bugs always come up after you’ve moved on to something else. This is not an excuse to tolerate bugs, however. If you put off fixing the bug until “someday”, chances are you won’t fix it or that it will take you a lot longer to fix then than if you just fixed it today.

Business 17 Jul 2006 12:23 pm

Declining Cost of Production

I went through a phase of reading books that related economics to biology. If you think about it, when you’ve got a really good theory of economics, it should help you explain the things we observe in nature (animal behavior, evolution, etc).

During this time, I ran into this “law” — the cost of to produce a unit of any thing declines on an inverse power law relationship with the number of units produced (on a global basis). And it turns out this is true for many things, including such basic things as eggs. This was first observed by Kenneth Arrow, in his 1962 paper “The Economic Implications of Learning by Doing”. I ran into it in Bionomics by Michael Rothschild.

You hear a lot about Moore’s law and Metcalfe’s law. I’m always surprised you don’t hear more about this one, since its at least as profound in its impact on new technologies.

Bay Area Housing 21 May 2005 12:38 pm

The Fed starts backing down health of Real Estate Market

From the Wall Street Journal: The Fed Starts to Show Concern Over Bubble.

For a long time, Federal Reserve Chairman Alan Greenspan dismissed suggestions that the U.S. was in the early stages of a housing bubble. He talked about the extraordinary demand for houses among hard-working immigrants. He emphasized that housing, unlike stocks, is a local market, so it’s almost impossible to have a national housing bubble. He explained that it’s hard to speculate in a house that you own because to sell it you have to move out.

But there has been a little more concern creeping into his commentary in the past few months. “We do have characteristics of bubbles in certain areas, but not, as best I can judge, nationwide,” he told a House committee in February. Mr. Greenspan speaks to the Economic Club of New York at lunchtime tomorrow. If housing comes up in his remarks or if he is questioned on the subject by one of the prominent economists there, look for the Fed chairman to mention — as Fed Governor Donald Kohn did recently — the upturn in people buying vacation homes, second homes or other homes on the risky bet that housing prices will continue to rise as they have lately.

Mr. Greenspan hasn’t yet hit the “irrational exuberance” gong, the phrase he used to warn about the stock market in December 1996. The Fed and other bank regulators, however, this week warned banks to take more care with home-equity loans, noting that such loans are “subject to increased risk if interest rates rise and home values decline.” (Did you say decline? Gulp.) Even a slowing of the pace of increase in housing prices probably would dent consumer spending, which, for the past couple of years, has been helped by Americans tapping their home equity.

Other Fed officials have begun to express some anxiety. In a speech last month, Mr. Kohn said, “A couple of years ago I was fairly confident that the rise in real-estate prices primarily reflected low interest rates, good growth in disposable income and favorable demographics.” Mr. Kohn was a longtime adviser to Mr. Greenspan before his appointment to the Fed board.
No longer. “Prices have gone up far enough since then relative to interest rates, rents and incomes to raise questions; recent reports from professionals in the housing market suggest an increasing volume of transactions by investors, who…may be expecting the recent trend of price increases to continue,” Mr. Kohn said.

Interestingly, the one place I saw these speeched headlined, the headline was “Greenspan say no real estate buble”. I guess the story is the improbable rise of real estate, not the risk of the real estate market.

The thing is that Greenspan only ever speaks about the national market in the aggregate because that’s his job. Its not his job to manage regional economies (in fact, that might interfere with his management of the national economy). When he finally recognizes a real estate bubble, it will only be because it has reached national proportions.

Technology 21 May 2005 11:00 am

wikipedia is becoming the source for answers

From John Battelle’s Searchblog: Wikipedia and Search

A nice piece penned by Max Kalehoff.

A ranking of all Web sites based on the total volume of traffic received directly from search engines placed Wikipedia at 146 in June 2004. But in September 2004 it jumped in the ranking to 93; 71 in December 2004; and in March 2005, it was the 33rd most popular site in terms of visits received from search engines.

That means Wikipedia is impacting not only the trivial results of our Internet searches, but increasingly what content we consume and the types of answers we find to larger questions. This is a profound statement for anyone competing in the marketplace for attention to content and ideas.

Interesting. Wikis took off like weeds at work last year. The thing that’s been most valuable about the team wiki is that’s been a quick place to host a page that you need to share and possibly collaborate on. We *didn’t* get a a beautifully tended garden like wikipedia. I think it helps that wikipedia its modelled on an encyclopedia — the structure is simple and clear and there are clear ground rules for what an entry should look like.

Next Page »