Python task manager from scratch, part 18: Adding a feature

A while ago we created a Task object, and we put a due field of type datetime on it. The idea is that tasks have due dates (we call them "due dates," but they should be represented as datetimes, because at least sometimes we want a time of day and not just a day).

I hadn't yet bothered to actually implement it.

What to do

1. Change the serialization and deserialization logic;
2. Change the Web display;
3. Test the serialization and deserialization.

The results are in the current commit in the veery/ repository.

The morals of this part of the story

1. The serialization and deserialization logic needed changing only at the repository level. In many systems this would have necessitated all sorts of downstream changes. This is still a small piece of software, but it would already have been very easy to go wrong. In general, not just the difficulty but the locality of a bugfix or feature addition is an excellent (and underrated) metric for the health of a code base.
2. Serializing and deserializing a datetime seems straightforward, but you'll notice that the logic is fiddly. I wouldn't swear in court that it's bug-free. I'd call this the first time in this project when I really felt discomfort at using a text file as the database. In practice, the reasons people use established databases over ad hoc solutions have a bit less to do with fancy performance guarantees, and a bit more to do with their having already ironed out stuff like this, than you think.
3. It's tempting to do this sort of thing en passant while you add a bunch more fields to Task or change the persistence backend or whatever. Resist that urge. Any modern version control system, and any respectable software engineering environment, is perfectly well suited to handling small changes. (At my first Big Tech job, my first submission to the version control system was a one-character change in a single file. It was gratefully accepted.)

Have fun.