1. 10

  2. 15

    I’ve seen too many developers (myself included) do too many dumb things deleterious to the host organization in the name of software quality to trust any blanket statements re: software scheduling.

    I really like the examples in the article, but I can’t help but notice that all of the bad code could just as easily been produced by a time-unconstrained developer who made a bad call.

    Our industry tends to wring its hands over a false dichotomy of “scheduled development yields garbage code” and “unscheduled development yields golden, perfect engineering”. The reality tends far more towards “scheduled development yields code without generally revenue-impacting defects” and “unscheduled development yields okay-to-good code without generally revenue-impacting defects that solves a problem the business no longer is focusing on”.

    From a business standpoint, so much of our quality metrics are just masturbation and inefficiency–inefficiencies the market is perceived as not willing to bear. We forget this at our peril.

    1. 5

      The real warning sign in this story is the engineers massaging the estimates to make them fit a a date given from on high. I’ve been on teams where this happens. If it happens, someone is too focused on pleasing the boss instead of on getting the job done. Sitting a bunch of engineers in a room and forcing them to come up with a set of compelling lies about how long something is going to take because you’re afraid to say “this isn’t possible in that time” is the definition of counter-productive.

      An organization can’t function if people are afraid to communicate honestly to management.

    2. 7

      Counterpoint from Planning & estimating large-scale software projects:

      Engineering does not work in a vacuum, and there are commercial contracts that will be signed, at a high level, without your involvement. Deals that will have been agreed before you joined the organization. “Tie-ins” with other companies that have specific launch dates. Marketing and finance departments that want to know when they’ll need to spend £xm on producing a Christmas ad campaign.

      Entire teams of people, who aren’t software engineers, and are used to being held accountable for delivery dates in their fields, will expect you to be able to tell them when your part of a project is likely to be done.

      1. 3

        Thing is that if you don’t involve your technical people in the initial project planning when you decide on timelines and sign contracts then these numbers are just being pulled out of thin air. Expecting your technical team to commit to made up timelines and budgets that weren’t informed by technical expertise means that you’re setting up your project to fail.