Lambda the Ultimate

i need to get up earlier and read more. i have been getting into ToC via Lean and Critical Chain over the last few years. (i read and learn at a snail's pace.) i was also reading the Rugby model you mentioned elsewhere.

In my humble opinion, Rugby model is a throwback to analysis stage in the Software Development Life Cycle (SDLC). Back in the old days of usenet://comp.object/ there would be glorious debates about structured analysis versus object-oriented analysis and whether data coupling or functional coupling or temporal coupling was a more severe software maintenance problem, as that would determine how you might approach physical design in 3GL code. Nowadays with remote procedure calls, people just call services and glue things together so they rarely appear to care about good design; when they want performance they throw things in giant hash trees (bigtable) or distributed mainframes (map/reduce). usenet://comp.object/ used to have LtU users like Patrick Logan debate this stuff, oh, 20 years ago. Anyway, Rugby model partitions coupling analysis into four dimensions, which sort of fits David Barbour's guess that the traditional TRIZ model does not fit software well.

Commentary on good design is pretty rare. The one person who I've learned the most from, retaining as much as possible like a clay lake basin, is H.S. Lahman. I joked with him once that they should just rename usenet://comp.object/ to usenet://ask.h.s.lahman/, because he almost always gives a comprehensive answer to a question posed about problem domain modeling. He and Greg Eakman are working on model-driven architecture book series that I am hoping will be very good.

I've pretty much ignored Lean and Critical Chain, and even Six Sigma, as well as Hammer's business process re-engineering. All of these ideas are re-hashing statistical process control theory pioneered by Dr. W. Edwards Deming. Hammer's faux pas seminal book, Re-engineering the Corporation, in particular is hilarious; whereas Deming condemns the American post-World War II corporate model and gives concrete reasons for why the "too big to fail" corporations of the '80s is nonsense, Hammer is totally apologetic and forgiving to self-cannibalistic corporations like ITT (led by Harold Geenan), stating that it was a sequential progression.

What is the lesson I've learned from reading lots and lots of general systems theory and business books? 1) Know your math, and be a multi-disciplinary mathematician; as a programmer, also know your language theory; 2) If an idea is not selling well (the Deming Method), repackage it with weaker ideas and a different story line that revises history, but is essentially the same thing (business process re-engineering)

In the '60s, there were quite a few math books about general systems theory, such as Wymore's 1967 book Mathematical Theory of Systems Engineering: The Elements, Lotfi Zadeh's 1963 Linear System Theory: A State-Space Approach (Zadeh is most known for founding the field of fuzzy logic), Mihajlo Mesarovic's 1975 General Systems Theory: Mathematical Foundations, and Michael A. Arbib and Louis Padulo's System Theory: A Unified State-Space Approach to Continuous and Discrete Time Systems. In the '80s, the biggest idea came from melding object-oriented simulation with AI knowledge-based systems: (1) Bernie Zeigler's endomorphic systems, where intelligent agents build internal models of their environment through interactions with it, was a good idea but did not solve "the library problem" of finding model concepts easily (2) Arbib's analogies between theory of mind and system theory

I wouldn't recommend reading these old, musty books.

Applying systems theory to software systems is very hard, especially when you merge analysis and design, rather than separate the two through inserting a translation phase. Diomedis Spinellis tried following up his Code Reading book (applauded by the agile community) with Code Quality, but the book ultimately lacked legs and was filled with fluff.

For a real mind-bending discussion about distributed systems design, I recommend Sumit Ghosh's Algorithm Design for Networked Information Technology Systems, which unfortunately requires the ability to read electrical engineering / hardware diagrams to fully appreciate. Ghosh is like a modern Dijkstra; he lays it all out with regards to his feelings about distributed systems design and why systems are not scale-free.

only for pessimism? :-)

I think I am firmly rooted in having the right historical perspective on things. If you start from the wrong narrative, then you are bound to have faulty storylines.

It is important to learn how to communicate and sell ideas effectively. It is a mistake to assume the best ideas are the ones accompanied with the best salesmanship - that is rarely the case.

Being able to trace history is important.

If I sound bitter, it is mainly because I have had to learn history by searching Google, and this time could be more productively spent at the beach impressing girls with my volleyball digs and slams. On the other hand, optimistically, Google has proven a wonderful tool to dig up history - in large part thanks to their archiving of Usenet.

Edit: By the way, apparently a couple people found the above post about systems theory and software engineering interesting, as I recevied three e-mails about it. Funny; I expected most people to despise such things as being off-topic and almost didn't post it.