Archive

Posts Tagged ‘linkedin’

Strongly Typed

February 25, 2010 9 comments

In “Hackers and Painters“, one of my favorite essayists and modern day renaissance men, Paul Graham, states his disdain for strongly typed programming languages. The main reason is that he doesn’t like to be scolded by mindless compilers that handcuff his creativity by enforcing static type-checking rules. Being a C++ programmer, even though I love Paul and understand his point of view, I have to disagree. One of the reasons I like working in C++ is because of the language’s strong type checking rules, which are enforced on the source code during compilation. C++ compilers find and flag a lot of my programming mistakes prior to runtime <- where finding sources of error can be much more time consuming and frustrating.

Driven by “a fierce determination not to impose a specific one size fits all programming style” on programmers, Bjarne Stroustrup designed C++ to allow programmers to override the built-in type system if they consciously want to do so. By preserving the old C style casting syntax and introducing new, ugly C++ casting keywords (static_cast, dynamic_cast, etc) that purposefully make manual casts stick out like a sore thumb and easily findable in the code base, a programmer can legally subvert the type system.

C++ gets trashed a lot by other programming language zealots because it’s a powerful tool with a rich set of features and it supports multiple programming styles (procedural, abstract data types, object-oriented, generic) instead of just one “pure” style. Those attributes, along with Bjarne’s empathy with the common programmer, are exactly why I love using C++. How about you, what language(s) do and don’t you like? Why?

Powerful Tools

February 24, 2010 3 comments

Cybernetician W. Ross Ashby‘s law of requisite variety states that “only variety can effectively control variety“. Another way of stating the law is that in order to control an innately complex problem with N degrees of freedom, a matched solution with at least N degrees of freedom is required. However, since solutions to hairy socio-technical problems introduce their own new problems into the environment, over-designing a problem controller with too many extra degrees of freedom may be worse than under-designing the controller.

In an analogy with Ashby’s law, it takes powerful tools to solve powerful problems. Using a hammer where only a sledgehammer will get the job done produces wasted effort and leaves the problem unsolved.  However, learning how to use and wield powerful new tools takes quite a bit of time and effort for non-genius people like me. And most people aren’t willing to invest prolonged time and effort to learn new things. Relative to adolescents, adults have an especially hard time learning powerful new tools because it requires sustained immersion and repetitive practice to become competent in their usage. That’s why they typically don’t stick with learning a new language or learning how to play an instrument.

In my case, it took quite a bit of effort and time before I successfully jumped the hurdle between the C and C++ programming languages. Ditto for the transition from ad-hoc modeling to UML modeling. These new additions to my toolbox have allowed me to tackle larger and more challenging software problems. How about you? Have you increased your ability to solve increasingly complex problems by learning how to wield commensurately new and necessarily complex tools and techniques? Are you still pointing a squirt gun in situations that cry out for a magnum?

Layered Obsolescence

February 23, 2010 2 comments

For big and long-lived software-intensive systems, the most powerful weapon in the fight against the relentless onslaught of hardware and software obsolescence is “layering”. The purer the layering, the better.

In a pure layered system, source code in a given layer is only cognizant of, and interfaces with, code in the next layer down in the stack. Inversion of control frameworks where callbacks are installed in the next layer down are a slight derivative of pure layering. Each given layer of code is purposefully designed and coded to provide a single coherent service for the next higher, and more abstract, layer. However, since nothing comes for free, the tradeoff for architecting a carefully layered system over a monolith is performance. Each layer in the cake steals processor cycles and adds latency to the ultimate value-added functionality at the top of the stack. When layering rules must be violated to meet performance requirements, each transgression must be well documented for the poor souls who come on-board for maintenance after the original development team hits the high road to promotion and fame.

Relative to a ragged and loosely controlled layering scheme (or heaven forbid – no discernable layering), the maintenance cost and technical risk of replacing any given layer in a purely layered system is greatly reduced. In a really haphazard system architecture, trying to replace obsolete, massively tentacled components with fuzzy layer boundaries can bring the entire house of cards down and cause great financial damage to the owning organization.

“The entire system also must have conceptual integrity, and that requires a system architect to design it all, from the top down.” – Fred Brooks

Having said all this motherhood and apple pie crap that every experienced software developer knows is true, why do we still read and hear about so many software maintenance messes? It’s because someone needs to take continuous ownership of the overall code base throughout the lifecycle and enforce the layering rules. Talking and agreeing 100% about “how it should be done”  is not enough.

Since:

  • it’s an unpopular job to scold fellow developers (especially those who want to put their own personal coat of arms on the code base),
  • it’s under-appreciated by all non-software management,
  • there’s nothing to be gained but extra heartache for any bozo who willfully signs up to the enforcement task,

