You are under the impression there is some "good" part of our current government that should not be abolished. This is incorrect; every part is under the control of corrupt politicians and the corporations that fund them. I did a blog entry last month on the corruption around the FDA, picking one of the easier to like departments just to show how invasive that influence is. I don't know if electing Ron Paul will be sufficient to change much, given the likely deadlocks with Congress. But a vote for anyone else is certain to be useless at improving things.
Saying that API versioning rejects backwards compatibility isn't quite right. The transition to adopt HTTP 1.1 instead of 1.0 didn't involve immediate backwards incompatibility. It's possible (albeit more expensive) to roll out a new version while simultaneously continuing to support the old one for some time. That's the way many real systems that need to operate while continuing to improve lurch forward. I work on PostgreSQL, and the current command line client can still talk to server versions going back at least five years. That doesn't stop introducing new versions of the client protocol that new clients and servers know how to speak.
As for the specific Netscape server crashing example you gave, there are two missing pieces there: a second server implementation, and having open-source implementations as a reference. The fact that closed-source code can be buggy in an undocumented, inexplicable, and unfixable way is well understood. I don't see extrapolating a useful argument for or against APIs from that though; I just see one against using closed source software.
The existence of the IETF standards disproves this is the way things have to happen. That works by having multiple interoperable implementations before the standard is accepted. Then no one can rely too specifically in implementation details; any simple test against both implementations would fail. Your arguments around API issues are a bit narrow in terms of how language implementation specific you're making them. There's no reason the sort of web services being discussed here can't use a RESTful type of API for things, with published source code that implements it.
Versioned APIs are another useful path through the backward compatibility vs. innovation trade-offs. If you push the concept of an API version into the software very early, that gives more freedom to release a new one that innovates as necessary. The Mozilla Add-on version mechanism is one of the most popular examples. Add-ons break, but the scope of that problem is certainly not as dire as you're making it out to be.
It's not like one could develop an OS kernel based on some documented open API.
One of the first design goals for Linux was following POSIX, even though the standard was too expensive for Linus. While standards like POSIX and TCP/IP don't directly state how an OS kernel must be written, wanting to comply with them does shape the basic form the kernel needs to take.
If you read the Tanenbaum-Torvalds Debate thread, one of the recurring themes there is that even having easily available source code (as MINIX did) isn't enough. One of the necessary components to growing a software community is one or more maintainers willing to incorporate changes from contributors. And that's where these web service oriented companies fail the worst.
The question raised but not answered here is whether any knowledge of work systems was involved in the design of the software. If you built a completely generic help desk program that anyone could deploy usefully, then you might be OK here. The test I would apply is whether you could rightly expect any other company to use the program were it released to the world as open source. If it's in any way tied to the workflow of the job you have, in your position I'd hand the code over ASAP. Whether it was legal or not for you to develop the program is in a fuzzy area. You should consider the very real possibility you'll only find out for sure during a lawsuit you'd have to bring for wrongful termination, after you're fired for taking that knowledge outside of the company without permission.
Anyway, writing new software isn't worth anything to most companies. Long-term maintenance of any codebase dwarfs initial development. You'd need to turn statements like "streamline a lot of processes and take a lot of the burden off my team" into a proper business plan, one where that savings funded supporting the code base if you weren't there, before the thing you've developed is worth anything to most places. That's actually a much harder job than writing the code, because you need a mix of both technical skills and business planning to do it well.
Corrupted MyISAM Tables after a crash are expected from MySQL when using that storage engine; that's the only sort of incident I can think of here that could rightly be attributed to that database. slashdot converted to Innodb a long time ago though. The downthread griping sounds like it could just as easily be a caching issue above the database instead, given there's multiple layers of that going on.
The last big shady insecure voting machine company scandal was at a company led by a major Republican supporter. This call toward Anonymous is simple misdirection, like a magician making you look at the thing he's pointing to so you miss where the action is at. The most likely cause of US voting fraud are the corrupt and heavily financed members of the major parties, who are frantically trying to preserve the status quo right now. And they're surely not going to vote to hang themselves.
When I say "early versions of Spinrite", I was talking about SpinRite 1.0 through 3.1. The whole "sector interleave" concept Steve Gibson was playing with in the late 80's seemed to usefully revive things on ancient MFM/RLL drives that no other utility would handle. I'm not sure exactly when those were above and below INT13, but you can see in the history document he was trumpeting operation below the BIOS in the 3.1 release. But any capabilities like that stopped being feasible for anything still working well over 10 years ago, and surely the later versions only do INT13 level work. Gibson built up a lot of goodwill in the industry from his work in the late 80's and early 90's, which he has shamefully kept milking to this day.
Earlier versions of Spinrite would talk to drives at a level below how DOS would access them. It would sometimes recover data that regular drive access calls wouldn't, by knowing tricks related to how MFM and RLL drives actually stored data.
Nowadays, this cannot work. Drives abstract away access to their low-level internals. This allows them to do things like quietly remap bad sectors in a way the user doesn't even see. The work Spinrite used to do--find questionable sectors, read multiple times to get a good copy, then relocate to a better area of the drive--is being done in drive firmware. You can't see it, can't modify it; your only access to it are SMART statistics and calls to request various types of deeper checks. If you do a read of a bad sector, the drive is going to decide how many times to retry that read, and if it gets a good read after a bad one it will move that data somewhere else. That all happens without the software doing the read even realizing what happened.
Spinrite started out as a great product, but it stopped being useful for anything a long time ago. The fact that it's still sold anyway makes me sad, as I used to have a lot of respect for its author.
The "mail myself a copy" trick is useful for overturning a patent you have prior art in that form on. Problem is that such a lawsuit is still expensive, and people still have the patent (to use against others and you!) while it's ongoing. It's very fun to get slapped with a patent infringement lawsuit on something you have proof you developed earlier; having it doesn't just make the lawsuit go away.
If you release as open-source, it lowers the odds people will even try to patent something. That's particularly true if they actually get the idea from your implementation, one of the concerns here. Making a patent obviously uneconomical to your competitors is a more valuable thing than being able to overturn a patent they've already been granted. Patent busting is not always easy even with public prior art; when it's private instead that makes it even harder.
My current startup is two years old and going strong with less than $30K at its start, and I financed its unprofitable beginning using my savings. And I moved out of my mom's basement during the first.com boom! One of my customers is Y-Combinator darling Heroku, who did quite well on their small bit of seed money. I'm more of a fan of the web based startup nowadays, have actually had worse luck at the $1M+ startups. But I can see your point that a single patent wouldn't be very expensive if you're in that environment, and that success on a small budget is pretty unlikely for most companies.
Thanks for the flame-free discussion, can't remember the last time I went several messages deep into something at Slashdot without a condescending message to be found.
I don't see anything to disagree with you on here, except the difficult subject of whether there is such as thing as a true invention covered by a good patent anymore. I'm not sure where your original "laughably small" comment came from now though. We agree that even a 5-figure attorney fee would be a small one nowadays. Even if you find prior art 3X as fast, the amount of money involved is only small if you don't value your time as worth very much. In all of the 4 startups I've been involved in, the lost opportunity cost of the real inventors in the company wasting time on something is the most expensive thing there is.
The amount of money to apply for a patent is small. The amount it takes to be granted one is a lot more complicated. One of my ideas was patented by the startup employer I had at the time, Wireless burstable communications repeater. Almost all the actual money involved in applying for it went to Hoffmann & Baron, LLP. If you think you're going to get a useful patent granted without an experienced patent attorney firm like that, you're being quite optimistic. I can't even imagine how much time it would have taken to duplicate the patent industry specific parts of the argument with the patent office that they managed, doing it myself instead. The prior art search alone found dramatically more things to reference than I had--while running up a five-figure bill. I am certain the patent would have been rejected as "already covered by #XYZ123" without that input. I had to carefully rewrite our original patent text to distinguish exactly what ways it was different from every one of those, and even after that the patent office spat out another half dozen to address. Responding to the initial rejection letter usefully is another difficult task that I doubt would have been successful without input from the lawyers.
Having done it once successfully, I wouldn't dream of trying to get a tech industry patent again as an individual if I didn't have a bare minimum of $100K to burn along the way. The only thing more expensive than hiring patent attorneys is how expensive it would be to do that yourself instead--presuming that as an inventor your time is actually worth something. Don Lancaster's Patent Avoidance Library is filled with horror stories about small companies trying to do useful things with patents. About the only thing that's changed since he wrote those is the idea that companies don't buy patents. Now they do, but only in bulk. You need to have a large pile of them before you have decent odds of doing anything with them.
The problem with this idea is that it puts a multi-year time delay into executing your business strategy fully, as well as bleeding a large pile of money towards the patent system and the lawyers around it. Patents are really only a usable defense or weapon for a company that already has lots of cash to burn. Chasing after getting them as a startup is a very low percentage bet.
There's actually one more point to consider along this line. When facing a well funded competitor, one thing that can happen is them patenting some aspect to what they do, one that is obvious and necessary for any similar design to function. One way you can block this is by releasing your version as open-source, serving as an undeniable bit of prior art. Killing competitors with patents is now the area unfair tech business competition is fighting hardest at. One reason I push out almost everything I do to the world is to keep someone else from patenting the ideas I come up with.
Even if your competitors do then take that idea and steal it, it's possible to make money from the fact that your version is always months ahead in innovations. It's easier for someone who is actively inventing ideas to keep the flow of research moving forward, compared to someone that who just copied a subset of their ideas.
For the next ten years, the real question in the US is which of investment and cash accounts will lose value slower, relative to what you can buy with the result. Just like real estate, the idea that the stock market has any sort of consistent return is a myth that came about from 20 years of general US prosperity (1980 to 2000) where that was usually true--and that relatively short trend is completely busted now.
You've missed the real implication that comes from realizing good software developers are actually worth more than just about anything else. The right answer to your thought experiment problem is to find/make an accountant who knows enough about software to write useful specifications, then put them to work on testing the results too. That's cheaper than trying to turn a good developer into a entry-level accountant, which isn't very likely to go well anyway.
You don't need a tablet to have a focused writing environment. Applications like WriteRoom and its Windows clone Dark Room have been doing that just fine for years. I'm happy for the author that he's gotten his ADD issues under control by getting a system that can't do more than one thing at a time well. And that he's caught up to the full day of work battery capacity I've had since 2009 using my Acer Aspire One and a 9-cell battery.
There are only two things drive cache can help with significantly. When rebooting, where memory is empty, you can get memory primed with the most common parts of the OS faster if most of that data can be read from the SSD. Optimizers that reorder the boot files will get you much of the same benefit if they can be used.
Disk cache used for writes is extremely helpful, because it allows write combining and elevator sorting to improve random write workloads, making them closer to sequential. However, you have to be careful, because things sitting in those caches can be lost if the power fails. That can be a corruption issue on things that expect writes to really be on disk, such as databases. Putting some flash to cache those writes, with a supercapacitor to ensure all pending writes complete on shutdown, is a reasonable replacement for the classic approach: using a larger battery-backed power source to retain the cache across power loss or similar temporary failures. The risk with the old way is that the server will be off-line long enough for the battery to discharge. Hybrid drives should be able to flush to SSD just with their capacitor buffer, so you're consistent with the filesystem state, only a moment after the server powers down.
As for why read caching doesn't normally help, the operating system filesystem cache is giant compared to any size it might be. When OS memory is gigabytes and drive ones megabytes, you'll almost always be in a double-buffer situation: whatever is in the drive's cache will also still be in the OS's cache, and therefore never be requested. The only way you're likely to get any real benefit from the drive cache is if the drive does read-ahead. Then it might only return the blocks requested to the OS, while caching ones it happened to pass over anyway. If you then ask for those next, you get them at cache speeds. On Linux at least, this is also a futile effort; the OS read-ahead is also smarter than any of the drive logic, and it may very well ask for things in that order in the first place.
One relevant number for improving read speeds is command queue depth. You can get better throughput by ordering reads better, so they seek around the mechanical drive less. There's a latency issue here though--requests at the opposite edge can starve if the queue gets too big--so excessive tuning in that direction isn't useful either.
From where I'm setting Twitterrific seems like the "hello, world" of app development, but maybe this OSHA thing is even simpler; it's hard to get too excited about either. Regardless, it is a very popular app, which should have some correlation with the developers being decent. I'd like to think that "people who have won the app store competition and build something popular" are a more competent and productive group, on average, than "people who develop phone apps on government contract". And bad programmers always end up costing a lot more than good ones, even when they deliver junk that happens to meet spec.
Check out How much does it cost to develop an iPhone application? for a few numbers that are in line with what you roughed out here. There seems cause to complain about the quality of the result, but the price tag itself isn't surprising at all. $150 an hour is also cheap for a good mobile phone developer, given the rampant gold rush speculation driving up salaries in that section of the market right now.
"The Door Into Summer" is a great start. One of the less popular Heinlein books is one of my favorites: the short story collection published as "The Unpleasant Profession of Jonathan Hoag". There are two stores in there, "They" and "All You Zombies...", that have inspired countless other time travel and "is this the real world or a simulated one?" tales.
Slashdot Mirror
You are under the impression there is some "good" part of our current government that should not be abolished. This is incorrect; every part is under the control of corrupt politicians and the corporations that fund them. I did a blog entry last month on the corruption around the FDA, picking one of the easier to like departments just to show how invasive that influence is. I don't know if electing Ron Paul will be sufficient to change much, given the likely deadlocks with Congress. But a vote for anyone else is certain to be useless at improving things.
Saying that API versioning rejects backwards compatibility isn't quite right. The transition to adopt HTTP 1.1 instead of 1.0 didn't involve immediate backwards incompatibility. It's possible (albeit more expensive) to roll out a new version while simultaneously continuing to support the old one for some time. That's the way many real systems that need to operate while continuing to improve lurch forward. I work on PostgreSQL, and the current command line client can still talk to server versions going back at least five years. That doesn't stop introducing new versions of the client protocol that new clients and servers know how to speak.
As for the specific Netscape server crashing example you gave, there are two missing pieces there: a second server implementation, and having open-source implementations as a reference. The fact that closed-source code can be buggy in an undocumented, inexplicable, and unfixable way is well understood. I don't see extrapolating a useful argument for or against APIs from that though; I just see one against using closed source software.
The existence of the IETF standards disproves this is the way things have to happen. That works by having multiple interoperable implementations before the standard is accepted. Then no one can rely too specifically in implementation details; any simple test against both implementations would fail. Your arguments around API issues are a bit narrow in terms of how language implementation specific you're making them. There's no reason the sort of web services being discussed here can't use a RESTful type of API for things, with published source code that implements it.
Versioned APIs are another useful path through the backward compatibility vs. innovation trade-offs. If you push the concept of an API version into the software very early, that gives more freedom to release a new one that innovates as necessary. The Mozilla Add-on version mechanism is one of the most popular examples. Add-ons break, but the scope of that problem is certainly not as dire as you're making it out to be.
It's not like one could develop an OS kernel based on some documented open API.
One of the first design goals for Linux was following POSIX, even though the standard was too expensive for Linus. While standards like POSIX and TCP/IP don't directly state how an OS kernel must be written, wanting to comply with them does shape the basic form the kernel needs to take.
If you read the Tanenbaum-Torvalds Debate thread, one of the recurring themes there is that even having easily available source code (as MINIX did) isn't enough. One of the necessary components to growing a software community is one or more maintainers willing to incorporate changes from contributors. And that's where these web service oriented companies fail the worst.
The question raised but not answered here is whether any knowledge of work systems was involved in the design of the software. If you built a completely generic help desk program that anyone could deploy usefully, then you might be OK here. The test I would apply is whether you could rightly expect any other company to use the program were it released to the world as open source. If it's in any way tied to the workflow of the job you have, in your position I'd hand the code over ASAP. Whether it was legal or not for you to develop the program is in a fuzzy area. You should consider the very real possibility you'll only find out for sure during a lawsuit you'd have to bring for wrongful termination, after you're fired for taking that knowledge outside of the company without permission.
Anyway, writing new software isn't worth anything to most companies. Long-term maintenance of any codebase dwarfs initial development. You'd need to turn statements like "streamline a lot of processes and take a lot of the burden off my team" into a proper business plan, one where that savings funded supporting the code base if you weren't there, before the thing you've developed is worth anything to most places. That's actually a much harder job than writing the code, because you need a mix of both technical skills and business planning to do it well.
Corrupted MyISAM Tables after a crash are expected from MySQL when using that storage engine; that's the only sort of incident I can think of here that could rightly be attributed to that database. slashdot converted to Innodb a long time ago though. The downthread griping sounds like it could just as easily be a caching issue above the database instead, given there's multiple layers of that going on.
The last big shady insecure voting machine company scandal was at a company led by a major Republican supporter. This call toward Anonymous is simple misdirection, like a magician making you look at the thing he's pointing to so you miss where the action is at. The most likely cause of US voting fraud are the corrupt and heavily financed members of the major parties, who are frantically trying to preserve the status quo right now. And they're surely not going to vote to hang themselves.
When I say "early versions of Spinrite", I was talking about SpinRite 1.0 through 3.1. The whole "sector interleave" concept Steve Gibson was playing with in the late 80's seemed to usefully revive things on ancient MFM/RLL drives that no other utility would handle. I'm not sure exactly when those were above and below INT13, but you can see in the history document he was trumpeting operation below the BIOS in the 3.1 release. But any capabilities like that stopped being feasible for anything still working well over 10 years ago, and surely the later versions only do INT13 level work. Gibson built up a lot of goodwill in the industry from his work in the late 80's and early 90's, which he has shamefully kept milking to this day.
Earlier versions of Spinrite would talk to drives at a level below how DOS would access them. It would sometimes recover data that regular drive access calls wouldn't, by knowing tricks related to how MFM and RLL drives actually stored data.
Nowadays, this cannot work. Drives abstract away access to their low-level internals. This allows them to do things like quietly remap bad sectors in a way the user doesn't even see. The work Spinrite used to do--find questionable sectors, read multiple times to get a good copy, then relocate to a better area of the drive--is being done in drive firmware. You can't see it, can't modify it; your only access to it are SMART statistics and calls to request various types of deeper checks. If you do a read of a bad sector, the drive is going to decide how many times to retry that read, and if it gets a good read after a bad one it will move that data somewhere else. That all happens without the software doing the read even realizing what happened.
Spinrite started out as a great product, but it stopped being useful for anything a long time ago. The fact that it's still sold anyway makes me sad, as I used to have a lot of respect for its author.
The "mail myself a copy" trick is useful for overturning a patent you have prior art in that form on. Problem is that such a lawsuit is still expensive, and people still have the patent (to use against others and you!) while it's ongoing. It's very fun to get slapped with a patent infringement lawsuit on something you have proof you developed earlier; having it doesn't just make the lawsuit go away.
If you release as open-source, it lowers the odds people will even try to patent something. That's particularly true if they actually get the idea from your implementation, one of the concerns here. Making a patent obviously uneconomical to your competitors is a more valuable thing than being able to overturn a patent they've already been granted. Patent busting is not always easy even with public prior art; when it's private instead that makes it even harder.
My current startup is two years old and going strong with less than $30K at its start, and I financed its unprofitable beginning using my savings. And I moved out of my mom's basement during the first .com boom! One of my customers is Y-Combinator darling Heroku, who did quite well on their small bit of seed money. I'm more of a fan of the web based startup nowadays, have actually had worse luck at the $1M+ startups. But I can see your point that a single patent wouldn't be very expensive if you're in that environment, and that success on a small budget is pretty unlikely for most companies.
Thanks for the flame-free discussion, can't remember the last time I went several messages deep into something at Slashdot without a condescending message to be found.
I don't see anything to disagree with you on here, except the difficult subject of whether there is such as thing as a true invention covered by a good patent anymore. I'm not sure where your original "laughably small" comment came from now though. We agree that even a 5-figure attorney fee would be a small one nowadays. Even if you find prior art 3X as fast, the amount of money involved is only small if you don't value your time as worth very much. In all of the 4 startups I've been involved in, the lost opportunity cost of the real inventors in the company wasting time on something is the most expensive thing there is.
The amount of money to apply for a patent is small. The amount it takes to be granted one is a lot more complicated. One of my ideas was patented by the startup employer I had at the time, Wireless burstable communications repeater. Almost all the actual money involved in applying for it went to Hoffmann & Baron, LLP. If you think you're going to get a useful patent granted without an experienced patent attorney firm like that, you're being quite optimistic. I can't even imagine how much time it would have taken to duplicate the patent industry specific parts of the argument with the patent office that they managed, doing it myself instead. The prior art search alone found dramatically more things to reference than I had--while running up a five-figure bill. I am certain the patent would have been rejected as "already covered by #XYZ123" without that input. I had to carefully rewrite our original patent text to distinguish exactly what ways it was different from every one of those, and even after that the patent office spat out another half dozen to address. Responding to the initial rejection letter usefully is another difficult task that I doubt would have been successful without input from the lawyers.
Having done it once successfully, I wouldn't dream of trying to get a tech industry patent again as an individual if I didn't have a bare minimum of $100K to burn along the way. The only thing more expensive than hiring patent attorneys is how expensive it would be to do that yourself instead--presuming that as an inventor your time is actually worth something. Don Lancaster's Patent Avoidance Library is filled with horror stories about small companies trying to do useful things with patents. About the only thing that's changed since he wrote those is the idea that companies don't buy patents. Now they do, but only in bulk. You need to have a large pile of them before you have decent odds of doing anything with them.
The problem with this idea is that it puts a multi-year time delay into executing your business strategy fully, as well as bleeding a large pile of money towards the patent system and the lawyers around it. Patents are really only a usable defense or weapon for a company that already has lots of cash to burn. Chasing after getting them as a startup is a very low percentage bet.
There's actually one more point to consider along this line. When facing a well funded competitor, one thing that can happen is them patenting some aspect to what they do, one that is obvious and necessary for any similar design to function. One way you can block this is by releasing your version as open-source, serving as an undeniable bit of prior art. Killing competitors with patents is now the area unfair tech business competition is fighting hardest at. One reason I push out almost everything I do to the world is to keep someone else from patenting the ideas I come up with.
Even if your competitors do then take that idea and steal it, it's possible to make money from the fact that your version is always months ahead in innovations. It's easier for someone who is actively inventing ideas to keep the flow of research moving forward, compared to someone that who just copied a subset of their ideas.
For the next ten years, the real question in the US is which of investment and cash accounts will lose value slower, relative to what you can buy with the result. Just like real estate, the idea that the stock market has any sort of consistent return is a myth that came about from 20 years of general US prosperity (1980 to 2000) where that was usually true--and that relatively short trend is completely busted now.
You've missed the real implication that comes from realizing good software developers are actually worth more than just about anything else. The right answer to your thought experiment problem is to find/make an accountant who knows enough about software to write useful specifications, then put them to work on testing the results too. That's cheaper than trying to turn a good developer into a entry-level accountant, which isn't very likely to go well anyway.
Cake is loaded with deeply awkward black magic and bad practices
Wow, I didn't realize they'd copied Rails so accurately.
You don't need a tablet to have a focused writing environment. Applications like WriteRoom and its Windows clone Dark Room have been doing that just fine for years. I'm happy for the author that he's gotten his ADD issues under control by getting a system that can't do more than one thing at a time well. And that he's caught up to the full day of work battery capacity I've had since 2009 using my Acer Aspire One and a 9-cell battery.
There are only two things drive cache can help with significantly. When rebooting, where memory is empty, you can get memory primed with the most common parts of the OS faster if most of that data can be read from the SSD. Optimizers that reorder the boot files will get you much of the same benefit if they can be used.
Disk cache used for writes is extremely helpful, because it allows write combining and elevator sorting to improve random write workloads, making them closer to sequential. However, you have to be careful, because things sitting in those caches can be lost if the power fails. That can be a corruption issue on things that expect writes to really be on disk, such as databases. Putting some flash to cache those writes, with a supercapacitor to ensure all pending writes complete on shutdown, is a reasonable replacement for the classic approach: using a larger battery-backed power source to retain the cache across power loss or similar temporary failures. The risk with the old way is that the server will be off-line long enough for the battery to discharge. Hybrid drives should be able to flush to SSD just with their capacitor buffer, so you're consistent with the filesystem state, only a moment after the server powers down.
As for why read caching doesn't normally help, the operating system filesystem cache is giant compared to any size it might be. When OS memory is gigabytes and drive ones megabytes, you'll almost always be in a double-buffer situation: whatever is in the drive's cache will also still be in the OS's cache, and therefore never be requested. The only way you're likely to get any real benefit from the drive cache is if the drive does read-ahead. Then it might only return the blocks requested to the OS, while caching ones it happened to pass over anyway. If you then ask for those next, you get them at cache speeds. On Linux at least, this is also a futile effort; the OS read-ahead is also smarter than any of the drive logic, and it may very well ask for things in that order in the first place.
One relevant number for improving read speeds is command queue depth. You can get better throughput by ordering reads better, so they seek around the mechanical drive less. There's a latency issue here though--requests at the opposite edge can starve if the queue gets too big--so excessive tuning in that direction isn't useful either.
From where I'm setting Twitterrific seems like the "hello, world" of app development, but maybe this OSHA thing is even simpler; it's hard to get too excited about either. Regardless, it is a very popular app, which should have some correlation with the developers being decent. I'd like to think that "people who have won the app store competition and build something popular" are a more competent and productive group, on average, than "people who develop phone apps on government contract". And bad programmers always end up costing a lot more than good ones, even when they deliver junk that happens to meet spec.
Check out How much does it cost to develop an iPhone application? for a few numbers that are in line with what you roughed out here. There seems cause to complain about the quality of the result, but the price tag itself isn't surprising at all. $150 an hour is also cheap for a good mobile phone developer, given the rampant gold rush speculation driving up salaries in that section of the market right now.
The version with spell checking costs $300K.
Writing random garbage to disk is the one place that ROT-13 encryption is actually good enough for.
"The Door Into Summer" is a great start. One of the less popular Heinlein books is one of my favorites: the short story collection published as "The Unpleasant Profession of Jonathan Hoag". There are two stores in there, "They" and "All You Zombies...", that have inspired countless other time travel and "is this the real world or a simulated one?" tales.