Tools are not the Answer

  • The premises of the article: "hold programmers to a higher standard" "always do a good job, don't cut corners, use TDD"

    are neat and all, and the TDD part is all fine and good and such, but this is advice for a singular person.

    One doesn't address systemic flaws by essays urging individual moral fortitude and hope for the best.

    Next, the author mentions that tools are not the answer, as they clearly wish to focus on character and ethics on the part of the individual, but then by mentioning their confidence in automated testing suites, they are belaying the eponymous claim of the title of the article itself.

    While I don't expect The Atlantic to provide much insight for our industries internal consumption, neither does this authors article.

    I will argue that it is explicitly a question of tooling:

    Does ones task have a safety component that requires one to adhere to realtime coding standards? (no function pointers, for example, no malloc/free, for example...stack only..)

    Is a realtime operating system a requirement? hard realtime? soft realtime? milliseconds, microseconds, picosecond response time, deterministic response time range etc?

    Is a statically typed compiled language like Haskell or Ocaml an option? Those folks literally sit around proving things, as far as determinism and systems go...

    I just find that the article was lumping entertainment website development in with vehicle braking systems with word processors... and the moralistic tone, while possibly inspiring to some, is rather a refusal to consider the systemic aspects to the issues raised/discussed...

    my unsolicited $0.02

    :D

  • Other engineering disciplines have solved this: Actual engineers are in charge of the project, and dictate a realistic schedule.

    Too often, we have marketing-driven schedules and we aren't empowered to fight back, so we cut corners instead.