1. 13
  1.  

  2. 5

    Sigh. I agree with bits of this…. the need for bouts of stillness and deep thought and clean design.

    But I disagree with the details.

    overly quick release cycles.

    That’s sort of interesting. What is “overly quick”?

    I’m firmly in favour of release cadences. Why?

    Because if you do it often you get good at it.

    You get lazy. You automate away the drudge work. The manual stuff that goes wrong because you forgot a step.

    How quick is quick?

    Well how long do you need?

    If you have improved something for a customer, you have unit tested, coded, reviewed and system level tested it….

    How long do you need to wait? Will you really honestly look at it again?

    Code in your repository isn’t earning value for anybody, it’s actually a liability.

    Code deployed in production is.

    Facebook has a weekly release cadence… http://www.infoq.com/presentations/Facebook-Release-Process

    Is that too quick and thoughtless?

    When I listen to that facebook Chuck Rossi guy, I’m very impressed with his thoughtfulness and competence.

    I wouldn’t phrase it as “avoid overly quick release cycles”. I would phrase it avoid compromising quality by schedule pressure. A very different thing.

    I have heard many wondrous “Castle in the Air” designs. I seen some amazing paper designs.

    But I trust working, tested, in production designs.

    They may have faults. But they can always be improved.

    They can be reasoned about and the reasoning can be tested by reality.

    You can’t wish away Design Process.

    Nor should you.

    But it is not something that ceases when you start to do.

    Doing doesn’t stop you from designing, designing doesn’t stop you from doing.

    Sometimes one is spending more time typing, sometimes you are spending more time thinking. There is no boundary between the two.

    1. 2

      It’s “overly quick” if it changes again in the next release. More time percolating the feature through beta testing might have revealed the problems before release. Gating features into a release is somewhat orthogonal to release schedule, but common practice seems to relate the two. Slowing down the release schedule means new features in the pending release get more incidental testing while they wait to become the current release.

      1. 1

        It’s “overly quick” if it changes again in the next release.

        Did you listen to that facebook guys talk? Personally I’m impressed.

        If they have any sense they’re paying that guy Big Bucks.

        The strategies he is deploying on that front are really smart.

        1. 1

          Sorry, no. infoq has decided my browser isn’t worthy. I found a later talk on youtube, but I’m not sure it’s exactly the same topic and it’s an hour long, which is a bit much to skim through looking for the good bits.

          1. 1

            Eh. Understood.

            But that talk is worth the time… so book mark it for when you have some.

            I agree with TFA that working in such a frantic environment might not be the nicest from a work life balance…. but the strategies they are using to cope with that level of churn can be used to make any paced environment more tolerable.

    2. 2

      I wrote up a response to this: http://deliberate-software.com/skill-continuum/

      1. 2

        I cannot relate to this at all:

        My wife often comes out into the yard and asks me: “are you coding?” Often my answer is “yes”. Usually I am cutting twigs with a garden clipper, or moving compost around.

        1. 1

          I find that when I get stuck on a problem the best tactic is to back away from it and do something else. Without me consciously trying, new ideas on ways to solve the problem just pop into my head. That’s what he’s talking about - by doing something that’s calming and unrelated to his programming he frees up his subconscious to crunch on his problem. Everyone’s different, but you should give it a try!