The Passive-Aggressive Programmer (again)

I'm not even interested in psychology.  But.  This kind of thing seems to come up once in a great while.

You're asked (or "forced") to work with someone who—essentially—fails to cooperate.  They don't actively disagree or actively suggest something better.  They passively fail to agree.

In fact, they probably disagree.  They may actually have an idea of their own.

But they prefer to passively "fail to agree."

I have little patience to begin with.  And I had noted my personal inability to cope in The Passive-Aggressive Programmer or Why Nothing Gets Done.

Recently, I received this.

"I thought I was going crazy and started doubting myself when dealing with a PAP co-worker. I went out on the internet searching for help and ran into your blog and its helped me realize that I'm not crazy. The example conversations you posted are almost every day occurrences here at my job when dealing with my co-worker. From outside of the department it was oh those two just butt-heads because I never knew how to communicate or point out that really I'm a targeted victim of a PAP rather than a butting heads issue. No matter what approach I took with the PAP I was doomed and still not quite sure where to go from here. Would you happen to offer any advice on how to actually deal with PAP? It's driven me to a point where I'm looking for new employment because my employer won't deal with it." 

I really have no useful advice.  There's no way to "force" them to agree with anything specific.  In some cases, there's no easy to even determine what they might agree with.

Your employer will only "deal with" problems that cause them real pain.  If you're butting heads, but still getting things done, then there's no real pain.  You're successful, even if you're unhappy.

If you want to be both happy and successful, you need to stop doing things that make you unhappy.  If you can't agree with a co-worker, you can butt heads (which makes you unhappy) or you can ignore them (which may make you happy.)

Ignoring them completely may mean that things will stop getting done.  You may appear less successful.  If you stop being successful, then your employer will start to feel some pain.

When you employer feels pain, they will take action to relieve the pain.

You might want to try to provide clear, complete documentation of your colleague's ideas, whatever they are.  If you write down the Passive-Aggressive Programmer's "suggestions", then you might be able to demonstrate what's causing the pain.  Since a properly passive programmer never actually agrees with anything, it's tricky to pin them down to anything specific.

You might be able to make it clear that they're the roadblock that needs to be removed.

Mid-Atlantic Design Expo (MADExpo)

I'm looking forward to this.  I'll be talking about Python.  

• A Python 3.2 tutorial.  I did a dry run with the help of the 757 Python group.  Made a bunch of changes based on their input.
• A more in-depth presentation on a good architecture of Database Schema Migration scripts.  You know, the "open heart surgery" of a database where the structure changes in some way that's not a trivial ALTER statement.

Are engineers valued?

Check out this post: "Why Quit? Because They Have Bigger Monitors".

Brilliant summary of a few small cost things that have a large impact.

How many other signals are being sent?

Jim B. once pointed out that some organizations are entirely run by the accountants.  You can have a good idea.  You can justify the good idea.  You can show ROI for the good idea.  And you can still be shot down in flames with feeble excuses like "it wasn't part of this year's budget, so we won't do it."

Delusional Project Managers

Maybe it's the circle-R in the PMP® signature that put me off.

What's important is that the PMP-certified project manager is absolutely married to fixed-price software development.  The idea of "Agile" was unthinkable.  They were very clear that we had enough information to create a fixed price.

It's hard to disagree with someone who's sure that their presentation is a pinnacle of project specification.

Slides 2 and 3 are an overview that lists some broad, vague buzzwords.  ("Asset", "Resource")

Slides 4 to 7 are blurry screen shots of the legacy application.  There must be dozens of pages.  We were shown four.

Slide 8 is a list of project objectives with no priorities, actors or user stories.  "Modify tool navigation to be more intuitive and efficient."  That's the kind of stuff that's supposed to define the scope with enough detail to create a fixed price.

Slide 9 is  another list of objectives.  "Create a simple project and resource KPI dashboard showing real-time status."  I'm not even sure we can define a fixed-price task for figuring out what this might mean.

Slide 10 is a schedule in which all of the dates are already in the past.

