It took me a while to realize the situation, now I get it. I write big paragraphs so I'm going to make the important part stand out, Shaggy Hiker made me understand it with his last post.

When you add a new column and rows exist, each row has to get a value for that column. If you provide a default value, that's what everything gets. Otherwise, the only reasonable value is NULL.
Sometimes there's a default value that can be applied. Other times, you really can't pick one. When that happens, you have to allow NULL, and your UI has to be prepared to handle it. It's a pain. That's why, in general, it's recommended you fully design your tables BEFORE entering data. Adding columns when there's thousands of rows is tricky business.

REDevos: I agree with you, that NULL is problematic because its meaning is always ambiguous. But programming decisions are context-sensitive, and in this context we (probably) don't have the luxury of choosing "not null" values for the column. Maybe. "Never use null" is a policy that has very good arguments in favor, but "use null judiciously" is also a policy with very good arguments in favor. The only policy I can't support is "don't think about null, use it like salt".

ddeprospero, if I were you, I'd learn to safeguard my UI from null values. This can vary a little depending on how you're getting data from the db into the UI and vice versa. Maybe you haven't appeared in a few days because you don't like the answer. I don't think it's going to change.

A reasonable option might be to take a "no NULL allowed" approach like RDevos advocates. I don't know what the column actually represents, but this would involve adding a default value that effectively means "This hasn't been set yet." This is janky for Boolean, DateTime, and several other column types depending on your program's constraints. For example, your "unset" rule for DateTime might be "any date before 1980 represents unset", but only if your program shouldn't ever reasonably store a date before 1980. Generally it involves a little bit of thought and a little bit of updating your logic to handle this case.

Unfortunately, "you can update your program's logic to handle that safely" is functionally equivalent to how you handle leaving NULL inside. The only benefit to having a not-null value mean "unset" is you can tell the difference between, "Something in my program is screwing up and setting NULL" and, "I haven't filled in this column yet".

So you're going to have to update your UI/logic no matter what. No way around it.

If you're just straight executing SQL queries and using things like DataReader to deal with the values, you need to be checking that each value is not System.DBNull before you use it. If your code encounters DBNull, then you need to convert it to some reasonable value the UI can display. This is notoriously difficult for DateTime fields, as DateTimePicker doesn't have facilities for handling this.

Shaggy Hiker mentioned a different approach: some APIs have special methods or mechanisms you can use to adjust values from DBNull to a more UI-friendly type. There's probably half a dozen other ways to approach it.

But you can't escape it: now that your database might have values that aren't 100% valid in them, your UI and logic are going to have to adjust to that.