1. 6
  1.  

  2. 4

    There are many ways to terrible codebases. Yes that includes test-first.

    1. 4

      It might be even better if programming languages had features to assist modelling system as a whole, with top-down approach, before actual implementation. This is usually accompanied by type systems and rich support for defining abstractions. In Ruby (and lots of other similar languages) you don’t even have interfaces; usually you describe high-level design of your system by informal text, diagrams or keep it in mind, the language only allows you to write pretty low-level implementation. Ruby is high-level language, but it’s only high level in that it abstracts from memory management and so on, it’s not arbitrary high level, when you can express concepts with it, you can only write actions and “mechanical” computation sequences in it. This article suggests to use tests as an additional tool for modelling, which helps a bit, but there could be better tools for that.

      Also, the main problem with first approach, “straight to the implementation” is that refactoring is error-prone in dynamically typed languages.

      1. 3

        Ruby is high-level language, but it’s only high level in that it abstracts from memory management and so on, it’s not arbitrary high level, when you can express concepts with it, you can only write actions and “mechanical” computation sequences in it.

        Astute observation!

      2. 3

        One way to accidentally write bad code is to jump straight into the implementation, without considering the design, and then lock it in with tests.

        I’m afraid this is quite often the case because of presure from the business side of things. Everything must be implemented as quickly as possible!

        I don’t want to say design isn’t looked at in these situations. But I do believe implementation is started on too quickly. It can be troublesome if requirements as defined by business aren’t concrete yet and are changing all the time.