Archive
Reasonable Debugging
In Rich Hickey‘s QCon talk, “Simple Made Easy”, he hoisted this slide:
So, what can enhance one’s ability to “reason about” a program, especially a big, multi-threaded, multi-processing beast that maps onto a heterogeneous hodge-podge network of hardware and operating systems? Obviously, a stellar memory helps, but come on, how many human beings can remember enough detail in a >100K line code base to be able to debug field turds effectively and efficiently?
How about simplicity of design structure (whatever that means)? How about the deliberate and intentional use of a small set of nested, recurring patterns of interaction – both of the GoF kind and/or application specific ones? Or, shhhh, don’t say it too loudly, how about a set of layered blueprints that allow you and others to mentally “fly” over the software quickly at different levels of detail and from different aspect angles; without having to slodge through reams of “flat” code?
Do you, your managers, and/or your colleagues value and celebrate: simplicity of design structure; use of a small set of patterns of interaction; use of a set of blueprints? Do you and they walk the talk? If not, then why not? If so, then good for you, your org, your colleagues, your customers, and your shareholders.
Misapplication Of Partially Mastered Ideas
Because the time investment required to become proficient with a new, complex, and powerful technology tool can be quite large, the decision to design C++ as a superset of C was not only a boon to the language’s uptake, but a boon to commercial companies too – most of whom developed their product software in C at the time of C++’s introduction. Bjarne Stroustrup‘s decision killed those two birds with one stone because C++ allowed a gradual transition from the well known C procedural style of programming to three new, up-and-coming mainstream styles at the time: object-oriented, generic, and abstract data types. As Mr. Stroustrup says in D&E:
Companies simply can’t afford to have significant numbers of programmers unproductive while they are learning a new language. Nor can they afford projects that fail because programmers over enthusiastically misapply partially mastered new ideas.
That last sentence in Bjarne’s quote doesn’t just apply to programming languages, but to big and powerful libraries of functionality available for a language too. It’s one challenge to understand and master a language’s technical details and idioms, but another to learn network programming APIs (CORBA, DDS, JMS, etc), XML APIs, SQL APIs, GUI APIs, concurrency APIs, security APIs, etc. Thus, the investment dilemma continues:
I can’t afford to continuously train my programming workforce, but if I don’t, they’ll unwittingly implement features as mini booby traps in half-learned technologies that will cause my maintenance costs to skyrocket.
BD00 maintains that most companies aren’t even aware of this ongoing dilemma – which gets worse as the complexity and diversity of their product portfolio rises. Because of this innocent, but real, ignorance:
- they don’t design and implement continuous training plans for targeted technologies,
- they don’t actively control which technologies get introduced “through the back door” and get baked into their products’ infrastructure; receiving in return a cacophony of duplicated ways of implementing the same feature in different code bases.
- their software maintenance costs keep rising and they have no idea why; or they attribute the rise to insignificant causes and “fix” the wrong problems.
I hate when that happens. Don’t you?
Complexity, Evolution, Growth
Is an increase in complexity required for evolution to occur?
Likewise, is an increase in complexity required for growth to occur?
Frag City
As the accumulation of knowledge in a disciplinary domain advances, the knowledge base naturally starts fragmenting into sub-disciplines and turf battles break out all over: “my sub-discipline is more reflective of reality than yours, damn it!“.
In a bit of irony, the systems thinking discipline, which is all about holism, has followed the well worn yellow brick road that leads to frag city. For example, compare the disparate structures of two (terrific) books on systems thinking:
Thank Allah there is at least some overlap, but alas, it’s a natural law: with growth, comes a commensurate increase in complexity. Welcome to frag city…
Attack And Advance
Check out this recent Grady Booch tweet on the topic of “why” he, James Rumbaugh, and Ivar Jacobson syntegrated their individual modeling technologies into what became the UML standard:
Over 20+ years ago, when the rate of global change was just a mere inkling of what it is today, my friend Bill Livingston stated in HFAW that: “complexity has a bright future“. He was right on the money and I admire people like Bill and the three UML amigos for attacking complexity (a.k.a ambiguity) head-on – especially when lots of people seem to love doing the exact opposite – piling complexity on top of complexity.
Extreme complexity may not be vanquishable, but (I think) it can be made manageable with the application of abstract “systems thinking” styles and concrete tools/techniques/processes created by smart and passionate people, no?
Illusion, Not Amplification
The job of the product development team is to engineer the illusion of simplicity, not to amplify the perception of complexity.
Software guru Grady Booch said the first part of this quote, but BD00 added the tail end. Apple Inc.’s product development org is the best example I can think of for the Booch part of the quote, and the zillions of mediocre orgs “out there” are a testament to the BD00 part.
According to Warren Buffet, the situation is even worse:
There seems to be some perverse human characteristic that likes to make easy things difficult. – Warren Buffet
Translated to BD00-lingo:
Engineers like to make make easy things difficult, and difficult things incomprehensible.
Why do they do it? Because:
A lot of people mistake unnecessary complexity for sophistication. – Dan Ward
Conclusion:
The quickest routes to financial ruin are: wine, women, gambling….. and engineers
No Obvious Deficiencies
While perusing my favorite quotes page for blog post seedlings, this one spoke to me:
“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.” – C.A.R. Hoare.
Being the mangler, distorter, and exaggerator that I am, here’s my version:
“There are two ways of camouflaging crappy work: One way is to present it so simply that there are no obvious deficiencies, and the other way is to make the presentation so complicated that there are no obvious deficiencies. Both ways are equally effective.” – C.A.R. Hoare + Bulldozer00.
Go, Go Go!
Rob Pike is the Google dude who created the Go programming language and he seems to be on a PR blitz to promote his new language. In this interview, “Does the world need another programming language?”, Mr. Pike says:
…the languages in common use today don’t seem to be answering the questions that people want answered. There are niches for new languages in areas that are not well-served by Java, C, C++, JavaScript, or even Python. – Rob Pike
In Making It Big in Software, UML co-creator Grady Booch seems to disagree with Rob:
It’s much easier to predict the past than it is the future. If we look over the history of software engineering, it has been one of growing levels of abstraction—and, thus, it’s reasonable to presume that the future will entail rising levels of abstraction as well. We already see this with the advent of domain-specific frameworks and patterns. As for languages, I don’t see any new, interesting languages on the horizon that will achieve the penetration that any one of many contemporary languages has. I held high hopes for aspect-oriented programming, but that domain seems to have reached a plateau. There is tremendous need to for better languages to support massive concurrency, but therein I don’t see any new, potentially dominant languages forthcoming. Rather, the action seems to be in the area of patterns (which raise the level of abstraction). – Grady Booch
I agree with Grady because abstraction is the best tool available to the human mind for managing the explosive growth in complexity that is occurring as we speak. What do you think?
Abstraction is selective ignorance – Andrew Koenig
Cleanliness And Understandability
While adding code to our component library framework yesterday, a colleague and myself concocted a 2 attribute quality system for evaluating source code:
When subjectively evaluating the cleanliness attribute of a chunk of code, we pretty much agree on whether it is clean or dirty. The trouble is our difference in evaluating understandability. My obfuscated is his simple. Bummer.
Armed And Ready
How much technical acumen does a project manager need to have in order to effectively manage a software-intensive product development effort? Are Spreadsheet, Gannt chart, PERT chart, EVM, Microsoft Project skills, and a golden certificate from schools like the vaunted PMI the only tools needed to lead a multi-disciplined, technical crew of engineers to so-called victory? I think not, but you may think differently – especially (and understandably) if you’re a project/program manager.
I think effective technical project managers are rare and they sprout from the trenches of one or more of the technical disciplines: software, hardware, test, and systems engineering. Wrestling with technical problems in the mud while under schedule pressure from multiple managers to keep costs down and to deliver quality promptly is the hazing experience needed to appreciate both the financial and technical aspects of a project or program. It may seem that project and program managers are under pressure themselves from executives above them in the command and control hierarchy, but unlike the dudes at the bottom of the food chain, they can easily pass the buck when financial and technical goals aren’t met. Who do ineffective BMs pass the buck to when the execs in the heavens demand accountability for poor project performance (usually way downstream after project execution has been supposedly progressing splendidly)? Why, the dweebs in the cellar of course.
“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
Cranking fat heads off the project management education assembly line and arming them with the necessary but insufficient skills to lead technically smart people into the raging battle against complexity is like arming firefighters with squirt guns to put out a 5 alarm fire. All it does is perpetuate the illusion of control and prep the graduates for moving higher up on the Plan-Watch-Control-Evaluate ladder – even though they don’t have a clue as to what they’ll be planning-watching-controlling-evaluating. But hey, I like to make things up and I’m not fit to lead anything, so don’t listen to a word I say 🙂
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 