Archive
90 Degree Rotation
The figure below shows a 3 group system that efficiently transforms a stream of raw inputs into a stream of valued outputs (they’re valued because customers want to pay for them) via the application of talent, knowledge, and skill. In this system, since all groups are on the same horizontal plane of importance, negative feedback channels are embraced, and hence, the information that flows within them blunts the rate of increase in entropy while providing a source of reflective learning.
Now, let’s introduce vertical levels of “perceived importance” by rotating the system in the clockwise direction by 90 degrees:
So, you ask “why were those red verboten x’s introduced during the rotation? “. I put them there because once people start perceiving that the levels above are more important than them, they stop giving negative feedback – even when the inputs they’re given to work with turn into POPs over time. After all, if someone/group is perceived as more important than someone else, the “someone else” is likely to think that whatever they’re given as an input to work with must be good – regardless of its real quality.
Now, let’s introduce a culture of fear (which usually goes hand-in-hand with hierarchical levels of importance) into the system:
So, you ask “why were those feedback loops to “self” crossed out? “. You see, when a sub-group is an integral part in a fearful hierarchy of importance, it doesn’t critically evaluate its own work and it covers up mistakes – lest it be perceived as unworthy for promotion to the next higher level of importance by those in said level.
As startups grow, unless their founders exert Herculean force to prevent it, they start rotating to the right. The rate of rotation is often so sloooow that no one notices it until it’s too late . The feedback loops are broken, product/service quality erodes, and the fit hits the shan. D’oh! I hate when that happens. Don’t you?
No, I’m Argyle
When something is so over-hyped like, say, “agile“, if you try it out and don’t find it to be effective, the high priests will tell you that you’re doing it wrong. If you don’t try it out because your common sense and experience tell you it won’t work effectively in the context you’re in, then the high priests will call you a Luddite. The high priests of anything over-hyped always have their bases covered, no?
A Rough Cut
I think I’ve stated it before, but in case I haven’t, I’m a subscriber of safaribooksonline.com. One of the membership benefits is called “Rough Cuts“. You’re given access to book manuscripts as they are developed, before they are published. One of the rough cuts that caught my eye is titled:
Here is the the table of contents :
Uh, say what? There’s no Part I or Part IV titled “Technical Skills” in a book with “Software Architects” in the title? Gimme a break.
Granted, the book’s overview states:
“These are the skills that are typically the most challenging for people with technology backgrounds. The book assumes that the reader already has the requisite technical skills to become an architect and as such does not focus on these types of skills.”
I’m not so naive to think that “relationship, internal, and business” skills aren’t critical for success, but if you’re gonna put “Software Architects” in the title, the highly esteemed and influential BD00 demands some sort of technical skills advice in the book. You know, like heuristics and guidance for allocating requirements to functions/patterns/packages/components/class-clusters, layering for loose coupling, leveling for balanced consistency, blueprint creation through modeling, wrestling the”ilities” into submission, yada, yada, yada. But cheeze… remove the words “Software Architects” from the title.
As you might have surmised, I didn’t read the book from cover to cover – I’m simply not that into the subjects covered in it . However, I did invest an hour skimming through the chapters. If I didn’t know what the title was, I would’ve guessed that it was something like “how to be a great executive“, “X steps to managerial success“, “moving on up in the organization“, “yada, yada, yada“. There are already a bazillion books out there that offer similar content.
One saving grace is that the book uses lots of dorky, BD00-like graphics, and it has a boatload of great quotes in it. By far, my fave is this one:
Another saving grace is that the chapter in which the quote prefaces, “Passion“, is terrific. Nevertheless, I found it ironic that the rest of the book is about how to squelch your passion by acting/behaving/operating the “way you’re expected to” in order to advance your career.
That’s All It Takes?
The MITRE corporation has a terrific web site loaded with information on the topic of system engineering. In spite of this, on the “Evolution of Systems Engineering” page, the conditions for system engineering success are laid out as:
- The system requirements are relatively well-established.
- Technologies are mature.
- There is a single or relatively homogeneous user community for whom the system is being developed.
- A single individual has management and funding authority over the program.
- A strong government program office capable of a peer relationship with the contractor.
- Effective architecting, including problem definition, evaluation of alternative solutions, and analysis of execution feasibility.
- Careful attention to program management and systems engineering foundational elements.
- Selection of an experienced, capable contractor.
- Effective performance-based contracting.
That’s it? That’s all it takes? Piece of cake. Uh, I think I’ll ship some parkas and igloo blueprints to hell to help those lost souls adapt to their new environment.
Psychopaths And Bozeltines
As I sat down to write my next post, I was staring at the blank page when this quote came to mind:
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. – Damian Conway
D’oh!
I really do try to take Damian’s message to heart. How about you? Do you buy into it? Do you buy into this instead:
Always code as if the maintainers of your code will be bozeltines who won’t have a freakin’ clue about what it does, how it works, or how to modify it – and so that they’ll be in awe of how much smarter you are than them.
Benevolent Dictators And Unapologetic Aristocrats
The Editor in Chief of Dr. Dobb’s Journal, Andrew Binstock, laments about the “committee-ization” of programming languages like C, C++, and Java in “In Praise of Benevolent Language Dictators“:
Where the vision (of the language) is maintained by a single individual, quality thrives. Where committees determine features, quality declines inexorably: Each new release saps vitality from the language even as it appears to remedy past faults or provide new, awaited capabilities.
I think Andrew’s premise applies not only to languages, but it also applies to software designs, architectures, and even organizations of people. These constructs are all “systems” of dynamically interacting elements wired together in order to realize some purpose – not just bags of independent parts. As an example, Fred Brooks, in his classic book, “The Mythical Man-Month“, states:
To achieve conceptual integrity, a design must proceed from one mind or a small group of agreeing minds.
If a system is to have conceptual integrity, someone must control the concepts. That is an aristocracy that needs no apology.
The greater the number of people involved in a concerted effort, the lower the coherency within, and the lower the consistency across, the results. That is, unless a benevolent dictator or unapologetic aristocrat is involved AND he/she is allowed to do what he/she decides must be done to ensure that conceptual integrity is preserved for the long haul.
Of course, because of the relentless increase in entropy guaranteed by the second law of thermodynamics, all conceptually integrated “closed systems” eventually morph into a disordered and random mess of unrelated parts. It’s just a matter of when, but if an unapologetic aristocrat who is keeping the conceptual integrity of a system intact leaves or is handcuffed by clueless dolts who have power over him/her, the system’s ultimate demise is greatly accelerated.
Popularity Contest
The TIOBE Programming Community index is an indicator of the popularity of programming languages. The index is updated once a month. The ratings are based on estimates of the number of skilled engineers world-wide, available training courses, and third party vendors. The results are computed (somehow) from the web’s most popular search engines; Google, Bing, Yahoo!, Wikipedia, YouTube, and Baidu.
My favorite language, C++, is in third place, but quite a bit behind Java and C. I think that Objective-C took a big jump relative to last year because of the Apple iPad juggernaut. I’m bummed that my second favorite language, Erlang, didn’t even make the top 20.
The Elephants In The Room
One of the originators of RUP and the creator of the 4+1 view modeling approach, Phillippe Kruchten, has written a terrific article on the “twenty elephants in the room” that haunt the agile movement. Here’s a subset of his infamous list that resonates with me:
- Commercial interests censoring failures (tell me about the failures).
- Failure to dampen negative behaviours (no analysis of failures).
- Context and contextual applicability of practices (can you say “safety-critical systems“?)
- Anarchism (preventing a more systematic organization of the body of knowledge).
- Elitism (blame failure on the “unenlightened” others)
- Certification (effective tool to assess maturity for individuals and organization, or commercial ploy from trainers and consultants to rake in the dough?)
- Role of architecture and design (they are still often equated to BUFD, and rapidly brushed aside with claims of YAGNI, or “we’ll refactor it later”)
- Scaling naïveté (with a bit of imagination all agile practices scale up, and if this does not work it is because you have not tried hard enough).
- Technical debt (while agile practices could help control technical debt, they are also often at the root, the cause of massive technical debt).
- Effective ways of discovering information without writing source code (uh, can you say “modeling“?).
Of course, because of his involvement in the development of the perceived horrible, heavyweight, RUP process, extreme agilistas will not even listen to Phillippe’s ideas – let alone ponder the validity of any of them.
One Size Fits All
On Bjarne Stroustrup’s FAQ page, he state’s his opinion on the utility of object oriented programming:
The strength of OOP is that there are many problems that can be usefully expressed using class hierarchies – the main weakness of OOP is that too many people try to force too many problems into a hierarchical mould. Not every program should be object-oriented. As alternatives, consider plain classes, generic programming, and free-standing functions (as in math, C, and Fortran).
The same could be said of organizations of people, no? Of course, in a purposeful org of people and machines, the goal is to produce and distribute material wealth to all stakeholders: products/services to its customers and financial well-being to its employees and owners. Thus, some sort of controller-controllee structure is required to keep the org from deviating too far from its purpose. There are alternative structures to hierarchy but, as Bjarne sez, “too many people try to force too many problems into a hierarchical mould“. Bummer.
Botted?
I’ve been blogging for over 2 years now. Until a few days ago, the maximum number of hits that this blog had absorbed in one day was 149. On 07/29/11, my blogs stats chart zoomed to 291 hits:
After zeroing in on the July 29 date, I discovered that 231 of the hits came from Google:
From looking at the content of the referral links, I’ve concluded that a google bot had crawled the site and extracted/stored a bunch of the dorky images that I post daily. Do you think that’s what happened?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 