Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Can't Driven Development

rm4n0s.github.io

Post reply on HN
Print view View original

41–50 of 54 posts

Re: Can't Driven Development

#41

Post by kubanczyk »

rmanolis wrote: post #13
salomonk_mur wrote: post #12

Earlier quoted context omitted.

Your 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

yes, 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.

The 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.

Re: Can't Driven Development

#42

Post by rmanolis »

tharkun__ wrote: post #40
rmanolis wrote: post #37

Earlier quoted context omitted.

Odin can make stack traces as error types. Your system with Java will break if someone else add an AuthenticationFilter, but my system in Odin will not even compile until I have handled all the stack trace paths that include AuthenticationFilter. Do you see the differences between handling stack traces with union types rather than string?

I don't see how it improves or gives me anything, no. See, the `AuthenticationFilter` sits outside of my REST resource. I could not care less that someone configured it and that at runtime, based on some configuration that can change without even needing a recompilation, this filter will either be there on the stack or it won't. My resource does not interact with this filter in any way and when an error happens somew…

Odin's way does not mean that you have to do something for every Exception that is thrown to you. Also, in Odin SQLException can not exist, it is too generic, but SQLClosedConnException which is more specific can give a different story to a stack trace, which you can handle.

For example, in Authentication_Filter_Error union, you will have another union called SQL_Verify_Account_Error, that it will contain SQL_Error enum with the Closed_Conn value.

Imagine your stack trace like this Authentication_Filter_Error -> SQL_Verify_Account_Error -> SQL_Error.Closed_Conn

Now when you know that can happen (through CDD), you can create a switch statement to catch the specific stack trace, to call the system administrator in the middle of the night to check what happens.

This is how software should handle its errors and there is not even a need to log it.

In your scenario, you wake up, you go to work, everyone is screaming at the office, you check the logs, you see the problem, and then you call the system administrator for the problem.

Re: Can't Driven Development

#43

Post by rmanolis »

tharkun__ wrote: post #39
rmanolis wrote: post #38

Earlier quoted context omitted.

Look, you are very lucky for sticking with java and using your OOP knowledge to move to other programming languages. But an unexpected change will come and you will need to go back studying on your free time. This is always happening in our industry, you were just lucky for not living it because you sticked with Java.

You are making assumptions there, even though in this very conversation you have evidence to the contrary. In professional capacity over the years I have used Perl, PHP, Bash, SQL (various dialects), Java, Groovy, Kotlin, Scala, Javascript and Typescript. I did not move from Java and OOP knowledge to other programming languages. I started with with languages that don't (have to) use OOP. I still work with Typescript…

What company gives you time to learn at work? where do you even live?

Re: Can't Driven Development

#44

Post by rmanolis »

kubanczyk wrote: post #41
rmanolis wrote: post #13

Earlier quoted context omitted.

yes, 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.

The 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.

What 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?

Re: Can't Driven Development

#45

Post by tharkun__ »

rmanolis wrote: post #42
tharkun__ wrote: post #40

Earlier quoted context omitted.

I don't see how it improves or gives me anything, no. See, the `AuthenticationFilter` sits outside of my REST resource. I could not care less that someone configured it and that at runtime, based on some configuration that can change without even needing a recompilation, this filter will either be there on the stack or it won't. My resource does not interact with this filter in any way and when an error happens somew…

Odin's way does not mean that you have to do something for every Exception that is thrown to you. Also, in Odin SQLException can not exist, it is too generic, but SQLClosedConnException which is more specific can give a different story to a stack trace, which you can handle. For example, in Authentication_Filter_Error union, you will have another union called SQL_Verify_Account_Error, that it will contain SQL_Error e…

I agree with half of that. The half that says that most exceptions thrown from libraries today and in much of application code as well are way too generic and hide the details that might allow handling them in a `message` String.

However, that's still about the exceptions thrown from down thread, not from the call path part of the "stack trace".

