No, unit tests will not help with parts of this. Take today for me as an example: I need to update some python code which calls the database through SQLAlchemy. I can't remember half of SQLAlchemy in my head, so I begin digging for what I want in the documentation. No Carrot in 5 minutes. Around 10 minutes in, I find it, just to realize that I am poking at the low-level framework of SA. I hack up the code as I think it works. Application explodes somewhere deep inside SA with a missing cursor.
Then I spend about one hour trying to narrow down how I call the thing incorrectly. I also search for the error message, which prompts an upgrade of psycopg2 for a bug. Doesn't help. In the end, I realize that the calling convention I use is wrong and I should have called the thing differently.
This kind of problem is trivially mitigated with any static type system which is just a little stronger than what Java or C buys you (ocaml, Haskell).
Comments
No, unit tests will not help with parts of this. Take today for me as an example: I need to update some python code which calls the database through SQLAlchemy. I can't remember half of SQLAlchemy in my head, so I begin digging for what I want in the documentation. No Carrot in 5 minutes. Around 10 minutes in, I find it, just to realize that I am poking at the low-level framework of SA. I hack up the code as I think it works. Application explodes somewhere deep inside SA with a missing cursor.
Then I spend about one hour trying to narrow down how I call the thing incorrectly. I also search for the error message, which prompts an upgrade of psycopg2 for a bug. Doesn't help. In the end, I realize that the calling convention I use is wrong and I should have called the thing differently.
This kind of problem is trivially mitigated with any static type system which is just a little stronger than what Java or C buys you (ocaml, Haskell).