Slightly tangent, this reminds me of the story of the game developer that would allocate a few tens or hundreds of megs of RAM early on in the project and not touch it. He knew that as the project was nearing completion, they would get squeezed on available RAM. Then he could just go and delete a single line of code and, bam, tons of free RAM.
This seems like a slight variant of SDD: dickhead-driven-development. Clever, but your coworkers still hate your guts.
There's a real reason to do something similar if you're developing for a memory constrained devices with a API someone else will use.
If you have objects your API functions return that API consumers will use, you want to make sure the objects don't suddenly grow in size, since that would eat into the memory that the consumers expect to use. So, you'd pad those objects with unused fields, and then if you need to add a new field, you can just use that padding area.
Something similar applies if you're sending objects over the wire, since you may not want to increase the size of the message later.
I knew someone who did this with humans at a bigcorp.
He’d politick to transfer in new teams for the sole purpose of building a supply of cannon fodder. Staff up in good times, and purge fodder when layoff targets came to protect “his people”.
This seems like a slight variant of SDD: dickhead-driven-development. Clever, but your coworkers still hate your guts.