Archive

Posts Tagged ‘linkedin’

Let’s Be Careful Out There!

September 30, 2009 Leave a comment

Based on a recommendation from fellow whack-job W. L. Livingston, I’m currently trying to read “The Theory Of The Leisure Class” by Thorstein Veblen (cool name, eh?). Man, this guy’s a tough read. The vocabulary that Thor(?) uses and his huge paragraphs often cause my CPU to overheat and spew blue smoke, but the self-imposed intellectual torture is worth the pain.

I love exploring the ideas and thoughts of guys like Veblen because they are so far off the beaten path and mind stretching that they cause new, but previously unused synaptic sub-networks to be instantaneously created in my brain. For me, spiritual and intellectual growth is painful but inspiring. The acts of  continuously trying to widen my horizons, destroying old and obsolete mental models, and exposing myself to the ideas of others makes me  feel vibrantly alive.

When you consciously choose to explore and probe weird and non-standard ideas that go against the norm, you’ve got to watch out for yourself. Internalizing and then subsequently espousing your new learnings in public can be detrimental to your health. If people are really set in their ways and you don’t take their feelings into account, you could trigger the fight or flight response in them. In one-on-one exchanges, the blowback that you experience may not be so bad. However, publicizing your new thoughts in a meeting with a group of clanthinkers can cause you considerable external and internal damage.

“Let’s Be Careful Out There”  – Sergeant Esterhaus

Let's be careful out there

Some Of My Heroes

September 29, 2009 3 comments

“We’re just two wild and crazy guys” – Yortuk and Georg Festrunk

Wild And Crazy Guys

Unlike the quote above, Joe Walsh’s “I’m just an ordinary average guy” fits me to a tee. In spite of this, I’d like to think that I’m open to new ideas and thinking. At the moment, here are some of my favorite, inspirational, weird, and forward looking (but pragmatic) thinkers:

Check out what one or more of these whack jobs have to say if  you’re yearning to explore and discover new opportunities that may crack the  concrete in your brain and challenge your same-old, same-old mental models of the world. If you think there is an “edge” to my blarticle posting style, then you should give all the credit to those dudes.

Who are your favorite thinkers, visionaries, and potential status-quo busters? What, you don’t have any? Why not?

My “Status” As Of 09-27-09

September 27, 2009 1 comment

I recently finished a 2 month effort discovering, developing, and recording a state machine algorithm that produces a stream of integrated output “target” reports from a continuous stream of discrete, raw input message fragments. It’s not rocket science, but because of the complexity of the algorithm (the devil’s always in the details), a decision was made to emulate this proprietary algorithm in multiple, simulated external environmental scenarios. The purpose of the emulation-plus-simulation project is to work out the  (inevitable)  kinks in the algorithm design prior to integrating the logic into an existing product and foisting it on unsuspecting customers :^) .

The “bent” SysML diagram below shows the major “blocks” in the simulator design. Since there are no custom hardware components in the system, except for the scenario configuration file, every SysML block represents a software “class”.

Test Harness

Upon launch, the simulator:

  1. Reads in a simple, flat, ASCII scenario configuration file that specifies the attributes of targets operating in the simulated external environment. Each attribute is defined in terms of a <name=value> token pair.
  2. Generates a simulated stream of multiplexed input messages emitted by the target constellation.
  3. Demultiplexes and processes the input stream in accordance with the state machine algorithm specification to formulate output target reports.
  4. Records the algorithm output target report stream for post-simulation analysis via Commercial Off The Shelf (COTS) tools like Excel and MATLAB.

I’m currently in the process of writing the C++ code for all of the components except the COTS tools, of course. On Friday, I finished writing, unit testing, and integration testing the “Simulation Initialization” functionality (use case?) of the simulator.Yahoo!

The diagram below zooms in on the front end of the simulator that I’ve finished (100% of course) developing; the “Scenario File Reader” class, and the portion of the in-memory “Scenario Database Manager”  class that stores the scenario configuration data in the two sub-databases.

Simulation Init

The next step in my evil plan (moo ha ha!) is to code up, test, and integrate the much-more-interesting “Data Stream Generator” class into the simulator without breaking any of the crappy code that has already been written. 🙂

If someone (anyone?) actually reads this boring blog and is interested in following my progress until the project gets finished or canceled, then give me a shoutout. I might post another status update when I get the “Data Stream Generator” class coded, tested, and integrated.

What’s your current status?

Proprietary Sneeze

September 26, 2009 1 comment

In stodgy, arrogant, and paranoid corpocracies, everything is marked as proprietary: the company letterhead, the standard powerpoint layout, all documented processes (that (shhhh!) nobody follows), every e-mail, every conversation, the company newsletter, the recipes in the cafeteria, etc. Hell, when someone sneezes it’s deemed proprietary. Geez, what up wit dat?

“Lighten up Francis” – Sergeant Hulka (from the movie “Stripes”)

