In my part of the big project I’m on, I have a class called a Playlist, and a corresponding database table. Based on my analysis of how many Playlists are likely to be used in the lifetime of a system, I decided that an int would be more than adequate storage space for the sequential internal id number. Actually, a short would probably be adequate, but there isn’t any compelling reason to use shorts on modern systems since they don’t save much storage and they’re slower to process (is that true in Java? I know it is in C/C++.) And so I happily used this id all over the code.
But the author of a fairly recent new part of the system (call him cow orker #1, or C1), that runs on a different computer, decided he wants to use Playlist as well. Fine, I’m all about code re-use. But then somebody else (call him cow orker #2 or C2) decided that he wanted to generate Playlists on that computer system, he couldn’t generate his internal playlist ids from a database sequence the way I do, because they don’t have a database on his computer, and so rather than coming up with a better idea, decided to use time_t’s for the internal ids. But here’s the problem – time_t is a long, not an int. So he stored the time_t into the internal id, and then complained when it came back with a different id than the one he stored.
When C1 complained about this to me, I said “Playlist is my class, and I have no need for it to have a bigger id, fix C2’s code to not use time_t”. He said he couldn’t do that, because C2 works for a different section and isn’t maintaining that code any more. Plus he’d written his own Playlist creator that used the same time_t method.
I still maintained that the problem was with him, not with me, and I shouldn’t have to change all my working code just to accomodate his design flaw. But my boss sided with him. So I went off and changed my database schema, created scripts to change all the database tables and indexes that use that internal id (and our version of PostgresSQL doesn’t have ALTER TABLE ALTER COLUMN, so it wasn’t trivial), and changed over 40 Java files, that probably use that id in a few hundred places. It took me almost a whole weekend to make all the changes and test the bits of the code that I’m responsible for. I didn’t test the parts of the code that run on C1’s part of the system, because frankly this change was to accomodate him and I didn’t want to have to learn his part just to make sure this fix fixed the problem he was having.
The change went into the system the other day. And it didn’t entirely fix the problem. I said “well, I did my part, the rest is up to C1” and assigned the bug report to him. And he closed it saying that he found one place where this internal id was being cast to an int, and included a snarky comment that I didn’t properly unit test the change. Ok, leaving out the fact that I didn’t even want to do the change, and it that this was his part of the program and I don’t even know how to run that part, and I don’t have that kind of computer to test it on, when you change one of the fundamental base classes of the entire system, one that’s used in every part of the system, it’s no longer unit testing, it’s system testing. And system testing is what QA does, not developers. They have the systems and data and procedures to do that.