Re: Slow software
One of my "favourites" was finding that, in an externally written "modernisation" to our embedded system, all of the config options for all of the separate processes were placed into a big XML file (so it could be a "single system config" - which isn't a particularly bad idea). A convenient utility routine allowed a process to read a value, by the simple method of reading the XML into an in-memory DOM[1] and walking the tree to the named value. Then the process would read a second value, by the simple method of reusing the convenient utility, hence reading the XML into an in-memory DOM and walking the tree to this second named value. Then the process would read a third value, by a simple utility call, which read the XML into an in-memory DOM and walked the tree to this third named value.
And so on, until it had effectively read all of its options at startup: saves using tricky command line options - even though the processes were all started by a master process (don't call it an "init") which had learnt the list of processes to start by reading the XML into a DOM and iterating over a certain node's children...
Of course, not all of the coders thought of getting all the config values ready at the start of a process, so some of them would, after running for a period of time, pause doing useful work, read the XML into a DOM...
[1] use of a stream parser - Expat - was deemed "too complicated" for an embedded system, given you could just build the DOM in one simple call to this library that everyone uses in all the StackExchange examples, rather than some weird library no-one had heard of...