Open Source Amiga OS

[Mrs Beanbag]

As someone who has worked on closed source software, I can tell you it is never complete either. The only difference is we have this thing called "release day" where it has to look complete to customers. There is a lot of code inside that is temporarily commented out because it didn't work well enough in time for the deadline. Also the marketing department keep moving the goalposts, and sometimes their non-technically informed requirements cause the code to get tied up in all kinds of horrible knots. Hacks and cludges get through to release because there isn't time to sort it out properly. But as long as it looks tidy on the outside, that's all that matters.

Code base is always full of "TODO" comments.

[Mrs Beanbag]

For what it's worth, today I told my manager that some computer was running at 99.9% CPU usage and was crawling because of some java software that is simply supposed to do something like FTP files.  I made the comment, "He needs to write his software for computers that are made today, not 20 years from now."  I have already gone blue in the face from them re-writing something as simple as transferring files in Java, and using UDP... but that's a bit off topic...

I used to work with a guy who insisted that since everyone has 3GHz quad cores and 4Gb of RAM we don't need to worry about writing efficient code. But that doesn't even make sense, since if you're processing ever larger amounts of data it becomes more and more important that your algorithms don't run in polynomial time.

[Mrs Beanbag]

As far as I'm concerned, as long as applications aren't jerks, they should be happy together.  I think memory fragmentation is a bigger issue, isn't it?  (Having so many different banks of memory, some slower than others can't be all that fun to write around in.)

Fragmentation shouldn't be too much to worry about as long as programs aren't wont to request large blocks of contiguous memory, which I guess is fairly rare these days. On old stock Amigas you could legitimately request 50% of Chip RAM in one go but a few Gb, not so much.
 
Besides, if that is a problem, one could maintain a single virtual address space, which would get round the fragmentation problem without breaking software, and have a few other advantages too (swap space, seg faults if unallocated memory is accessed). But unfortunately the real problem these days is malicious code. Computer security is big business. It's sad that computers should have to be so much more complex and less efficient just because of selfish idiots, but there you go.

[Mrs Beanbag]

There's a lot to be said for avoiding premature optimization especially if it comes at he cost of poor design, but I think that's taking it a bit too far. Reminds me of the Civ 4 updater that takes an hour to download the 100Mb patch purely because the process spends 99% of the time updating the bytes downloaded count I downloaded it manually from the same url in about 3 minutes...

There's premature optimisation, and there's long overdue optimisation.

There's also optimisation you should do before you even write a line of code. If you write the equivalent of a bubble sort to solve a problem it's never going to be fast no matter how much you try to optimise it later, and woe betide you if it becomes an issue two years later when it has become such a central point of failure that nobody dare touch it in case it changes the behaviour.

I used to get all the optimisation CRs in my queue but it was like trying to stop the tide coming in. I'd make the code faster and mark it as fixed, but by the time anyone got round to verifying it some other code got bloated and it was slower than before, so CR got re-opened and sent back