There is an aspect of the story, which deserves a special mention. concrete problem. We got stuck with the concrete problem, overwhelmed
by the details and the variables, and any solution we could think of seemed arbitrary. In order to reflect and simplify, we decided to phrase our question categorically. This lead to a diagram of sources and sinks, so we just used pushouts and pullbacks to glue things together. ...
This seems to be a typical story of software design. Category theory provides a toolbox of design patterns, which can be useful before and irrespectively to an actual formalization. Tom Maibaum and I even wrote a paper trying to stress this aspect of CT: Category Theory and Model-Driven Engineering: From Formal Semantics to Design Patterns and Beyond http://rvg.web.cse.unsw.edu.au/eptcs/paper.cgi?ACCAT2012.1 Intuition of a healthy structure provided by CT is based on formal foundations, but its value goes beyond formal semantics. Cheers, Zinovy [For admin and other information see: http://www.mta.ca/~cat-dist/ ]