Heaven forbid that a competitor gets its slimy hands on any of your proprietary “stuff”. OMG, they’ll put you out of business by using all of your world-changing intellectual property against you. Anyone caught disclosing anything about the corpo innards will swiftly receive a peek-a-boo visit from a high ranking corpocrat, right?

To be fair, there probably is some stuff that really is proprietary, like some domain-specific algorithms and/or some custom hardware modules. But gimme a break Einstein. Regardless of what you espouse, the ubiquitous Bell curve says that you’re most likely not all that (pause for a yawn) great. Although you, like the vast majority of corpo citadels on the landscape, think and espouse that you’re obviously a cut above the rest, you’re not. Deal with it. Remove the camouflage that everyone is aware of, but is forbidden to discuss.

When you explicitly “allow” your  people to discuss the undiscussables in a truly open and receptive environment without publicly or privately tarring and feathering them, then you’ve taken the first courageous step toward differentiating yourself from the herd.  Mooo!

The Herd

Note: I’m just a Dilbertonian DIC (Dweeb In the Cellar) who makes things up, so don’t believe a word I say.

Six To Nine Months

September 25, 2009 1 comment

As a rule of thumb, one can assume that a corpo reorg will take place every six to nine months. “Our new organization will (no doubt) increase efficiency, profitability, and align us more closely with our customers“. Yada, yada, yada. Yeah, right. Whatever you say dude.

The figure below shows sample before-and-after corpo reorg charts. After the re-org, more profit-sapping fat has been added in an ill fated attempt to increase corpo performance. In the shiny new org, less productive work gets performed because some lucky(?) or ass-kissin’  DICs (Dweebs In the Cellar) are “promoted” into the ranks of the elite. Of course, as a reward for their loyalty, and regardless of their performance (because behavior is always more important than performance), some MIMs (Managers In the Middle) are further promoted up into the rafters or reshuffled sideways. Narrow, specialized, confusing, undefined, and weird new corpo titles are conjured up like “manager of the company newsletter”, “deputy director of timecard compliance”, “director of trade show booth setup “, and “manager of coffee grounds disposal”.

reorgs

After six to nine months of further deteriorating financial performance, the corpo hierarchs shrug, scratch their heads, and repeat the cycle  to “(no doubt) increase efficiency, profitability, and align us more closely with our customers“. Wash, rinse, and repeat. Wash, rinse, and repeat………….

Sole Source

September 24, 2009 Leave a comment

When a customer awards a vendor a contract without considering bids from other competitors, it is deemed a sole source victory. There are two ways to look at “sole source” contracts:

  • The customer loves you
  • The customer hates you

If you’ve done a great job providing a product that unobtrusively solves a customer’s problem, then that customer will love your company. Hence, if  the “rules” allow it, that customer will shower you with follow on sole source contracts for more copies and variants of the product.

If your product sux but it is inextricably and pervasively intertwined within the customer’s day-to-day operations, then your customer may hate you. However, since it would cost a ton of money and time to rip out and replace your junk with someone else’s junk, the customer may still shower you with follow on sole source contracts.

Regardless of which reality is true, corpo hierarchs will always attribute sole source contract awards to love.

Sole Source

Categories: business Tags: , , ,

Evasion And Abdication

September 22, 2009 1 comment

One way to evade or abdicate responsibility is to never write anything down. Writing something down is a form of commitment because other people can see what you wrote, and archive it, and use it to hold you accountable.

“The palest of ink is better than the best memory.” – Chinese proverb

As a rule, managers don’t write down what they’ve signed up to do because they don’t “do” anything of substance. Of course, everyone in a standard cookie-cutter corpo hierarchy unquestioningly accepts that it’s “not a manager’s job” to do or commit to anything. Managers do, however, insist that others write things down because without the written word a manager can’t periodically poll for status and hold others accountable when schedules are missed.

On the other hand, really bad managers love to conjure up and write down what work others are required to do and when that work is due (even when they don’t have a klue what the work is). It’s the best of both worlds because they can hold others accountable without having to be held accountable themselves (whoopee!).

Even if managers are held accountable for poor team performance by higher up meta-managers (who also don’t write down their non-existent commitments),  they don’t experience a guilty conscience because they fall back on the “the team failed and not me because it’s not my job” mentality.

When was the last time your immediate manager asked you “what problems are you having and how can I help?” or told you “let me know when you run into a problem so that I can try my best to help you“?

Abdication

Disclaimer: I don’t have any badges or credentials and I just make things up, so don’t believe a word I say.

90 Percent Done

September 20, 2009 1 comment

In order for those in charge (and those who are in charge of those who are in charge ad infinitum) to track and control a project, someone has to estimate when the project will be 100% complete. For any software development project of non-trivial complexity, it doesn’t matter who conjures up the estimate, or what drugs they were on when they verbalized it, the odds are huge that the project will be underestimated. That’s because in most corpo command and control hierarchies, there is always implicit pressure to underestimate the effort needed to “get it done”. After all, time is money and everyone wants to minimize the cost to “get it done”. Even though everybody smells the silent-but-deadly stank in the air and knows that’s how the game is played, everybody pretends otherwise.

