On Infrastructure

The following quote is from a long article on Toyota in the New York Times:

Improving efficiency in the factory, though, doesn’t necessarily lead to greater profits. Savings on the assembly line can mean a nicer dashboard without making the customer pay more for it. “If you’re efficient in the things the customer doesn’t see, then you can put it into the things the customer does see,” Ron Harbour, a consultant whose company rates the efficiency of auto plants, told me. A result is a car more popular with customers. Success on the assembly line, in this way, begets success in the showroom.

For me, this best describes the business case for choosing Cocoa as your application framework for Mac applications. This is not to say that you can't write terrible Cocoa applications. You can, to be sure, but in general the APIs, the design patterns, even the style of the code subtly try to keep you from rebuilding things that have already been built. Many of the programming idioms try to get out of your way and "do the boring stuff" so that you can spend time adding value that the customer actually sees.

If you are always spending time working on the guts of your application, especially the parts that the user doesn't directly interact with, there's often little perceived value in the work you are doing. If you are all of the time "platform building", it's easy to loose sight for what the platform is being built to support. Don't get me wrong, I'm a big fan of infrastructure work, I've spent most of my professional career doing it. However, it's absolutely critical to see the connection from the work you do to the customer value. This is why a good user interface is so important. This is why a good application programming interface is so important.

On the other hand, if you are working with people that watch out for the schedule and bottom line and you propose an infrastructure improvement, immediately you will, or should be, accosted with pointed questions about cost, time and customer value. All of these are very good things to discuss, but when you do discuss them, you must not forget the long term impact of the work you do. If you're only going to be there for one version of the software, then maybe the near term results are all you care about. There are as many shortsighted programmers as clueless business men, but I think the real answer is that working on improving the guts, the engine, the non-visible, un-photoshopable parts of your application are the long term the "critical path features" that will allow for money and time to be spent on the high customer impact features of version n+1.

Toyota’s executives recognized early on that improving the process by which cars are designed and built is just as important as improving the vehicles themselves.

You've got to have both, but if you only ever focus on what the user sees (and this is easy to do!) eventually, your application will collapse under its own weight. What I'm trying to discribe might be the best business case for the model-view-controller design pattern. How does this apply to Cocoa? Sure, you can build an app using the model-view-controller design pattern without Cocoa, it's just that with Cocoa, you just fall into doing the right thing long term, even if you don't quite know why.