I.e. your situation would never happen.

    Authentication_Filter_Error -> SQL_Verify_Account_Error -> SQL_Error.Closed_Conn
This stack / call path is impossible, because when the AuthenticationFilter notices that the token is invalid, it returns a 401 or 403 or whatever is appropriate and my REST resource is never actually called. There's no SQL being run and very definitely no "connection closed" error occurred.

But let's say there was a distinction made with proper exception types and instead of `SQLException("Connection closed")` and `SQLException("Statement timeout")`, I actually received `SQLException(ConnectionClosedException())` vs. `SQLStatementTimeoutException`. Now, without string parsing, I can know that either the connection just closed or that the statement was aborted due to timeout. If these are checked exceptions, I have to declare that I'm aware these can happen and what I want to do with them: Handle or rethrow.

However, a myriad of such exceptions can happen. I would probably have to declare 20-50 exceptions way up in a REST resource layer. Not only can these two happen, but many other situations on the network or database side and on the JSON parsing side for the payload I receive, some exceptions from my business logic etc.

And for most of these, what can I do? If the connection to the database closed, all I can do is to log the error and return a `500 Internal Server Error` to my caller. Guess what I can do when a statement timeout occurs? I log the error and return a `500 Internal Server Error` to my caller. For a statement timeout I can't even return a `400 Bad Request`, because it's not knowable if the statement timeout occurred because the database was simply overloaded in that moment or if the request itself was created with such parameters as to always cause a statement timeout. Until we see the logs and through investigation figure out that it wasn't a bad request after all anyway. We were missing an index and the table finally grew large enough for that to matter.

So yeah, I'm good with `RuntimeException` and handling only very few specific ones ever.

Also nobody will be screaming when the token is invalid and I definitely don't call any system administrator. That's something you as a developer look into. Same with the statement timeout.

Re: Can't Driven Development

#46

Post by tharkun__ »

rmanolis wrote: post #43
tharkun__ wrote: post #39

Earlier quoted context omitted.

You are making assumptions there, even though in this very conversation you have evidence to the contrary. In professional capacity over the years I have used Perl, PHP, Bash, SQL (various dialects), Java, Groovy, Kotlin, Scala, Javascript and Typescript. I did not move from Java and OOP knowledge to other programming languages. I started with with languages that don't (have to) use OOP. I still work with Typescript…

What company gives you time to learn at work? where do you even live?

You did read the "while doing it" part, right?

Talk about it. Prolifically. Say that you have no problem working on "that thing" but that it's going to take more time, because you're unfamiliar with that language / library / service or whatever it is that would slow you down.

Then adjust your estimates. If you are working on something completely new that you know nothing about, put in "Spike" tickets to prototype things. Put larger estimates for the tasks themselves after for the "unknown unknowns". When you discover an unknown unknown that can be extracted as a new ticket from what you are currently working on, create a ticket for it to make that fact visible and adjust your current ticket to say it got extracted so nobody still expects your ticket to do it.

Tickets are not evil, tickets are protection for developers - create them and comment on them, explaining what is going on and what needs to be done. Most companies aren't really "evil" in that way. They just don't know better. If you do happen to be in one of the 'actually evil' ones, go find another company to work for. E.g. if developer are not allowed by process or actually prevented by the ticketing software from just creating tickets and moving things around as necessary: run. Don't walk. Run from that company.

Re: Can't Driven Development

#47

Post by rmanolis »

tharkun__ wrote: post #45
rmanolis wrote: post #42

Earlier quoted context omitted.

Odin's way does not mean that you have to do something for every Exception that is thrown to you. Also, in Odin SQLException can not exist, it is too generic, but SQLClosedConnException which is more specific can give a different story to a stack trace, which you can handle. For example, in Authentication_Filter_Error union, you will have another union called SQL_Verify_Account_Error, that it will contain SQL_Error e…

