7 ms·
Can't Driven Development
- hitchstory 2y agoThis doesnt make a lot of sense. The set of things your software cant do is infinite. The set of potential errors is massive and many if not most are unrelated to domain logic.
- rmanolis 2y agoI think it's is finite. I couldn't think of another "can't" statement for my exercise. If you find any please tell me to patch the code. You thinking in DDD because in CDD there is no domain logic. Everything is part of stack trace tree
- salomonk_mur 2y agoYour exercise can't: 1. Tell me who other people's friends are. 2. Change it's output if a spammer stops pinging after 1 hour. 3. Count the amount of times a person has pinged in their lifetimes. 4. Build a pyramid 5. Output Pi 6. Make me lasagna
- rmanolis 2y agoyes, it can't. For some “can't” statements, you don't need to write any error. The “can't” statements in CDD are for actions and input that you could take, but the software deliberately prevents you from doing them. There are no actions or input, requested from the exercise that make it possible to do the list you gave me, so it does not make sense to create an error for them.
- kubanczyk 2y agoThe TDD and DDD ultimately tell you which inputs are of interest. CDD doesn't, so it's apples to oranges. People who think that specifically TDD is a programming technique didn't get the entire memo. It can drive you to design and re-design your app's inputs. But that part of TDD is tacit - hard to teach.
- rmanolis 2y agoWhat are you even talking about? where in the article say that CDD does not care about inputs? Also in the article says "The main idea of TDD is to design the software through tests." do you disagree with that?
- tharkun__ 2y agoI guess while you're at it, you are also going to tell us how you solved the halting problem then? Why not prove if P != NP or not while you're at it. I mean after all, we just couldn't think of any other reason why P should not equal NP, so it must be equal, mustn't it? Not being able to quickly think of more test cases for whatever you're trying to test at any given moment does not prove anything. You also seem to be very hung up on something about stack traces that I'm really not able to figure out what it really is, even though you keep mentioning it.
- rmanolis 2y agoThe best way to architect, test and develop software
- BoiledCabbage 2y agoCan you describe how this is different from TDD. From what I understood it seemed like you listed a collection of requirements for TDD failure cases, named them "can't" statements and then did TDD on them. But I believe there is more to it, but I couldn't see it. Could you list the types test cases you would have created if you had done TDD on this same problem? And how they'd be different?
- rmanolis 2y agoIn TDD, I would have to iterate over the hello_from procedure 900 times to create the software design. In CDD, I created first the software design by translating "can't" statements to errors and then iterate over the errors following specific rules to create a tree of stack traces that created the software design and then I TDD over that design to complete the application.
- athorax 2y agoThis is just TDD. Your tests should be written to verify and gaurd against "cants" not verify the happy path
- rmanolis 2y agoIt is not TDD because CDD does not architect the software through refactoring passed tests. It architects the code from the errors by following specific rules
- thanks_dang 2y agolol
- sunir 2y agoGuard conditions, assertions, constraints and tests are dynamic limits on code and are critical to maintain quality despite code rot and drift from changes. Static constraints like types can also be also good, where types are good. I applaud anyone who advocates to focus on the unhappy path over the happy path. On a side note 25 years ago was the end of the dot.com and the height of the y2k scam and I have never seen developers more burnt out than then; but that’s because I was just starting my career then. I don’t know about previous eras like the 89 crash and recession. I am not sure why the OP has rose coloured glasses of the past. But it’s always good to treat history with a little more interest.
- rmanolis 2y agoI put coloured glasses on the past because back then companies didn't request developers to know more than one programming language. They just used fancy words for simple tasks.
- thanks_dang 2y agoDevelopers were more in tune with the entire tech stack down to silicone. Today you’d be “unreasonable” for asking such a thing.
- atomicnumber3 2y agoYeah because back then the tech stack was: php apache mysql linux it was so small we could put it into an acronym. Meanwhile in 2024 you could barely begin to even describe any individual layer of the stack with so few words. You'd be out of breath before even beginning to finish describing React. (btw it's silicon, not silicone).
- athorax 2y agoGood ole PAML stack :)
- rmanolis 2y ago
- svilen_dobrev 2y agonegative assertions are more powerful/expressive than positive ones. e.g. "Not an enemy" is more powerful than "A friend" - the latter limits the possibilities a lot. or, #ifndef GONE is more powerful/flexible than #ifdef PRESENT Of course, sometimes one wants exactly that specific things that positive assertions do. But IMO that's rarely the case, it's just going positive seems simpler/easier to think of. one may say, in some system of rules, "Dont's" are more usable than "Do's". Think cultures..
- thanks_dang 2y agoWell boys, it’s not quite April 1st but the shitposts can’t wait and Christmas came early this year.
- cfrak 2y agoThis is just TDD without tests.
- rmanolis 2y agoit has tests, and better than TDD
- QuasarOne 2y agoCCD is an analysis, not a development method.