very few step up to the plate to do the right thing. Can you blame them? Those that have done it and have been rewarded by excommunication from the local development community in addition to indifference from management, rarely do it again – unless coerced.

Why?

February 21, 2010 2 comments

Why are you behaving this way”? I’ve been asked that question quite frequently – mostly by a person higher up in a chain of authority with an approved title. My stock answer has always been something to the effect: “to expose errors, ambiguity, and mistakes so that they can be corrected and the whole can grow, develop, and temporarily arrest the growth in entropy that eventually destroys all closed systems“.  Even though that response has often stunned the questioner into a frozen silence, it’s never been enough to counter the pre-conceived opinion they have formed: “I’m a bad person who doesn’t care about the feelings of others“. Bummer.

Most of the time, I’m fully prepared for the external  “asshole judgment” and it bounces right off of me. At other times, and thank god (little “g” in “god” on purpose) it doesn’t happen that often, it pierces my heart and triggers a massive case of angst and discomfort. It sux to be human, no?

How about U? Do U ever get asked asked about your deviant behavior from the norm by those that are charged with judging U because of the inherent design of CCH bureaucracies? If not, why not? Is it because U are a saint who gets along with all souls? Is it because you suppress your individuality in order to conform to what is expected of good little children? What’s your story?

Throw It Away

February 19, 2010 Leave a comment

I’m currently in the process of helping a friend write his fourth book by providing feedback on the sections that he writes. As part of the creation process, he’s been discarding big chunks of work after revisiting them and finding that they don’t support the message he’s trying to communicate.

I don’t know about you, but I find it tough to throw away any work that I do (source code, models, algorithm designs, blog posts) – even when I know that it’s not good. I interpret this behavior as an ego-centric flaw and that’s why I admire people who can detect and chuck their crap. As the Buddhists say “Attachment brings suffering“.

“The ability to simplify means to eliminate the unnecessary so that the necessary may speak” – Hans Hofmann

Categories: miscellaneous Tags: , ,

Engage Me, Please

February 18, 2010 Leave a comment

Since many people spend a large amount of time at work, or thinking about work, I’ve been on a perpetual search for the keys to developing, and more importantly, sustaining an inspirational culture that brings daily joy to all. I’m keenly interested in the topic because an inspiring company culture, like quality, is ephemeral, hard to quantify, and hard to bring to fruition.

In this blog post, “The Hole In The Soul Of Business“, Gary Hamel laments the fact that so many business leaders come up empty when it comes to the creation and sustainment of an engaging company culture.

In my last post, I cited a survey that found that only 20% of employees are truly engaged in their work — heart and soul. As a student of management, I’m depressed by the fact that so many people find work depressing. In the study, respondents laid much of the blame for their lassitude on uncommunicative and egocentric managers…

Why is it that managers are so willing to acknowledge the idea of a company dedicated to timeless human values and yet so unwilling to become practical advocates for those values within their own organizations? I have a hunch. I think corporate life is so manifestly inhuman—so mechanical, mundane and materialistic—that any attempt to inject a spiritual note into the overtly secular proceedings just feels wildly out of place—the workplace equivalent of reading a Bible in a brothel.

The first step toward getting rid of a bad habit is admitting that you have a problem in the first place. Alas, uncommunicative and egocentric managers never admit that there is a problem. That’s because they’re infallible, of course.

Hey Nicky, Please Pass The Culture Sauce

February 17, 2010 Leave a comment

This Inc. Magazine piece, Lessons From a Blue-Collar Millionaire, tells the story of CEO Nick Sarillo and Nick’s Pizza & Pub. Like Tony Hsieh of Zappos.com , Jim Goodnight of the SAS Institute, and Ricardo Semler of Semco, Nick knows that the real key to business success is building a people-centric culture and relentlessly husbanding it so that the second law of thermodynamics doesn’t slowly but surely destroy it.

Here are some snippets from the article followed by comments from the peanut gallery.

In an industry in which annual employee turnover of 200 percent is considered normal, Sarillo’s restaurants lose and replace just 20 percent of their staff members every year. Net operating profit in the industry averages 6.6 percent; Sarillo’s runs about 14 percent and has gone as high as 18 percent. Meanwhile, the 14-year-old company does more volume on a per-unit basis (an average of $3.5 million over the past three years) than nearly all independent pizza restaurants. And customers, it seems, adore the service: On three occasions, waitresses have received tips of $1,000.

The above results clearly show that what Nick’s doing works, no?

Sarillo has built his company’s culture by using a form of management best characterized as “trust and track.” It involves educating employees about what it takes for the company to be successful, then trusting them to act accordingly. The company’s training program is elaborate, rigorous, and ongoing. The alternative is command and control, wherein success is the boss’s responsibility and employees do what the boss says.”Managers trained in command and control think it’s their responsibility to tell people what to do,” Sarillo says. “They like having that power. It gives them their sense of self-worth. But when you manage that way, people see it, and they start waiting for you to tell them what to do. You wind up with too much on your plate, and things fall through the cracks. It’s not efficient or effective. We want all the team members to feel responsible for the company’s success.”