I agree with half of that. The half that says that most exceptions thrown from libraries today and in much of application code as well are way too generic and hide the details that might allow handling them in a `message` String. However, that's still about the exceptions thrown from down thread , not from the call path part of the "stack trace". I.e. your situation would never happen. Authentication_Filter_Error ->…

No, you don't need to just log and return 500, you can make the software to handle these kind of errors.

You could make the software call the system administrator and return a message to the user "Try again in an hour, the system administrator is fixing it now"

Or if it is a timeout, the software will call amazon to buy a new machine to scale the database and send a message to the user "Try again in an hour until we scale the system".

Developer's job is to automate error handlers and not be the error handlers.

If you can see the stack trace tree, then you can plan far ahead, but to do that we need to destroy this "agile" mindset, that is always in a hurry and doesn't let you to think that far ahead.

Re: Can't Driven Development

#48

Post by rmanolis »

tharkun__ wrote: post #46
rmanolis wrote: post #43

Earlier quoted context omitted.

What company gives you time to learn at work? where do you even live?

You did read the "while doing it" part, right? Talk about it. Prolifically. Say that you have no problem working on "that thing" but that it's going to take more time, because you're unfamiliar with that language / library / service or whatever it is that would slow you down. Then adjust your estimates. If you are working on something completely new that you know nothing about, put in "Spike" tickets to prototype thi…

The “while doing it” does not work if you don't have experience with similar language. If you don't believe me, try learning Rust while writing a server for your work.

Tickets are useless. Real tickets are unit tests that need to pass for the software to be ready for production.

Tickets cannot protect you, only Odin's switch statement on stack trace can protect developers from bad changes.

I will give you an example, you worked for a company and on a ticket, you wrote “this code works this specific way and should never be changed”. After 6 months, the company fires you and another senior developer takes your place. The new developer never read previous tickets because no one read old completed tickets, so no one will read the message you left, and they will change the code accidentally.

However, in Odin with unit tests and locking stack traces with switch statements, the code is really protected from these kinds of accidents.

Re: Can't Driven Development

#49

Post by tharkun__ »

rmanolis wrote: post #47
tharkun__ wrote: post #45

Earlier quoted context omitted.

I agree with half of that. The half that says that most exceptions thrown from libraries today and in much of application code as well are way too generic and hide the details that might allow handling them in a `message` String. However, that's still about the exceptions thrown from down thread , not from the call path part of the "stack trace". I.e. your situation would never happen. Authentication_Filter_Error ->…

No, you don't need to just log and return 500, you can make the software to handle these kind of errors. You could make the software call the system administrator and return a message to the user "Try again in an hour, the system administrator is fixing it now" Or if it is a timeout, the software will call amazon to buy a new machine to scale the database and send a message to the user "Try again in an hour until we…

    you can make the software to handle these kind of errors.
No you can not do this in all cases and I described multiple cases in my comment already in which you can't reasonably do anything automatic. Let me explain.

    You could make the software call the system administrator
But why would I do that for every `StatementTimeoutException` at every moment of the night and why do I need to bake that into my error handling? That isn't actually handling the error.

    "Try again in an hour, the system administrator is fixing it now"
Please never ever do this to either your users, who may believe it or you "system administrators" who do value their sleep or have other more pressing matters to attend to.

    Or if it is a timeout, the software will call amazon to buy a new machine to scale the database
I described a case in which automatically adding resources would actually be wrong in that it would completely mask the actual problem, which is that the developer did not think about the access patterns of the software they wrote enough and did not add the right index to the database. If you keep scaling your database automagically you'll pay AWS until you run out of money and have not solved anything. Believe me, a missing index can eat up a lot of resources before anything gets better. And until then your software will just keep failing and keep adding resources. And in this case it won't help at all because your new machine will not even be used by the query. It'll still only be one node handling your read and that is constrained by actually reading data from the disk and that's super slow because you forgot the index!

    Developer's job is to automate error handlers and not be the error handlers.
