This is going to be a little bit of a stream of consciousness, but I will probably build on it later.

First, two preconditions

1. understand the business needs. kinda obvious, but you need to plan for it to be iterative, especially if the business needs are not fully known yet. (even if you think they are they probably aren't)
   
   
2. understand the mindset and capability of your developers—what are their strengths/weaknesses, what conceptual models do they click with or struggle with

The interesting thing I realise about these points is that they define your two main points of interest, which are also your two "clients": the business; and the developers. Even if you are in exactly the same team as the developers who will be using your frameworks they are really your clients in the sense that your job is to enable them to be productive.

Goals when designing & implementing a code framework

1. end result should allow the natural expression of the real world model such that it's easier to accidentally do the right thing than to make a mistake. this goal is symbiotic with the general goal of hiding complexity where possible.
   
   
2. build in enough flexibility for accidental reuse without increasing the complexity of the mental model required to put the objects to use. (more on accidental reuse to come in a later blog entry).
   
   
3. design for free improvement of end functionality via upgrades to the framework.
   
   
4. extend goal (A) such that simply using the framework should result in expressive self documenting code. an aid to achieving this is to think of objects/methods in terms of their use rather than their implementation.
   
   
5. internally design the classes/methods to allow for a change in the implementation of their own properties. eg. an identifier changing from an integer to an alphanum or a property being replaced by a method. these changes should be possible without resorting to an automated refactoring tool (although sed, awk and perl are perfectly respectable refactoring tools ;)

Observation: (D) & (E) are much easier to achieve with an OO agile language such as Ruby or even OO Perl than with traditional compiled languages. Objective-C and the core NS/Cocoa classes do a good job at bridging this gap.

Update: There's a useful article on API design just been posted on perlmonks On Interfaces and APIs. While not as concise as it could be, the referenced material is very good. Two that I would heartily recommend you read are:

• Edward Tufte - The Visual Display of Quantitative Information
• Donald A. Norman - The Design of Everyday Things

Banks feel like cathedrals, I guess casinos took their place

PS: Also noticed that there is no affiliates program for iTunes in Australia wheras there is for the US and UK - what's with that? I can link to iTunes for free, or I can give you a commission paying Amazon link to the Album...

I don't normally do a link roundup (that's what my del.icio.us feed is for), but there are a few links I've been storing up to discuss that deserve a few words.

The Cool

1. IBM z9 mid-size mainframe (links: IBM, El Reg)
   Some people are desperate for cost effective scaling + reliability, but getting all three of these with some (small a) applications is actually an incredibly difficult problem. Exhibit A is the brain power that it takes to make a serious search engine scale. The rule of thumb is that you can pick any two. If you're less cost sensitive than the average bear and you have very serious scale and reliability requirements then you could do much worse than look at mainframe hardware. Especially now that virtualised linux environments on mainframes are so de riguer. For people used to the constraints of Intel hardware, the difference is really outstanding - imagine being able to suffer a cpu failure then physically install a new one - all while your servers keep running. I wasn't aware that IBM offered a co-processing module targetted specifically at J2EE - that's pretty cool.
2. Reverse-capable C/C++ debugger for Linux (Links: Undo Software, LinuxPR)
   Speaks for itself. What's really great is that they chose to use gdb as the front end. Not only does that reduce the barrier to learning how to use it, all the traditional front ends will likely work with little change. Now on Intel, it should also take very little effort for Undo Software to make a MacOS X version that would work seamlessly with XCode (which uses gdb already)
3. Google Maps Geography Quiz
   Test your knowledge of the globe with this trés cool mashup
4. Tofu : Multi-column web browser for MacOS X
   Newspapers use multiple narrow columns for a reason. Now you can enjoy your electronic reading experience in the same form-factor with this free (alpha) viewer. I've tested it on PDF and html files, I assume it just subclasses an NS class of some sort.

And now for something completely different

1. Microsoft Bob
   This links to a separate article about Bob including screenshots and discussion of the performance on modern hardware! I think Microsoft had stolen too much of the Sculley Kool Aid!!
2. Apple Bandai Pippin
   I saw a mad demo of some prototype set top box software from Apple which seemed like a good idea that went nowhere. The Pippin on the other hand - that never seemed like a good idea to me!