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
Secret Salaries
Joel Spolsky is the CEO of Fog Creek Software. In this Inc. magazine article, “Why I Never Let Employees Negotiate a Raise”, Joel spews hearsay on the topic of salaries:
The trouble with keeping salaries a secret is that it’s usually used as a way to avoid paying people fairly. And that’s not good for employees — or the company. – Joel Spolsky
I wanted Fog Creek to have a salary scale that was as objective as possible. A manager would have absolutely no leeway when it came to setting a salary. And there would be only one salary per level. – Joel Spolsky
In this blog post, Joel lays out the details of his compensation system: “Fog Creek Professional Ladder“.
Your career level at Fog Creek is determined as a function of three things: experience (number of years), the scope of your job (what your current job entails), and your skills (your skill level, regardless of actual responsibility). – Joel Spolsky
In the post, Joel further defines what experience, scope (there are 7 levels), and skills (there are 7 levels) mean. Of course, the criteria are not 100% objective, but at least Mr. Spolsky valiantly tries to remove as much subjectivity and insert as much objective fairness as he can.
How about your org? Is its compensation system still based on the 1920’s FOSTMA, employee-in-a-box, carrot-and-stick mindset? You know, the one where your salary is totally based on how much your anointed “supervisor” likes you?
Fudge Factors
This graphic from Steve McConnell‘s “Software Estimation” shows some of the fudge factors that should be included in project cost estimates. Of course, they never are included, right?
Holy cow, what a coincidence! I happened to stumble upon this mangled version of Mr. McConnell’s graphic somewhere online. D’oh!
New Icon
The new icon‘s here! The new icon’s here! – Bulldozer00 (from the upcoming movie “The Jerk 2″)
Whoo Hoo! I’ve stumbled upon an icon that I’ll be using in future childish posts to represent female BMs, BOOGLs, BUTTs, and/or RAPPERs. It complements the venerable, male version nicely, dontcha think?
Level Of Loyalty
Checkout the sketch below. Everyone knows why too little loyalty is detrimental to purposeful organizations of people, but why is too much loyalty a problem? (And no, that’s not a swastika.)
Through The Wall
“Break on through to the other side – The Doors
Any project of appreciable size is most likely partitioned into phases where specialists (systems, software, test) that do the work in one phase “hand off” their work products to a new group of specialists in the next phase. One challenge to managing these types of multidisciplinary projects is avoiding the “over the wall” syndrome. You know, the case where the specialist group in phase N chucks their work product over the wall to a previously uninvolved specialist group in phase N+1. Surprise!
One textbook way of attempting to smooth the transitioning of work between groups is by holding an official “review” to serve as a visible waypoint in the project’s trajectory. Done well, a “review” can increase the quality of the work and inter-group relationships. However, done poorly, it is just a self-medicating waste of time where poor work is camouflaged and it serves as a stage for slick talking politicians to increase their stock.
As the figure below illustrates, an alternative to the one-shot, review-based project is the continuous review-based project. The “official” review is still held at a discrete point in time, but since collaborative inter-group communications were initiated well before the review, specialist group 2 will experience fewer “surprises” at review time.
Nevertheless, continuous review-based projects can still fail just as spectacularly as one-shot review-based projects. Can you think of how and why?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 