Archive

Posts Tagged ‘linkedin’

Disambiguation Text Boxes

October 23, 2010 Leave a comment

If you believe that 2D or 3D graphical models reveal more about a system than pure 1D  text models, then graphics should be the  primary means of communication for complex structural and behavioral  information, no? Nevertheless, sequential text annotations can be an important secondary contributor to the transmission of meaning and understanding via graphics. A skillful combination of graphics plus text  is best, dontcha think?

Graphical notations, while important and useful, aren’t sufficient. They simply capture the end product of the design process as relationships between classes and objects. To reuse the design, we must also record the decisions, alternatives, and trade-offs that led to it. – The GoF

DTBs, or Disambiguation Text Boxes (a.k. a. notes, legends), can be used to help fill in some of the subtle gaps in understanding that graphics alone cannot disclose/convey to people who need to deeply understand the message/content of what you’re trying to say. DTBs can contain full sentences or just phrases and acronyms; whatever it takes to help your readers extract whatever meaning and understanding they need to do their jobs better. And you do want to help others, no?

The figures below show some examples of attempts to use DTBs to help readers understand and make meaning from graphics models. Of course, graphics and text models can’t and shouldn’t totally replace physical human-to-human interaction, but they can lessen the required frequency of face to face communication and reduce errors when face to face meetings do occur, right?

Accept And Continue, Or Accept And Change

October 22, 2010 Leave a comment

If you’ve acquired a “bad rep” in a group, regardless of whether you think it’s deserved, it doesn’t matter how you present issues, problems, ideas, or solution options to anyone who perceives you as a “bad” person. Your ideas could have the potential to increase the group’s material or spiritual wealth, but……… fuggedabout getting any help from the “good” people. The “good” people are, by definition, those in positions of power who control the resources of production.

Once you understand the key principle of bad_rep == no_help, the first thing to do is get over any frustration and angst that you have from being “unfairly” adorned (how dare they!) with a scarlet letter. It’s out of your control, bozeltine. The next thing to do is to decide whether:

  1. to continue on being authentic, reinforcing your “bad rep” perception (if so-be-it) and knowing full well the consequences of your M.O.
  2. to attempt to force yourself into something you’re not. You know, morph into a “good” person so that the “bad rep” perception slowly dissolves in the minds of other “good” people.

I recommend continuing on and doing your thang as only you can do. You see, once your “bad rep” image gets burned into the UCB of one or more “good” people, it can never be erased. That’s because…… and here comes the usual acronym-laden rant that you may have been waiting for…… “good” BMs, CGH’s, SCOLs and BOOGLs are hoarders. They can add images and perceptions to their UCBs, but since they’re infallible, they are incapable of periodically re-assessing its truthiness and cleaning house. Like the Hotel California, “stuff can check in but it can never leave“.

I hate people who think in terms of “us and them”. You know, people like me. – Bulldozer00

Late Breaking News: After I wrote and queued up this vitriolic post, I discovered that one of my heroes, Scott Berkun, wrote a similar, but much more elegant, less offensive, and insightful one. Check it out here: “How To Keep Your Mouth Shut“, and be sure to watch the classic video snippet he points you to. It’s arguably the best caricature of a BM ever created.

Software Debt

October 21, 2010 Leave a comment

If it hasn’t taken place already, be prepared for the latest buzz-concept in the software development world to go viral –  “Software Debt“. I think that Ward Cunningham (who I love because he invented the Wiki) is the originator of the term “technical debt“, from which “Software Debt” is, no doubt, derived.

Voila, here’s the first book that I’ve seen so far with “Software Debt” in it’s title. Expect all kinds of seminars and videos and professional “Software Bankers” (who will certainly help you keep your debt low and prevent foreclosure by your customers) to sprout up all over like fungi in a dark, stanky, and moist environment. After all, the well worn and tired “agile” buzzword needs to be replaced by something just as exciting, no?

In my twisted mind, “Software Debt” is no different, but sounds a lot kooler than the bland “Software Maintainability“. Designing, coding, and artifacting to manage “Software Debt” is no different than doing the same for “Software Maintenance“. What do you think?

Hi, I’m a software banker and I can help you consolidate and pay off all your software debt. Trust me, I will solve all your maintenance, oops, I mean debt, problems in no time flat. Plus, my fee is reasonable.” – Bulldozer00

Liked And Respected

October 20, 2010 Leave a comment

Check out this snippet from “Proofiness: The Dark Arts Of Mathematical Deception“. It talks about people lying in the context of being asked questions by pollsters, but it also applies daily in corpricracies everywhere, dontcha think?