We were told -- firmly and finally -- that we were supposed to fabricate a fixed price proposal from this PPT.  We were encouraged to ask follow-up questions.

My first follow-up question should be "Are you crazy?"

My second follow-up question should be "How much time are you willing to put into this effort?  If it's less than 4 hours per day, we can't really help much."

I'm guessing that we're just "column fillers".  There's an incumbent team that has an existing proposal to extend or rewrite; we're merely providing an outside, "independent" quote that can be used for comparison purposes.  The incumbent team probably knows (in detail) the actors and user stories, and has a carefully prioritized feature set.  We don't even know (precisely) what's in the data model.

I would like to avoid writing a "column filler" proposal that will be a million dollars more than they had in mind.

An Agile approach (5 people × 8 hrs × 15 days = 600 labor hours per sprint) was refused.

If they would reveal their budget, we could have a more meaningful conversation on what they can get finished and delivered for that little dribble of money.

I think that PMP best practices are getting in the way of a successful software development effort.

Flickr, Innovation and Integration

Read this on Gizmodo: "How Yahoo Killed Flickr and Lost the Internet"

Compelling stuff: "Integration Is The Enemy of Innovation".

"[Corporate Development milestones] often completely ignore what made the smaller target valuable in the first place."

Lessons learned: it's hard to apply structured, formal, financial controls to innovation.  As soon as the accountants show up, innovation will be stopped.  Someone has to champion the freedom to innovate in spite of being part of a profit-seeking corporation.

More of Disruptive Technology Change

There's a cool infographic on technology change in FrugalDad.  See The Great Disruption: The Future of Personal Tech.  It's interesting and informative, but the few predictions it makes are not really disruptive.  You wouldn't see anyone lobbying against the suggested future directions.  They're all good ideas that leverage existing technology.

On the other hand, there's a great graphic that shows how disruptive technology is labeled as illegal.  See Infographic: Why the movie industry is so wrong about SOPA.

Consider just one example.  Digital Movies.  The DVD was so frightening to movie producers (or distributors or theaters or the whole supply chain) that discussion of circumvention of DVD encoding had to be made illegal.  That kind of industry legislative action is evidence that a technology is truly disruptive.

Disruptive change will often lead to fearful rejection and legislative action.

"But wait," you say, "no one tried to make the iPod illegal."  Correct.   The iPod is not the core disruptive change.  Digital music is the disruptive change.  The iPod is just a vehicle.  Apple is making their money by providing a platform for digital content.

If you want to know what the Next Big Thing is, look to the US Congress.  Lobbyists are trying to make some things illegal merely because they're disruptive.

Universal Health Care, as one example, is being fought against.  There are lots of specious and farcical reasons being used to argue against simplifying the insurance mess that has emerged over the last few decades.  If Congress is fighting against it, that means the following:

1.  It's disruptive.  Game Changing.  Terrifying.
2.  The old school companies are spending huge lobbying and campaign budgets to prevent change.  They are unable to adapt to a different set of rules.
3.  Some new school companies stand to be wildly profitable if the change ever gets past the Congressional objections.

For another example, read this brilliant article: How Ma Bell Shelved the Future for 60 Years.  This an example of internal censorship of disruptive technology.  "More precisely, in Bell's imagination, the very knowledge that it was possible to record a conversation would "greatly restrict the use of the telephone," with catastrophic consequences for its business. Businessmen, for instance, the theory supposed, might fear the potential use of a recorded conversation to undo a written contract."

You know it's disruptive when it's actively feared.

Bravo -- Iteration and Generator Functions

See this: http://nedbatchelder.com/blog/201204/python_iteration_presentation.html

Nicely done, very thorough presentation on some Python fundamentals.

The nature of iteration and generator functions is easily overlooked.

GE vs. Apple

Read this

http://www.forbes.com/sites/stevedenning/2012/04/25/david-brooks-competitiveness-vs-creativity-ge-vs-apple/

It's a brilliant analysis of innovation and creativity.