Iain Dooley - Expert in computers and the internet

I run Benko, where we help remote teams work better than any in-person team EVER could. I also run, have 2 kids, am married, and think everyone needs to #LearnMMT check out https://www.benkoworks.com
I run Benko, where we help remote teams work better than any in-person team EVER could. I also run, have 2 kids, am married, and think everyone needs to #LearnMMT check out https://www.benkoworks.com
  • rss
  • archive
  • Friction: why you can’t build software as fast as you think you can

    A few years ago my team and I came up with a term for all the shit you have to do on a software project after you’ve done what you initially perceived to be the most significant part of the job:

    Friction.

    It derives from the fact that, when you first learn physics in high school, you are given formulae for calculating things like the speed at which an object will slide down an inclined plane and told to ignore friction (and wind resistance).

    When you get to a higher level of education and start taking friction and wind resistance into account it increases the complexity of the calculations considerably.

    The reason for doing this is obvious: despite the increase in complexity the same basic principles still apply and it’s easier to learn those principles initially in a simpler form.

    The problem with software estimation is that when we initially look at a task, unless we have specifically dealt with a similar problem before or have extensive domain expertise we’re looking at the “simplified version” that ignores friction and wind resistance.

    If we know basically *how* we would go about doing something, in our own minds, it’s as good as done. Sure there are bound to be a couple of curve balls but how hard can it be?

    It’s not until the force of Friction hits that we realise the task is an order of magnitude more complex and time consuming than we first thought.

    I don’t think there is any way of fixing it, either. As developers we’re expected to deal with a variety of situations in which we have no prior experience so really our only weapon in the war on undeliverable projects is to ruthlessly cull the scope of work until we’re only planning on doing the least amount of work we can.

    The question I like to ask myself (and my clients) is:

    “If we took this feature out of the product, would it be a different product?”

    If removing a feature won’t change the fundamental purpose of the product then we don’t need to build it before we launch.

    And let’s face it, “before we launch” is where most software projects fail!

    • June 3, 2013 (1:43 am)
    • 21 notes
    1. jarek-przygodzki reblogged this from iaindooley
    2. jarek-przygodzki liked this
    3. jonathanmrobson liked this
    4. justinjacksoncanada liked this
    5. haggen reblogged this from iaindooley
    6. anpurnama reblogged this from iaindooley and added:
      frictionny adalah kadang ada solusi yang lebih efisien atau kadang solusi kita sebenarny tidak diperlukan. itu...
    7. dhotson liked this
    8. tomtheandroid-blog liked this
    9. montogeek liked this
    10. montogeek reblogged this from iaindooley
    11. alexjsharp liked this
    12. hjr3 reblogged this from iaindooley
    13. neatocode liked this
    14. iaindooley posted this
© 2013–2021 Iain Dooley - Expert in computers and the internet