I've yet to see anything that the developer should do here based on an individual error in the software. One case where something should happen automatically on the database would be if the database was running out of space. You should have monitoring in place that takes care of that. And no it should not be your software doing that scaling because it received a `SQLError -> DatabaseOutOfDiskSpace` error. If it gets that far, all of your calls to the database will fail. Which of your error handlers should be the one handling it and why should we let things get that far in the first place? Have monitoring set up outside of your actual software that adds disk space automatically before you run out of space and then make it scream very loudly to your system administrators and developers about it, so that they can take a look at it and determine if this was a legitimate "well I guess we got too many more paying customers now, this was OK" or if it was the last update that went out having a bug that keeps filling up the database with BS data and you need to make an emergency bug fix or maybe you're deliberately being DDoS'd and it got past your DDoS protection and you better do something about that or the DDoS'er is gonna make your AWS bill go crazy.

    If you can see the stack trace tree
Again, nothing and nobody cares about up-stack. I care about down-stack when handling such errors.

    we need to destroy this "agile" mindset, that is always in a hurry and doesn't let you to think that far ahead.
Nothing to do with agile at all. You should think about error handling every time you code anything. For example as we've seen above, think ahead about your database running out of disk space. But don't make every developer think about it for every single piece of code they ever write. That makes no sense to have them try to handle these situations. It'd actually make it worse and these people would never get any actual work done either.

Re: Can't Driven Development

#50

Post by tharkun__ »

rmanolis wrote: post #48
tharkun__ wrote: post #46

Earlier quoted context omitted.

You did read the "while doing it" part, right? Talk about it. Prolifically. Say that you have no problem working on "that thing" but that it's going to take more time, because you're unfamiliar with that language / library / service or whatever it is that would slow you down. Then adjust your estimates. If you are working on something completely new that you know nothing about, put in "Spike" tickets to prototype thi…

The “while doing it” does not work if you don't have experience with similar language. If you don't believe me, try learning Rust while writing a server for your work. Tickets are useless. Real tickets are unit tests that need to pass for the software to be ready for production. Tickets cannot protect you, only Odin's switch statement on stack trace can protect developers from bad changes. I will give you an example,…

    The “while doing it” does not work if you don't have experience with similar language. If you don't believe me, try learning Rust while writing a server for your work.
I can't try that unfortunately. I have tried to push trying Rust "for whatever next service we need" but nobody took me up on it :shrug:. That said, yes, many moons ago, probably about 25 years actually, I did have a job that paid me to learn how to write a TCP server in Perl that would take commands in a custom plain text protocol to do certain things. It was a drop-in replacement for the same thing written in C by some developer that long since had left the company and nobody knew how it worked or knew C. And no I did not know any C either, nor had I written any servers in Perl at that point (though to be fair I had used Perl to do some quick regex magic).

But I think I'm barking up the wrong tree here anyway, because you seem to be completely set in your thinking that nobody should need to know more than exactly one programming language and that should probably be Odin and that anyone thinking or saying anything else is just wrong. Well good luck to you getting paid and having fun. I definitely know that someone with your attitude towards learning and expanding ones horizon would not last long at my place.

    only Odin's switch statement on stack trace can protect developers from bad changes.
I mean, until here it was all "fun and games" but either you've also had fun here leading me with your little crusade or you actually believe this. But then I can't help you.

    on a ticket, you wrote “this code works this specific way and should never be changed”
Ah I see now. You misunderstood what I was saying about tickets and what they're good for. Ticket != (unit) tests! Tests are what describes how your software should behave.

What I was saying about tickets being protection is that they're protection against "the company" and process and being rushed all the time "because agile". Embrace them. Use them to your advantage. Someone gives you one ticket to do X and do it quickly but you don't know the library or service involved? Convert it into an Epic and extract 10 tickets including some prototyping in spikes.

    Odin with unit tests
s/Odin/Any compiled language with good typing/g ;)
Post reply on HN