Wil Shipley has explored this approach: http://blog.wilshipley.com/2009/08/pimp-my-code-part-16-heuristics-and.html
I also swear I remember reading another example of this on his blog, but I'm unable to find it, so I'll paraphrase from memory (which is somewhat murky, so caveat lector):
One of the features of Delicious Library is that you can use your computer's built-in webcam to scan barcodes as a way of adding items to your library.
The traditional, mathematically-inspired computer science approach to implement this is to frame the problem as: "Given an image with a barcode somewhere in it, find the barcode, and then read it." The problem is that a general algorithm that accepts entire set of images with barcodes in them is prohibitively slow, because you have to deal with skew, perspective, lighting, focus, etc.
The approach they ended up using was inspired by biology: it's OK to fail some of the time as long as there's feedback. They went with a much simpler algorithm that takes a fraction of a second to succeed or fail. They run it continuously against new frames, and indicate to the user whether it has succeeded. Since the user is standing there with the barcode in front of the camera, they'll reposition, try different angles, etc, until there's success.
You are misrepresenting his argument about frameworks. Re-read the first paragraph of his post:
"Apple's shared frameworks are very useful for sharing executable code and its associated resources among multiple applications, but were historically not designed to be created by authors of consumer applications. I discourage developers from creating frameworks as a method of sharing code, because they encourage code bloat, increase launch times, complicate the developer's fix/compile/link/debug cycle, and require extra effort in setting up correct and useful developer and deployment builds."
and the last one:
"Creating shared frameworks is a lot of hassle for third-party developers of consumer software, introduces instability into the development process, and encourages slower and larger applications. Code sharing is better accomplished through creating new directories for shared code in subversion and judiciously including only the files and resources needed by any application in its Xcode project."
http://blog.wilshipley.com/2005/11/frameworks-are-teh-suck-err.html
(Note: framework here refers to a specific way of organizing compiled code in OS X for sharing: .framework bundles)
My "crap app" got rejected for being of "minimal functionality" even though it duplicates the functionality of a physical device found in many restrooms in Japan, so it seems Apple is indiscriminately applying their policies regardless of application quality, leading to some making it through and others not. Case in point:
http://createdigitalmusic.com/2009/03/16/apple-rejects-free-iphone-tool-for-artists-because-of-minimal-user-functionality/
I would hardly call this as having "minimal functionality". Yet Apple thinks so. But neither I nor Apple should have that call beyond apps that are illegal, overly resource intensive or malicious. The market should be able to decide. This behavior hinders development across the board, especially when you have no insight into why an app is rejected or what it will take to get it approved. Will Shipley has a great post on his blog about this very issue:
http://wilshipley.com/blog/2008/09/iphone-app-store-let-market-decide.html
This is my question, too! I want one...
Wil Shipley blogged a couple years ago here:
http://wilshipley.com/blog/2008/01/macbook-air-haters-suck-my-dick.html
about developing his Delicious Library app on his Air. The post itself is a bit much, but there's an addendum at the bottom with some compile stats. Namely, the Air (because he got an SSD) compiled Delicious Library faster than his Macbook Pro.
But I would love to hear others' experience developing on an Air, since that's what I'm considering now, too. This Stack Overflow post:
http://stackoverflow.com/questions/549008/macbook-air-for-iphone-development
mentions that Xcode can't autocomplete well on an old air, but I think it might be because it has a balls-slow 4200 rpm hard drive.
The only thing that concerns me is the processor. What things tax the CPU?
Wil Shipley on unit tests:
http://wilshipley.com/blog/2005/09/unit-testing-is-teh-suck-urr.html
I think what he's saying is unit tests don't add much if you are doing UI type development. It is hard to write unit tests for UIs (web or GUI), so if most of your code is UI code, don't bother.
However, if you are writing a library that will be used by a lot of coders, unit tests are probably indispensable. Otherwise, you would never be able to make even simple architecture or design changes (refactoring).
My guess is that he's talking about this problem: http://blog.wilshipley.com/2011/04/success-and-farming-vs-mining.html
"Founders and angel investors usually don’t particularly care if the companies they created live or die after they sell out, because they’ve gotten their money and moved on. There’s no stigma to having a company you founded fail after you leave it. In fact, again, it's a badge of honor: “Bob Smith founded Flopper.com, sold it for $46MM, then got out before it tanked! Genius!”"