rosewater

It’s been a long time since I’ve posted here.

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

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.  

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.

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.

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.

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.

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.

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.

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

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.

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

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.

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

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.

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

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.

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.

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

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.