Horrible Apple update quality

There are two updates waiting to be done on a Mac Mini Mavericks server here. Both cause problems.

Security update 2014-005 1.0

This one causes the App Store app to become corrupt. There’s no way to do more updates once this happens. Also, there’s no way I know of to download it and reinstall it. If this isn’t a FUBAR, I don’t know what is. Yes, I restored an image and tried again, same thing. The restore didn’t recover the app, though. Don’t know why. Had to take it from another Mavericks machine and copy it over (you have to use sudo to get past OSX’s reluctance to replace that app). Now I’m wondering if applying the update, then replacing the App Store app would work, but I’m sick and tired of this nonsense, so it will have to wait until I gather enough energy to try yet again.

OSX Server 3.2.2

This is the second update in the queue right now. According to the description, it brings all kinds of improvements, but in actuality, the only thing that it clearly brings is a total failure of the wiki system. There’s no connection to the database. Had to restore from backups every time I tried this update.

This is not good. Let’s just hope that some later update is better.

One more thing…

It would be good if I could tell software update I don’t want these two updates, but I don’t see how. So the machine continuously keeps bugging me about restarting to do them. Very, very aggravating.

The flip side of TDD

There is a problem with Test Driven Development (TDD) and security. Even though I’m a severe proponent of TDD and do my own development (largely) that way, I notice a strong conflict between good architecture and TDD. I’ve also seen mention of this effect in the journals lately, so I’m not alone in this.

What happens is that TDD promotes doing early and minimal implementation, then iterate over it until you get everything to work. Fine, everyone loves that. But early “ready-to-run” code usually implies a simplistic architecture. Not necessarily, but usually, please note.

Now, you start out writing all these tests, ostensibly free from architecture and design assumptions, only specifying the actual requirements. But you aren’t as free from assumptions as you’d like, since just by writing the test in a particular place, you’ve already made an architectural decision. Once the tests are in place and your code runs fine, you’re very free to refactor and improve your code safely, in a kind of localized way, class by class, method by method. But as soon as you do serious changes of architecture, your fine unit tests are usually blown away and have to be refactored or even rewritten. That hurts, and humans try to avoid things that hurt.

After a few incidences like that, you get gun shy and tend to not change your architecture unless you really and truly have to. And there are very few instances where you really have to do that just to make your system work (which is the only criterion your stakeholders care about). So, the architecture of TDD developed systems tend to be monolithic or at least simplistic and kinda smacked together, and guess what… there’s nothing more important than good architecture for secure systems. Forget about buffer overruns and unsafe APIs. It’s the architecture that makes your system fragile or resilient. The rest is just dust and filling. You can make systems run fine and bug free without a solid architecture, but you can never make them really robust.

Personally, I refactor my architecture anyway, over and over, but the only incentive I have is because I’m compulsive obsessive and people tend to not appreciate it (until years later, that is). Every other external incentive there is tells me not to do it. Timeboxing also increases the pressure to leave the architecture unchanged.

So I think we’re in the process of discovering the Achilles heel of TDD: even if the code is great, it much too easily leads to a poor and insecure architecture, and I think we need to take that seriously and try to come up with answers to fix this problem.

And, no, BDUF isn’t the answer.