There’s not much to add to the above snippet. I, and countless others much smarter and more eloquent than me, have ranted about the toxicity of dysfunctional CCH corpocracies to no avail.  CCHs litter the landscape anf they will continue to do so because of Nick’s quote: “They like having that power. It gives them their sense of self-worth.”

They had someone else put in the numbers, and when the numbers came out wrong, they didn’t dig deeper to discover why. Because they didn’t know the ‘why,’ they couldn’t share it with the team members. When you know the ‘why,’ it’s really easy to figure out what to do, but sharing that kind of information wasn’t how they’d been trained to manage.”

In the above snippet, Nick relates his experience when he mistakenly hired managers with the old “I’m the boss and I don’t do details – I’m better than that” 1920’s mindset.

People who inquire about a job receive a handout detailing the company’s purpose and values. Candidates need four yes votes from three managers to receive an offer. Just one of every 12 applicants to Nick’s gets hired. “I was really surprised by the process,” she says. “You get interviewed twice, and you take a personality test.”

Like other culture-obsessed companies, the interviewing process is key to separating the wheat from the chaff.

  • 1 Feel your community’s pain; share its joy
  • 2 Hire only A+ players
  • 3 Learn, grow, compensate
  • 4 Systems are for building trust
  • 5 Coach in the moment, not after the fact
  • 6 A consultant can be more helpful than you think
  • 7 Turn negatives into positives by making talk safe
  • 8 “Why” is more important than “what” or “how”
  • 9 “Trust” without “track” is an invitation to trouble
  • 10 Beware of growing before you — and the company — are ready

The above list represents the 10 key ingredients that Nick uses to drive his business. My faves are numbers 4, 7, 8, and 9. What are yours?

Central Planning

February 16, 2010 3 comments

The most visibly confirming event that showcased the fact that “central planning” doesn’t work was the demise of the former Soviet Union. The 5 year plans foisted down on the populace by the politburo big-wigs stifled creativity, innovation, and motivation. In spite of the impeccable planning by those “who knew better“, the country imploded.

Likewise, in corpocracies that are incapable of learning from the past (no matter how compelling the evidence), the same fate awaits. By the time the perfectly infallible strategies and plans from the corpo  junta get approved, poured in concrete, and trickled down to the DICforce at rock bottom, they’re mostly useless and obsolete.

So, what’s a better way? How about generating flexible, multi-year rolling plans that are revisited often? Ricardo Semler uses that method at Semco. How about exposing the plans to the DICforce as they are being developed in real-time so that some insights from a larger pool of brains may be elicited? Got any other ideas?

Fault Finder

February 15, 2010 Leave a comment

Byron Katie once said something like “the mind’s job is to find problems“. I don’t have many skills, but fault-finding is one of my most finely honed talents. Because of my engineering training and genetic design, I can find fault with any person, place, thing, or situation. I put myself right up there on Everest with Don Rickles.

The trouble with constant fault finding is that one spends a huge portion of one’s precious time criticizing instead of creating. It’s a real tragedy because we were all put on this earth to create. The ability to create is naturally built in to each of us right out of the box.

Creation is an intimate act of communication between the creator and the created.

Obsessive fault finders are afraid of creating and exposing their own creations for fear of being criticized themselves. No one likes to be told that their baby is ugly but, au contraire, many people love to point out flaws in other people’s fugly children.

One way to break the fault finder mind set is to take the plunge. Stop oppressing yourself, do what’s natural, start creating stuff (a blog, a song, a painting, a computer program, a book, a company, a community, a tribe), and hoist it out there for all to see. The more you create and expose of yourself, the more you dismantle the fault finder mindset and the more liberated you become. Try it, especially if you’re an incorrigible fault finder like me.

Waiting

February 14, 2010 1 comment
  • “I’m waiting for the requirements specification”.
  • “I’m waiting for management approval”.
  • “I’m waiting for the customer’s answers to my questions”.
  • “I’m waiting for QA appproval”.
  • “I’m waiting for management to solidify our strategy.”
  • “I’m waiting to get a software (or hardware or systems or test) engineer assigned to the project”.
  • “I’m waiting for the finance department to open the charge number.”

Yada, yada, yada. On goes the list of pseudo-legitimate excuses for being late and inefficient in bureaucratic corpocracies. When a system is set up so that everything is tightly coupled and each element is highly dependent on everything else, productivity sinks, end-to-end delay increases, and it takes a miracle to get any value added work done. The funny thing is that the dudes in the bozone layer demand continuously increasing productivity while simultaneously allowing their system to deteriorate into an inflexible and intertwined mess of confusion.