Axis of beauty

Whilst beaty must be holistic, it must operate across different axis. For software these might include:

• Representation
• Textual, how is the text laid out on the page?
• Graphical, do the graphical representations hold any aesthetic merit?
• Dynamics
• The way the program executes, its flow of control.
• The way the software is updated as function or added, do new pieces slide into place simply?
• Structure
• Of the syntax tree.
• Of the data structures.
• Solution
• How elegant is the solution?
• How well does it balance the competing constraints?
• Output
• How attractive is the output from the software?

Visitors versus maps of functors

I find that it doesn't often reach for the Visitor pattern. The visitor pattern uses double dispatch, essentially scaffolding to get around the fact that many languages do not have multi-dispatch. In the visitor pattern this scaffolding is an accept (SomeVisitor) method, added for each type of visitor and a visit (ConcreteType) method on the visitor, for each type of object being visited.

I avoid the Visitor pattern because:

1. I don't like the scaffolding being invasive into the domain object.
2. I don't like the fact that when it steps through code in the debugger it steps into a method and immediately is bounced out into a corresponding method on one of the arguments passed in.
3. I don't like the fact the Visitor becomes a huge list of every type in the system, all crammed into a single interface.
4. If the Visitor needs additional context then the context needs to be added to each accept () method or put in thread local storage.
5. I don't have the disconcerting debugging experience where you step into a method in a domain object, only find a call out to one of the arguments.

So, instead of double dispatch, I normally rely on a table driven approach where the code looks like this and the ShapeRendererSource maintains a mapping of types to functors:

ShapeRendererSource::renderer (shape).draw ();

The ShapeRendererSource is scaffolding and the registering of functors with the source is also scaffolding. However, the scaffolding is external and adding context is as simple as extending the functor interface.

The approach addresses 1)..5) but has worse performance, creates a set of functors to render rather than a set of methods on a visitor (though to be fair visitors normally delegate out to objects - so you've saved one layer in the table based approach), and means somewhere you have the ugly code:

ShapeRendererSource::addRenderer (Circle.class, new CircleRenderer ());

On balance though I value the lack of intrusion into the domain object strongly enough that I'd choose the table driven approach unless there were performance concerns.

Intentional comnputing

"The key components of the proprietary technology are a uniform tree-like representation for all the contributions from all the stakeholders of the software that is produced; and an intentional editor that maintains the invariances that are represented and lets the stakeholders edit the contributions in any number of notations that are projections of the intentional tree."

Isn't that a bit like LISP with better tooling?

Coal mining & software

Coal mining was a major technological industry in the industrial age. In addition to technology and innovation it relied on people spending time underground digging.

Software is a major technological industry in the IT age. In addition to technology and innovation it relies on people spending time writing code.

Eventually it became cheaper to pay someone in Poland to dig coal out of the ground than it did to dig the coal out of the ground in some UK mines.

The economic argument that drove once high-tech jobs in coal mining off-shore are now driving software development off-shore. It is an inevitable progression, the question is not whether but rather how do we innovate fast enough to stay ahead of the curve.

Cost versus efficiency

Kenwood Corp. made mini-CD players in Malaysia until last year, when Haruo Kawahara, who heads the Japanese electronics company, decided to bring the work back. Now, teams of four Japanese employees do the work that had been done by 22 Malaysians.

I wonder what the equivalent avenues of efficiency improvements are when building business apps in the UK. Maybe there are some low hanging fruit (assuming that you've already got a recruitment policy of 'full stack', 'quality people only' in place):

• Knowledge sharing.
• Harvesting collateral as it is built and improving in next development.
• Having a good sharp set of appropriate tools.
• Avoiding NIH at all costs.

Then there is some tougher stuff (assuming that we can utilise the agile stuff in the right way - i.e. short feedback cycles, short defect discovery cycles etc.):

• Having a number of foundations; for management, .NET, J2EE (etc) that define some default tools/libraries/approaches that should be used when building 'standard' business apps (as opposed to the exceptions when you *have* to do something different - as the problem demands it).
• Reducing defects.
• Raising the level of abstraction we use to build certain type of systems. This is the tough one, since it needs an organisation to be building enough of a certain type of app that the abstraction level can be raised.
• Canned architectures.
• Engaging clients at the problem formulation stage so that the requirements can be distilled down to the smallest set needed for the required business value.
• Improving requirement analysis skills (including understanding of language and intepretation) and low cost prototyping so that requirement misunderstandings are less frequent.
• Getting the required amount of business engagement, when needed, with the right degree of analysis.
• Make 'play' cheap.

Of course, the big problem with this is that in manufacturing (presumably) costs are saved through reducing the cost or time it takes to instantiate a design where costs are saved across many multiple instantiations. In software, it's primarily about reducing the time needed to think hard rather than the instantiation time - since software is normally only instantiated a very small number of times.

However, instead of focusing on the flaws in the parallel consider that what is really going on is a battle of cost versus efficiency and it is about time we joined that battle. In the long run this battle will even out as any efficiency gain made in one area will eventually be equalised or bettered in another geographical area. However, in the short to medium term it may help.

Object Thinking

This book by Dave West seems pretty interesting. He did a great talk on magic and software at OOPSLA '03 Onward! track. Proceedings here. A book that actually talks about OO rather than C#, Java, C++, Ruby etc. There are very few of those.

Maybe worth a read.

Probably not a good read if you didn't listen to the monk until you found there was no light to read by ;-)

It became self aware on August 29 1997, 2:14 am Eastern Time

Mr Parkinson must have been watching the T franchise while he wrote this.
Alarmist but interesting points. Particularly the piece about building in 'circuit breakers' - I think it's interesting in the context of STP systems as well as 'society infrastructure' software