TDD is nice. However 90% of my work consists of finding out what the customer actually means and wants. Most of the “bugs” I have aren’t actually implementation bugs but more: the customer had an implicit assumption which I repeatedly asked if it was true and was confirmed to be true and in production actually, in fact, was not true
In a way, you are doing non-TDD with your customer, even if you are doing TDD with what they told you they want. If you can build your software/product a small step at a time and hand each piece to your customer to test, you may find that some of those issues go away. Essentially, try to get your customer to hand you each test. You complete that test and hand it back. They hand you a next test. You complete that test and hand it back.
@@avwie132 yeah, if only we could eliminate the customer, software development would be so much easier 🙂. Something of note - in Clean Code (I think that’s the book), he points out that 80-90% of the time we spend “writing code” is actually reading existing code. So, an effective strategy for speeding up “writing code” is to focus on making code faster and easier to read. You just said that you spend 90% of your time finding out what the customer wants and needs. Similarly, you are saying that you need to (or asking for advice on how to?) speed up the time it takes to find out what the client means and wants. Sure “agile” is a way to do that. The nuance, I think, is to figure out how to get your clients to willing, hopefully enthusiastically, participate in that process.
But when you build your code with TDD, it will get easier to change it later, when you find the new requirements. Because testable code is easier to change.
TDD for this type of code makes sense. But TDD for something like UI is rarely worth it. Fuzzy, brittle, slow, subject to change. The Roman numerals expected output will never change no matter how the business requirements change.
I love TDD, seriously. ESPECIALLY when the requirements are not that clear. It forces you to identify all the assumptions you are making and document them with your tests. If the requirements change, update the tests first, then fix the code wherever the tests fail. If a test passes, you can ignore that part of the code. This is the part of the project where TDD really shines. I'm surprised so many commenters are opposed to this.
TDD has a way to allow you to think about how to break your code, before you're writing it. This makes you cover a lot more angles once you get to the implementation and you end up with clearer code that tackles the problem with a far better overview. It also has a way to get you to enjoy the way you code. Few things are as satisfying as passing a test you wrote to be as difficult to pass as possible.
Exactly. Someone, or the dev themselves, must consider criteria and scenarios and write the acceptance tests. This takes time. And during this time, thinking & effort is made to the overall final solution--the development mistakes that would otherwise be overlooked, are considered when designing the tests.
A part of the time to write the code. I don't think the data show how long he as written the code to resolve the problem but how long he as written code to resolve the problem and in one case he write test code before writing implementation code and the other he write implementation code only
It's slow If the requirements change all the time which it has done in most projects I have been involved in. "327 tests failed". That is however another problem, code without a plan.
It does not work for huge code bases which need to be written initially. The devs tend to refactor the code again and again to a point where it fits to the given requirements. I saw teams which skipped this step of optimization because of TDD. It was just to much work to refactor the tests as well. There are use cases - but I would never use TDD for huge adaptations or green field projects. Here is a integration test at the beginning the only meaningful tool, where I see a bit of TDD as acceptable.
TDD is great when the requirements dont change. however, in a real project, requirements very often DO change. what do tests do? they make sure behavior remains as expected. they make the behavior of your thing STABLE. TDD is a tool to be used for when you know what you’re building and you dont want it to change if you are experimenting, or even just building a ui based application, TDD is a terrible tool to employ in the starting phase. once the systems are in place and everything behaves as expected, add tests for stability, then when engineers go to refactor it, the behavior stays the same
dont just blindly do what youre taught or what people, even experts tell you learn what things do and what the common use cases are. make an educated decision and trust yourself. if it didnt work out this time, then you’ve learned your mistake for the next time
Yeah - I think If he had had his memory wiped, the effect would have been a great deal more profound. Testing makes you developer faster. A LOT faster.
The practical problem with TDD is that most modern code is written in a framework like Django or React, and it's nearly impossible to write a test with mocks before you've written the code
My tickets have a title. Some have a description. Few have a clear description. Some tickets directives changed AFTER the ticket was solved, and then the ticket was reopened. Good luck doing TDD with that.
Depends on the scope and also the size of the team. When you are the only developer you can easily test each unit and function your self and you don't need to bother again -- 99.9% of my own software is written that way (games, interpreters, hacking tools, demos graphics solutions) and it saves easily 20-30% of time. When more people handle the code it starts to pay back the efforts. But when I was working in medical systems everything was defined and scoped before hand. As you don't want to accidentally inject too much of something or too little. And if you know something from A to Z, like this story, then there's no bloody need and it will speed things up.
A horrible example that feels kind of divorced from reality. It's easy to define everything necessary for the tests in such a relatively simple exercise, especially if you have already done it previously and you should already know how it's supposed to be implemented.
![Noob To Max With DRAGON REWORK In Blox Fruits [FULL MOVIE]](http://i.ytimg.com/vi/LnBMOinoOvA/mqdefault.jpg)
![Felix "Unfair" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/Oswujxm2Ag0/mqdefault.jpg)
TDD is nice. However 90% of my work consists of finding out what the customer actually means and wants. Most of the “bugs” I have aren’t actually implementation bugs but more: the customer had an implicit assumption which I repeatedly asked if it was true and was confirmed to be true and in production actually, in fact, was not true
In a way, you are doing non-TDD with your customer, even if you are doing TDD with what they told you they want.
If you can build your software/product a small step at a time and hand each piece to your customer to test, you may find that some of those issues go away.
Essentially, try to get your customer to hand you each test. You complete that test and hand it back. They hand you a next test. You complete that test and hand it back.
@ you’ve just reinvented Agile. I know all that. It doesn’t negate the fact that it is 90% of my work iterating over features with the customer
@@avwie132 yeah, if only we could eliminate the customer, software development would be so much easier 🙂.
Something of note - in Clean Code (I think that’s the book), he points out that 80-90% of the time we spend “writing code” is actually reading existing code. So, an effective strategy for speeding up “writing code” is to focus on making code faster and easier to read. You just said that you spend 90% of your time finding out what the customer wants and needs. Similarly, you are saying that you need to (or asking for advice on how to?) speed up the time it takes to find out what the client means and wants. Sure “agile” is a way to do that. The nuance, I think, is to figure out how to get your clients to willing, hopefully enthusiastically, participate in that process.
But when you build your code with TDD, it will get easier to change it later, when you find the new requirements. Because testable code is easier to change.
@@Monzy_ That is not exclusive to TDD, but is applicable to having code with tests.
TDD for this type of code makes sense. But TDD for something like UI is rarely worth it. Fuzzy, brittle, slow, subject to change.
The Roman numerals expected output will never change no matter how the business requirements change.
I love TDD, seriously. ESPECIALLY when the requirements are not that clear. It forces you to identify all the assumptions you are making and document them with your tests. If the requirements change, update the tests first, then fix the code wherever the tests fail. If a test passes, you can ignore that part of the code. This is the part of the project where TDD really shines. I'm surprised so many commenters are opposed to this.
TDD has a way to allow you to think about how to break your code, before you're writing it. This makes you cover a lot more angles once you get to the implementation and you end up with clearer code that tackles the problem with a far better overview.
It also has a way to get you to enjoy the way you code. Few things are as satisfying as passing a test you wrote to be as difficult to pass as possible.
TDD builds are slower yes. But not having tests is terrifying, especially if it's a project you'll be maintaining.
not doing tdd doesn't mean not having tests
@Pico141 writing tests reactively rather than proactively is also not great
It is anecdóticas data. But it is still interesting that it took him shorter with TDD given he knew the problem upside down.
The question is how long did it take him to write the test?
Exactly.
Someone, or the dev themselves, must consider criteria and scenarios and write the acceptance tests. This takes time. And during this time, thinking & effort is made to the overall final solution--the development mistakes that would otherwise be overlooked, are considered when designing the tests.
A part of the time to write the code. I don't think the data show how long he as written the code to resolve the problem but how long he as written code to resolve the problem and in one case he write test code before writing implementation code and the other he write implementation code only
It's obviously included in the time "with tdd".
It doesn't matter how long it took to write the test. Only overall time matters.
Companies usually accept 1 extra point for testing.
It is slow for devs that do not know what they are testing or writing tests to code that does not need testing at all!
Yes it is slow. Tests can take up over half of the the actual coding time.
Tell me that you don't watch the video without telling me you don't watch the video
you save a lot on debugging
I have to try. I start write my test from scratch. No test framework. And then i get my own get-roman function from scratch.
I actually check and I can answer if with a number 23/31% depending on the complexity of the project.
Matches my own experience. I'd love someone to show real studies, though.
It's slow If the requirements change all the time which it has done in most projects I have been involved in. "327 tests failed". That is however another problem, code without a plan.
It does not work for huge code bases which need to be written initially. The devs tend to refactor the code again and again to a point where it fits to the given requirements. I saw teams which skipped this step of optimization because of TDD. It was just to much work to refactor the tests as well. There are use cases - but I would never use TDD for huge adaptations or green field projects. Here is a integration test at the beginning the only meaningful tool, where I see a bit of TDD as acceptable.
TDD is great when the requirements dont change. however, in a real project, requirements very often DO change.
what do tests do? they make sure behavior remains as expected. they make the behavior of your thing STABLE.
TDD is a tool to be used for when you know what you’re building and you dont want it to change
if you are experimenting, or even just building a ui based application, TDD is a terrible tool to employ in the starting phase.
once the systems are in place and everything behaves as expected, add tests for stability, then when engineers go to refactor it, the behavior stays the same
dont just blindly do what youre taught or what people, even experts tell you
learn what things do and what the common use cases are. make an educated decision and trust yourself. if it didnt work out this time, then you’ve learned your mistake for the next time
Sorry - not a trustable anecdote unless he had his memory wiped before every iteration.
Yeah - I think If he had had his memory wiped, the effect would have been a great deal more profound. Testing makes you developer faster. A LOT faster.
But he was always faster with tdd, despite knowing the problem so well after multiple tries.
The practical problem with TDD is that most modern code is written in a framework like Django or React, and it's nearly impossible to write a test with mocks before you've written the code
My tickets have a title. Some have a description. Few have a clear description. Some tickets directives changed AFTER the ticket was solved, and then the ticket was reopened.
Good luck doing TDD with that.
Oh, if uncle bob friend likes TDD, then for sure TDD is great and not a waste of time! And for sure presented graph is just not just made up numbers😊
Depends on the scope and also the size of the team. When you are the only developer you can easily test each unit and function your self and you don't need to bother again -- 99.9% of my own software is written that way (games, interpreters, hacking tools, demos graphics solutions) and it saves easily 20-30% of time. When more people handle the code it starts to pay back the efforts. But when I was working in medical systems everything was defined and scoped before hand. As you don't want to accidentally inject too much of something or too little.
And if you know something from A to Z, like this story, then there's no bloody need and it will speed things up.
I think this is an example where tdd migh be better, but most real world developing scenarios are probably not good for tdd.
TDD, pair programming just sucks. It is a not very used way of lowering the developers cost.
Intuition? Common sense? Obvious? Debunked.
No, in Jesus' Name Amen ✝️
A horrible example that feels kind of divorced from reality. It's easy to define everything necessary for the tests in such a relatively simple exercise, especially if you have already done it previously and you should already know how it's supposed to be implemented.