The graph below shows a made up example (like John Lovitt, I’m a patholgical liar who makes everything up, so don’t believe a word I say) of a project timeline. On day zero, the obviously infallible project manager (if you browse linkedin.com, no manager has ever missed a due date) plots a nice and tidy straight (blue) line to the 100% done date. During the course of executing the project, regular status is taken and plotted as the “actual” progress (red) line so that everybody who is important in the company can know what’s going on.

100 Percent Done

For the example project modeled by the graph, the actual progress starts deviating from the planned progress on day one. Of course, since the vast majority of project (and product and program) managers are klueless and don’t have the expertise to fix the deficit, the gap widens over time. On really dorked up projects, the red line starts above the blue line and the project is ahead of schedule – whoopee!

At around the 90-95% scheduled-to-be-done time, something strange (well, not really strange) happens. Each successive status report gets stuck at 90% done. Those in charge (and those who are in charge of those who are in charge ad infinitum) say “WTF?” and then some sort of idiotic and ineffective action, like applying more pressure or requiring daily status meetings or throwing more DICs (Dweebs In the Cellar) on the project, is taken. In rare cases, the project (or product or program) manager is replaced. It’s rare because project (and product and program) managers and those who appoint them are infallible, remember?

So, is “continuous replanning”, where new scheduled-to-be-done dates are estimated as the project progresses, the answer? It can certainly help by reducing the chance of a major “WTF” discontinuity at the 90% done point. However, it’s not a cure all. As long as the vast majority of project (and product and program) managers maintain their attitude of infallibility and eschew maintaining some minimum level of technical competence in order to sniff out the real problems, help the team, and make a difference, it’ll remain the same-old same-old forever. Actually, it will get worse because as the inherent complexity of the projects that a company undertakes skyrockets, this lack of leadership excellence will trigger larger performance shortfalls. Bummer.

Surveillance Systems

September 19, 2009 Leave a comment

The purpose of a surveillance system is to detect and track Objects Of Interest (OOI) that are present within a spatial volume covered by a sensing device. Surveillance systems can be classified into four types:

  • Cooperative and synchronized
  • Cooperative and unsynchronized
  • Un-cooperative and active
  • Un-cooperative and passive

In cooperative systems, the OOI are equipped with a transponder device that voluntarily “cooperates” with  the sensor. The sensor continuously probes the surveillance volume by transmitting an interrogation signal that is recognized by the OOI transponders. When a transponder detects an interrogation, it  transmits a response signal back to the interrogator. The response may contain identification and other information of interest to the interrogator. Air traffic control radar systems are examples of cooperative, synchronized surveillance systems.

CoopSync

In a cooperative and unsynchronized surveillance system, the sensor doesn’t actively probe the surveillance volume. It passively waits for signal emissions from beacon-equipped OOI. Cooperative and unsynchronized surveillance systems are less costly than cooperative and synchronized systems, but because the OOI beacon emissions aren’t synchronized by an interrogator, their signals can garble each other and make it difficult for the sensor detector to keep them separated.

CoopUnSync

In uncooperative surveillance systems, the OOI aren’t equipped with any man made devices designated to work in conjunction with a remotely located sensor. The OOI are usually trying to evade detection and/or the sensor is trying to detect the OOI without letting the OOI know that they are under surveillance.

In an active, uncooperative surveillance system, the sensor’s radiated signal is specially designed to reflect off of an OOI. The time of detection of the reflected signal can be used to determine the position and speed of an OOI. Military radar and sonar equipment are good examples of uncooperative surveillance systems.

UnCoopActive

In a passive, uncooperative surveillance system, the sensor is designed to detect some type of energy signal (e.g. heat, radioactivity, sound) that is naturally emitted or reflected (e.g. light) by an OOI. Since there is no man made transmitter device in the system design, the detection range, and hence coverage volume, is much smaller than any of the other types of surveillance systems.

UnCoopPassive

The dorky classification system presented in this blarticle is by no means formal, or official, or standardized. I just made it up out of the blue, so don’t believe a word that I said.

Status Takers And Schedule Jockeys

September 16, 2009 Leave a comment

Status Takers And Schedule Jockeys

Whoo hoo! I’ve been promoted to “manager” by the Gods from above. I’m not a DIC (Dweeb In the Cellar) anymore. I’ve transitioned to the easy life of “taking status and riding the schedule”. Now I can shut down my brain because I don’t have to think or create anymore. I just have to walk around and: poll for status, look worried when people fall behind schedule, and “nicely” exert pressure on the team to perform. To top it all off, I got a big raise because of my “increase in responsibility”! Man, I love corpocracies and hieararchical gigs.