Comments by "Lee Rothman" (@leesoftwareengineer) on "TDD Isn't Hard, It's Something Else..." video.

  1. Yes because running the application locally and stepping through your code with a debugger is sooo much more efficient. Your prototype will gradually evolve and grow in complexity and then you’ll need to refactor, but you won’t because it will break.
    7
  2.  @joanvallve7647  Personal experience isn’t really going to give you anything other than an opinion. Scientists repeat their findings multiple times to confirm their results. Then they submit their work to be published. This is so other people in that field can scrutinise this work and tear it apart and debunk it (or occasionally not). I often find most people’s decisions and approach to software development are just opinion based and not based on data and facts. I’m not sure why our industry doesn’t take lessons from this approach?
    5
  3. Errr I think you’re missing one of the major points of test first. Tests after will not help you with the design because it’s already done.
    4
  4. I like the way you come up with a well thought out argument and backed it up with evidence. #flatesrtheralert
    4
  5. Agreed and also guilty. I’m going to try and change my workshops and use TDD in them. I think it will suit some subjects better than others? A session on refactoring code to use design patterns would be a good use case I think? I’m sure it will make attendees more confident in TDD in general?
    4
  6. Small incremental changes to the legacy code using the strangler fig pattern will allow your legacy code to evolve into well designed and easy to change code.
    3
  7. As I’ve already touched on in an earlier comment, I think most approach’s to software development is often based on opinions not on anything concrete. Why do we not take lessons from the scientific community and use experiments and observations (sounds like agile to me) to influence decisions on the way we write code? Science had their Age of Enlightenment back in the 17th century, when will get ours?
    2
  8.  @joanvallve7647  Comparing objects like this (hardware) to software isn’t really a useful comparison. They are not put in to the hands of users in an iterative process. The most efficient way to develop software is not waterfall, but agile. Not fake agile that doesn’t adopt best engineering principles, real agile where teams follow XP practices. The benchmark for good software isn’t just that it works (any fool can get software working), but that it is easy to change for all developers ie readable and simple to understand.
    2
  9.  @joanvallve7647  if your unit tests are tightly coupled to your infrastructure then that’s just down to badly written tests, not something wrong with TDD. Try getting the right experience people working on it 😜. Again high test coverage being used as an argument. That is not the reason behind TDD it’s a beneficial side effect. Infrastructure changes and changes to domain logic are separate concerns and will have separate tests. We could go on like this for months, let’s just agree to disagree shall we? You’re comfortable in your approach and I am with mine.
    2
  10.  @joanvallve7647  OK then let’s not, fine by me. So where is your evidence then? You say it’s been ‘empirically proven’ so show us the evidence to back this statement up.
    2
  11.  @joanvallve7647  It’s not the truth unless you have evidence to back up any of your rambling BS. It is being adopted because otherwise we wouldn’t be having these messages on this channel about this video. That is the reality, you can keep on saying the earth is flat all you want but provide evidence for it, but you can because it not true.
    2
  12.  @joanvallve7647  Well when there are comments about code coverage I’d say that the title of the video is spot on.
    2
  13. That’s what a CD process will help with.
    1
  14. You have bugs then, enough said.
    1
  15.  @trappedcat3615  If you write a failing test first then write the code to make it pass, then I’m not sure how it can be wrong? If you mean that the result you wanted wasn’t correct then your requirements were wrong. That’s not a problem with the test, that’s a problem with the process of gathering acceptance criteria.
    1
  16. ‘Agile project managers’ sounds like an oxymoron to me 😀.
    1
  17.  @joanvallve7647  What facts are you referring to? Can you send a link to published peer reviewed research paper for us please? Agree with your views about scrum. Most places I’ve worked don’t really do scrum in that they do not adopt the engineering practices that are at the core of agile. If you’re not adopting these practices you’re not agile. It’s been ambushed by non technical people and think it’s about management. The original signatories of the agile manifesto are software developers, so that should indicate what’s at the core of the idea. These are the same type of engineers that are frustrated when companies/people use the word ‘scrum’. I’m with them. This video explains it better than I can, https://youtu.be/3cmY-OFuuCw?si=cdHxF0KkeZLUDeAr
    1
  18.  @joanvallve7647  More than 15 years so you got that easy to lookup piece of data wrong. So you use the statement ‘Almost no one’, what is this based on? Some data published somewhere? How long something has been around for and the assumption that almost no one uses it is not proof. You can’t just dismiss something and come up with your own opinion as fact. That’s what some religious people do when arguing against scientific findings like evolution. As I’ve asked before get some evidence to back up your argument, if not it’s just your opinion and nothing more.
    1
  19.  @joanvallve7647  How you get to the statement ‘software industry is stupid’ is beyond me. As for evidence that the practice of TDD is a positive thing, if you watch the video studies are quoted that back this up. There are more studies out there that also produced data that would indicate this, I’ll get the links if you want? In the mean time perhaps you can share your data with us?
    1