Joel Spolksy argues that the Iceberg secret is not that 80% of a project is core, difficult code, and 20% is lipstick, but that it is the fact that end users don't know this. Corolary 2 to this principle is that if you show someone a user interface that is 90% done, they will think the project is 90% done.

People who aren't programmers are just looking at the screen and seeing some pixels. And if the pixels look like they make up a program which does something, they think "oh, gosh, how much harder could it be to make it actually work?"

I've worked on prototypes of software for various projects, one was even demo-ed in front of some folks at the white house. I've always striven to make the interface look like what it might look like in the finished software. The problem is, the Iceberg Rule kicks in and your audience starts to assume that you don't have that much farther to go in terms of creating a finished product.

You could create a beautiful, ajax interface to a database of turnip varieties. Client assumes you're basically done, right? But what happens when it turns out there are thousands of turnip varieties (I'm making this up, I don't actually know) and that the research to create the aforementioned database would cost millions of dollars?

There is a dissonance between what the prototype promises, and what you actually might be able to deliver on.

So I guess, in some respects, this argues for crappy looking prototypes. I accept that there is a value to building prototypes and working through user interface issues with clients. I accept that a clickable prototype represents a better artifact to build from than a 400 page specification. (You probably want both though.)

If you think about it, you can make an argument that, while it only takes a day to come up with some snazzy css for your prototype to make it look all that much better, it is not worth the dissonance between where you actually are in development and where the client (or your boss) thinks you are. ** With the caveat that sometimes if your boss wants you to just fake it, you might want to find a better job.

One tool that I really like for working in this vein is Balsamiq. This tool creates wireframe style mockups, using terrible comic sans style fonts and sketchy lines. There is no danger that it is going to be misinterpreted for a finished product.

Todd Zaki Warfel wrote a really good book on prototyping, but he kind of danced around this issue. He argues that you might be able to take resources from a prototype and use them in a production product (and you might not.) To do this though, it implies that you are creating something that is useable in a product, both from the core, quality, integrity standpoint, and from the look and feel standpoint.

Maybe a productive way to think about this is too recursively apply the Iceberg Principle to the mock up. Spend your time building the 80% back end to the interface, the jQuery, the MVC, the interactions and handlers and code. However, consciously avoid taking it the extra 20% and making it look slick. This is sort of counter intuitive, but what you end up if you do that is real UI work that you can poke and prod as part of the development process, but your boss won't confuse with a finished product.

Build the mockup with an eye towards style-ability, IE coherent css classes and design, but just sort of go through and dog it up a little bit when it comes time to present it to the client.

Of course the catch-22 is that your client may not ever accept your prototypes if they don't look finished. So you are basically screwed either way... A potential approach to this problem is to create the prototypes and put them in front of users (IE through a service like usertesting.com) and produce some research from that testing. It's a good process in and of itself, and it is also ammo you can bring to a client meeting to help move them and the project in the right direction.

I think prototyping is a valuable tool, but I've been burned one too many times by the Iceberg Principle. Clients just think the end product is done when they see a coherent user interface. Maybe we can apply a little bit of strategy and get a lot of the benefit from the prototyping process without the dissonance between expectations and appearance.

I was writing a homework assignment for a Discrete Math class, and writing some code to generate my answers. I realized something about my thought process, which I thought I'd share.

The problem was 4 different simple sums, and I wrote them 1 after the other, first: and then and so on... What I realized, was that I kept making mistakes in the counting. So the sum would be from 1 to 4, but I would accdentally count from 0 to 3 or something. I also realized that I was repeating myself a lot in writing the answer = 0; answer += .... etc bit.

So this is simple, but its a nice revision, to go to the following code: I'm writing this blog article, not because that's all that earth shattering, but because it illustrates a point about good code versus bad code. If you had a bunch of sums in the format I used initially, it would look like someone barfed a bunch of bad code on the page. On the other hand, using the general function and callbacks, you get a nice clean implementation.

Often the difference between a good coder and a bad coder is not the ability to write a lot of code, but to write a lot less code to get the same problem done.

This NY Times Article, "How U.S. Lost Out on iPhone Work" By CHARLES DUHIGG and KEITH BRADSHER contends that America isn't producing the type of workers that companies like Apple require to do their manufacturing.

I'm not sure I buy it.

The This American Life piece I posted last week, about manufacturing conditions in Asia, paints a different picture. Workers are working hugely long shifts. They are doing incredibly repetitive jobs to the extent that they get a level of repetitive stress injury that almost makes it a different syndrome then what American typists experience. In one case they were subjected to a potent neurotoxic cleaner because it evaporated faster than alcohol. They are starting working at age 13.

So yeah, America isn't producing the type of labor force required to produce iPhones, but it's not because they aren't studying math and physics. I think the Times article really misses the point. It's not that Americans are dumb, its that we have laws that protect workers and the environment from manufacturing. It's that we have standards here that workers in Shenzen aren't protected by.

It's because the cheap, unregulated labor force exists in China that other aspects of the supply chain are also relocating there. As the Corning exec said, they could manufacture Guerrilla glass in the US, and then ship it by boat (slow) or air (expensive) to where it is being assembled. Or they could just do everything in Asia.

It's the cheap unregulated labor that's driving this relocation.

• This opinion piece in the New York Times, entitled "The Rise of the New Groupthink" by Susan Cain.
• And a new video from Fog Creek Software (Joel Spolksy) on software teams. You can watch the trailer for the whole series here or rent the segment on the environment here.

This is a greasemonkey script. I'd say that if you are relatively technically savvy, you shouldn't have any trouble wrangling the plugin. The idea behind greasemonkey is that you can run your own custom JavaScript once a page loads. The script is fairly brain dead -- it just hides a couple of divs on the main page.

The basic installation instructions are to install the plugin, save this code as mint.user, and add it to the browser. (I think drag and drop works, but you can also click on the little monkey icon in your browsers toolbar.)

Here's a quick sketch of another pretty old Sam Halperin idea: It's pretty common to see multi-track recording software on a mac. You have garage band, logic, pro-tools...etc. These are all huge and robust professional recording programs. I am envisioning a simple tool though, one that would allow musicians to improve their improvisation skills, as well as a medium through which musicians from disparate backgrounds and geographies could work together.

The basic idea is that you start the program recording, and start playing your instrument. After a preset amount of time, the software loops, and you start hearing the first segment of what you played in the headphones. The software adds layer upon layer of sound, but fades out the original recording after a set number of loops.

It's a pretty simple idea. So you can start with a theme, and then sort of jam over that theme and see how it evolves as your old layers are faded out, and as you add new ones.

The other component of this, the social component, is the idea that you don't have to start with your own theme. So I could jam over a U2 track, but once the track ended, only my own playing would repeat.

You could imagine (though it is not required for this to be an interesting project) a sort of social network of people exchanging themes, upon which other musicians could evolve their own ideas.

I think it would be a fun little project, and would get into mac audio programming, something that I have no experience in. A first iteration could be devoid of any graphical interface. I imagine that the output of the program, once you are done recording a session, is a two track audio stream, where one track is the solo at any given point, and the other track is the playback.

Please see the following document: proposal.pdf.

I am currently trying to figure out how to work development of this project into my professional and personal situation. I will be occupied with 2 graduate classes until September, but I hope to eventually have some time to begin prototyping the various components.

https://github.com/shalperin/Algorithmic-Art

Look for a README in each directory, describing the projects, as well as at least one script (.pl, .py, .java) and at least one rendering (jpg, png, tiff, etc)