Archive
Synthanalysis
According to Russell Ackoff, there are two thinking tools for developing an understanding of how existing socio-technical systems work: analysis (reductionism) and synthesis (constructionism). Since analysis is taught in school (and synthesis is not – except in the arts), analysis is a well known tool to problem solvers. Synthesis is not taught in schools because it’s hard to teach – it’s a less methodical and more metaphysical technique than analysis.
The UML state machine diagram below models the behavior of two different problem solvers – one that exclusively uses analysis and one that bounces non-deterministically between analysis and synthesis. Note that the purpose of entering and dwelling in the synthesis state is to learn the holistic “why” of a system – which always lies outside of the system.
The figure below shows a typical example trace of a synthanalyst problem solver’s behavior over time. Over each iteration toward a viable solution to the problem at hand, a synthanalyst dwells less and less in the synthesis state and more and more in the analysis state. The behavior trace for a one dimensional analyzer is not shown because it’s trivial. It’s a boring and unadventurous flat line – one that self-smug managers trace out every day at work.
My Erlang Learning Status – III
Since my last status report, I haven’t done much studying or code-writing with Erlang. It’s not because I don’t want to, it’s just that learning a new programming language well enough to write idiomatic code in it is a huge time sink (for me) and there’s just not enough time to “allocate” to the things I want to pursue.
However, that may change now that I have e-access (through my safaribooksonline.com subscription) to a second, terrific, Erlang book: “Erlang And OTP In Action“. Together with the equi-terrific book, “Erlang Programming“, the two different teaching approaches are just what may motivate me to pick up the pace.
When learning a new topic, I like to use multiple sources of authority so that I can learn the subject matter from different points of view. It’s interesting to compare the table of contents for the two books:
Currently, I’m in chapter 2 of the Erlang/OTP book (left TOC above) and chapter 6 in the Erlang book. As I lurch forward, the going gets slooower because the concepts and language features are getting more advanced. I hate when that happens. 🙂
Note: If you’re interested in reading my first Erlang learning status report, click here. My second one is here.
SysML, UML, MML
I really like the SysML and UML for modeling and reasoning about complex, multi-technology and software-centric systems respectively, but I think they have one glaring shortcoming. They aren’t very good at modeling distributed, multi-process, multi-threaded systems. Why? Because every major element (except for a use case?) is represented as a rectangle. As far as I know, a process can be modeled as either a parallelogram or a stereotyped rectangular UML class (SysML block ):
To better communicate an understanding of multi-threaded, multi-process systems, I’ve created my own graphical “proprietary” (a.k.a. homegrown) symbology. I call it the MML (UML profile). Here is the MML symbol set.
An example MML diagram of a design that I’m working on is shown below. The app-specific modeling element names have been given un-descriptive names like ATx, APx, DBx, Mx for obvious reasons.
Compare this model with the equivalent rectangular UML diagram below. I purposely didn’t use color and made sure it was bland so that you’d answer the following question the way I want you to. Which do you think is more expressive and makes for a better communication and reasoning tool?
If you said “the UML diagram is better“, that’s OK. 🙂
Snap Judgments And Ineffective Decisions
In the software industry, virtually all people agree that Winston Royce‘s classic paper titled “Managing The Development Of Large Software Systems” was the first widely publicized work to describe the linear, sequential, “waterfall” method of building big systems. He didn’t coin the term “waterfall“, he called it a “grandiose process“.
Here’s one of the pics from Mr. Royce’s paper (note that he shows stage N to stage N-1 feedback loops in the diagram and note the “hopefully” word in the figure’s title):
What seems strange to me is that most professional’s that I’ve conversed with think that Mr. Royce was an advocate of this “grandiose process“. However, if you read his 11 page paper, he wasn’t:
The problem is…. The testing phase which occurs at the end of the (waterfall) development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. They are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. – W. W. Royce
This lack of due diligence to dig deeper into Mr. Royce’s stance reminds me of bad managers who make snap judgments and ineffective decisions. They do this because, in hierarchical command & control CLORG cultures, they’re “supposed to look like” they know and understand what’s going on at all times. After all, the unquestioned assumption in hierarchies is that the best and brightest bubble up to the top. But, as Rudy sez…..
“You have to know a lot to be of help. It’s slow and tedious. You don’t have to know much to cause harm. It’s fast and instinctive.” – Rudolph Starkermann
Of course, all human beings suffer from the same “snap judgments and ineffective decisions” malady to some extent, but the guild of management-by-hierarchy, fueled by its ADHD obsession to jam fit as much attention/planning/work into as little time as possible, seems to have taken it to an extreme.
Tell Me About The Failures
As the world’s rising population becomes more and more dependent on software to preserve and enhance quality of life, efficiently solving software development problems has become big business. Thus, from the myriad of “agile” flavors to PSP/TSP, there are all kinds of light and heavyweight techniques, methods, and processes available to choose from.
Of course, the people who acquire fame and fortune selling these development process “solutions” seem to only publicize success stories. In each book, case study, lecture, or general article they create to promote their solution, they always cite one or two concrete examples of wild success that “validate” their assertions.
Besides the success stories, I, as a potential consumer of their product, want to hear about the failures. No large scale software development system is perfect and there are always failures, no? But why don’t the promoters expose the failures and the improvements made as a result of the lessons learned from those failures? Humbly providing this information could serve as a competitive differentiator, couldn’t it?
The difference between a methodologist and a terrorist is that you can negotiate with a terrorist – Martin Fowler
What Really Happens…..
A Role Model For Change
In the comments section of the Horse And Buggy post, Steve Vinoski was gracious enough to provide links to four IEEE Computer Society columns that he wrote a few years ago on the topic of distributed software systems. For your viewing pleasure, I’ve re-listed them here:
http://steve.vinoski.net/pdf/IEEE-Serendipitous Reuse.pdf
http://steve.vinoski.net/pdf/IEEE-Demystifying_RESTful_Data_Coupling.pdf
http://steve.vinoski.net/pdf/IEEE-Convenience_Over_Correctness.pdf
http://steve.vinoski.net/pdf/IEEE-RPC_and_REST_Dilemma_Disruption_and_Displacement.pdf
Of course, being a Vinoski fan, I read them all. If you choose to read them, and you’re not an RPC (Remote Procedure Call) zealot, I think you’ll enjoy them as much as I did. To view and learn more about distributed software system design from a bunch of Steve Vinoski video interviews, check out the collection of them at InfoQ.com.
I really admire Steve because he made a major leap out of his comfort zone into a brave new world. He transitioned from being a top notch CORBA and C++ proponent to being a REST and Erlang advocate. I think what he did is admirable because it’s tough, especially as one gets older, to radically switch mindsets after investing a lot of time acquiring deep expertise in any technical arena (the tendency is to dig one’s heels in). Add to that the fact that he worked for big gun CORBA vendor Iona Technologies (which no longer exists as an independent company) during the time of his epiphany, and you’ve got a bona fide role model for change, no?
Obsolete, Or Timeless?
Waaay back in 1992, before “agile” and before all the glorious CMM incarnations and before the highly esteemed “PSP/TSP”, NASA’s Software Engineering Laboratory issued revision #3 of their “Recommended Approach To Software Development“. As you can see below, the table of contents clearly implies a “waterfall” stank to their analysis.
But wait! In section 10 of this well organized and well written “artifact“, the members of the writing team summarize what they think were the keys to successful on time and on budget software project success:
What do you think about this summary? Is the advice outdated and obsolete and applicable only to “waterfall” framed projects? Is the advice timeless wisdom? Are some recommendations obsolete and others timeless nuggets wisdom?
SOI Sauce
Assume that you’re given a bounded “System Of Interest” (SOI) you desperately want to understand. Cuz it’s a ‘nuther whole can of worms, please suspend “reality” for a moment and fuggedaboud who defined the SOI boundaries and plopped it onto your lap to study.
So, where and how do you start attacking the task at hand? Being a member of a western, logical, science-revering culture, you’ll most likely take the analysis path as depicted in the left side of the figure below. You’d try to discern what the SOI’s elemental parts are (forming your own arbitrary part-boundaries, of course) and how each of the parts behaves independently of the others. After performing due diligence at the parts level, you’d aggregate the fragmented part-behaviors together into one grand theory of operation and voila….. you’re done! Because the reductionist approach doesn’t explore the why of the SOI, you’d most likely be wrong. If one or more of the system “parts” is self-purposeful, uh, like people, you’d most likely be 100% wrong.
A complementary approach to understanding a SOI concerns formulating the why of the system – first. As the right-side path in the above figure conveys, the synthesis approach to understanding starts with the exploration of the super-system that contains the SOI. Upon gaining an understanding of the operational context of the SOI within its parent system (the why), the what and the how of the SOI’s parts can be determined with greater accuracy and insight.
The figure below illustrates side-by-side state machine models of the two approaches toward system understanding. Which one best represents the way you operate?
Focus And Curiosity
I like using tweets as a source of blog posts. This one by Tom Peters captured my imagination:
Too much vertical focus and there’s no growth or development. Too much horizontal curiosity and there’s no accomplishment. However, the right mix of focus and curiosity provides for both personal growth and accomplishment. As the state transition diagram below illustrates, I always start a new software project in the curious state of “not knowing“. I then transition into the focused state and cycle between the two states until I’m “done“. Don’t ask me how I decide when to transition from one state to the other because I don’t have a good answer. It’s a metaphysical type of thingy.
I start off in the curious state to gain an understanding of the context, scope, and boundaries of my responsibilities and what needs to be done before diving into the focused state. I’ve learned that when I dive right into the focused state without passing through the curious state first, I make a ton of mistakes that always come back to haunt me in the form of unnecessary rework. I make fewer and less serious mistakes when I enter the curious state at “bootup“. How about you?
Since bozo managers in CCH CLORGS are paid to get projects done through others, they implicitly or explicitly assume that there is no need for a curious state and they exert pressure on their people to start right right out in the focused state – and never leave it.
Good managers, of course, don’t do this because they understand the need for the curious state and that dwelling in it from time to time reduces schedule and increases end product quality. Great managers not only are clued into the fact that the curious state is needed at startup and from time to time post-startup, they actually roll up their sleeves and directly help to establish the context, scope, and boundaries of what needs to be done for each and every person on the project. How many of these good and great managers do you know?
“If I had an hour to save the world, I would spend 59 minutes defining the problem and one minute finding solutions” – Albert Einstein
Don’t you think Mr. Einstein spent a lot of time in the curious state?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 