It’s an innocent, human-nature-driven, corpo lie-fest: DICs lie to BUTTs; DICs lie to fellow DICs; BUTTs lie to other BUTTs; BUTTs lie to DICs. Got all that?

When a corpo environment is stable, the lying is kept to a minimum. When org stress rises during times of misfortune and financial instability, the lying escalates. Some DICs and BUTTs lie regularly, regardless of org stability. Uh, wait a minute. Maybe it’s just me who lies regularly in my fruitless search for likeability, respectability, honorability, trustability, noblility, integrity, blah-blah-blah; but you don’t.

An arguable, hypothetical case of SCOL-to-SCOL lying is shown below. It’s “arguable” because the repeated, measured shortfalls between planned and actual results could be totally innocent due to market conditions. What do you think the example represents? Lying? Innocent mistakes? Innocent, but culturally forced lying?

How about the example below? What do you think about these results? Can one make a judgment on “data” alone?

A Life Changing Experience?

October 19, 2010 2 comments

The article “Undercover Boss’ role opens Republic Airways CEO’s eyes” describes what Republic Airways CEO Bryan Bedford learned while participating on the show “Undercover Boss“. In the show, CEOs go undercover and work on the front lines as a DORK in disguise.

Here’s one thing Mr. Bedford said of his experience:

“What was eye-opening, the most noticeable thing was just the disconnect and (poor) communication between the management team and front-line employees,” Bedford said.

I don’t know what was so eye opening about it. As usual, I just don’t get it. Do you? Do you now understand the meaning of one of the profanely endearing acronyms, CGH, that I often use in this boisterous blog?

Moving on, here’s some more unsurprising (at least to me) commentary :

While working in different roles for the company — including cleaning aircraft, checking baggage, dumping aircraft toilets and standing at the ticket counter — he asked fellow employees why they didn’t take their complaints to management to implore change. The same response came time and time again: “No, I’ve talked to management about this stuff, and they never listen,” Bedford said.

Wow. Huge surprise, no? Why won’t the BMs, BUTTs, and CCRATs in the fatty middle org layers listen to, and act on, DICforce inputs? Because it would require hard work and it could make them look bad. You know, their image of being infallibly in charge might suffer: “Damn the org, it’s all about me and my success“.

“Are you here to build a career or to build an organization?” – Peter Block

I’m almost done with this rant, so bear with me just a couple of more sentences. Summing up his experience, Mr. Bedford relates his epiphany:

When you are actually working side by side and hearing about their struggles, it’s very personal. It’s life-changing. You can never go back to thinking of them as anything other than family.

So, six months from now, after returning to the same-old, same-old business as usual (operating off spreadsheets and powerpoints, communicating solely with his hand picked yes-men junta, caving to pressure from Wall St. and shareholders) do you think Bryan will remember what he said? I hope so, but I doubt it. He’s human just like you and (maybe) me.

How about you? Even if he/she wanted to, would your CEO, or even your immediate manager, be capable of doing your job in order to experience your frustrations at the inefficiency, dysfunction, and red tape that engulfs you?

Feedback Insertion

October 18, 2010 Leave a comment

Let’s say that you come up with a great product idea that is both wanted and needed by a large market (ka-ching!). Let’s also say that your product is non-trivial and it requires specialized expertise to produce it from raw inputs to its value-added end state. After mustering up enough courage and scrounging up enough money, you become an entrepreneur – whoo hoo! So, you design the system below, hire the expertise you need, and kick off the enterprise. Of course, you rightly put yourself in the controller position and serve as the system coordinator.

Uh, what’s missing from your design? Does the next picture below help? Still can figure it out?

Is feedback missing? Even though your customers need and want and buy your product, how do you know when/if your quality goes down hill and/or your customers want and need new features? Voila! You figure it out and design/install a feedback channel from your customers to you, and only you:

By responsively acting on customer inputs on your new feedback channel, you steer, guide, and direct your team back on track – until the complaints on the feedback channel start rising again. What’s wrong with your system now? Does the system augmentation below answer the question?

Because of increasing product complexity and your lack of in depth knowledge of it, (if you’re not an egomaniacal control freak,) you own up to the possibility that you could be misunderstanding and filtering out some customer feedback and you could be directing your team poorly. Accepting your humility, you set up a second feedback channel from your customers directly to your development team.

Now you’re back on track again – whoo hoo! But wait, something goes awry again and the customer complaint rate starts rising again. Since feedback solved your problems before, you set up additional feedback channels between yourself and your producer team and between your sub-teams:

Will this latest system enhancement work? Hell, I don’t know. Complexity begets complexity. Your increasingly complex system design might implode because of all the communication channels in the system and the fragmentation of contradictory messages that flow at high rates within the channels. If it doesn’t work, you could keep experimenting with changes to fine tune the system for stability and robustness.

The figure below shows yet another system enhancement possibility – the addition of another controller to ensure that the production sub teams receive coherent and filtered info from your customers. It may work, but it will fail if your second controller issues guidelines, advice, commands, and orders to your production team that contradict yours.

To solve your cross-management problem, you can setup a two way channel between yourself and your second controller to resolve contradictions and ambiguities:

So, what’s the point of this long and boring, multi-picture post? Geez, I don’t know. I wrote it on the fly, in a stream of consciousness with no pre-planned point in mind.

But wait, a possible answer to the question just popped into my head out of nowhere. The point of this post is to keep adapting and trying new things when your external environment keeps changing – which it always will. One thing is for sure: don’t design your operation like the very first picture in this post – open loop. Ensure that feedback channel(s) from your customers are in place and the information that flows on it (them) is acted upon to keep your product in synch with your customers.

Sheesh, I’m finally done!

An Estimation Example

October 17, 2010 Leave a comment

The figure below shows the derivation of an estimate of work in staff-hours to design/develop/test a Computer Software Configuration Item (CSCI) named YYYY. The estimate is based on the size of an  existing CSCI named XXXX and the productivity numbers assigned to the “Real Time” category of software from the productivity chart in Steve McConnell‘s “Software Estimation: Demystifying the Black Art“.

Of course, the simple equation used to compute effort and all of the variables in it can be challenged, but would it improve the accuracy of the range of estimates?

All Hands Meeting: Open To The Public

October 16, 2010 Leave a comment

Check out this e-mail invite from Zappos.com:

I participated as a cyber-attendee at the previous Zappos.com online all hands meeting. It wasn’t scripted, and some topics were discussed that your grandfather’s company of yesteryear would never air in public. Of course, your grandfather’s company of yesteryear, stuck in its FOSTMA mindset, could never even conceive of the idea of broadcasting an all hands meeting online.

“Few people are capable of expressing with equanimity opinions which differ from the prejudices of their social environment. Most people are even incapable of forming such opinions.” – Albert Einstein

Since clicking on the link in the above graphic won’t work, here’s a clickable signup link: Zappos All Hands Meeting Signup. Attend the meeting if you can and judge for yourself whether or not it’s a pure propaganda play.

Estimation Deflation

October 15, 2010 1 comment

The best book I’ve read to date on the topic of software effort and schedule estimation is Steve McConnell‘s “Software Estimation: Demystifying the Black Art“. According to Mr. McConnell, two large influences on the amount of work required to develop a non-trivial piece of software are “size” and “kind“. Regardless of the units of measure (use cases, user stories, function points, Lines Of Code, etc), the greater the “size”, the greater the amount of work required to build the thang. Similarly, the harder “kinds” are associated with lower productivity than the simpler “kinds”.

In his book, McConnell provides the following handy, industry-data-backed,  “kinds” vs “productivity” table that’s parameterized by “size” (in Lines Of Code (LOC)). Note that the “kinds” are sort of arbitrary and by no means an industry standard.

The Real-Time, 10K-100K LOC entry is circled because that’s the type and typical size of software that I specify/design/write. Note the huge 15-to-1 range of productivity for the type. Also note that the table contains large ranges of productivity for all the kind-size entries. Hint, hint: estimating is hard.

Ideally, for psuedo-accurate planning purposes, a software development org maintains its own table (see bogus example below) with real, measured numbers for the sizes of the CSCIs (Computer Software Configuration Items) that its DICs have created.

Of course, for a variety of cultural, competence, and social reasons, a lot of orgs don’t measure or maintain a custom productivity table. Thus, estimators are forced to pull numbers out of their arses and anyone’s productivity estimate is as bad anyone else’s. Everyone who wasn’t born yesterday knows that the pressure to use ridiculously high productivity numbers in work estimates pervades the ether in most orgs. Even when some FAI bucks the trend and withstands the looks and sound bites of disdain for conjuring up a work estimate that is perceived by the management chain as “too high”, the final estimates that show up on “approved” schedules are magically deflated to what is wanted by some clueless BM, SCOL, or CGH.

Responsibilities And Compensation

October 14, 2010 2 comments

If you’re in the blue box, better shoot for the yellow box ASAP and start accumulating titles (to post on LinkedIn.com) before your compensation curve flattens. Since there are fewer multividual contributors in an org pyramid, by auto-assumption they must be more valuable and deserving, right? Of course, the graphic below is an extreme exaggeration, but how far off the mark do you really think it is?