Lying Liars

Ok, so The Job has me working for a manager, and he's hired a Project Manager contractor (some time back, I'm just setting the stage)

Recent corporate bullshit has led to a requirement that everyone be working on funded projects.

So my manager has decided what percentage of "work' everyone is doing on his funded projects, for the next few months.  To be fair, he's keeping everyone on paid-for work, so it's a good thought.  But b/c of this, the PM is asking me what tasks can be given to the 2 devs who are not really on our project to cover the percentage of time they are supposed to be working on our funded project.

So to assuage his conscience and not lie, he wants be to invent work for them, even if they really have no business working on our project (b/c they have no context, not for any skills issue)

I hate this bullshit

Really Stupid Corporate Policies

Ok, The Job has really pissed me off this past couple of weeks.

They have a number of policies intended to protect company assets that are just plain useless.

#1 - only staff with "developer" in their title are allowed admin access to code repositories, despite a number of projects where the entire development staff has been on a revolving door, and only the manager is a continuous presence.  But we can't have one of the non-developers controlling access, can we?

#2 - despite a growing number of contract staff, several tasks can only be done be a full-time employee, which means that *I* get stuck with setting up those tasks for our projects and a couple of other groups'

#3 - Several tasks need approval by some specific level of management, and by 'specific' I mean exactly a certain level in the food chain.  Not "at least a 2nd-level manager", but "only 2nd-level manager, not 3rd, not 4th, etc"

SSDD, Agile Misunderstandings

So the latest job is moving to Agile.  They've got a nifty all-in-one Agile tool set up, with the usual problems such things involve.

But the real fun is that people are writing user stories who have no idea what the technical people on the team are doing, and without asking them at all.

This is driven by the mandate from On High that everyone will be doing Agile ASAP.

So we stumble along, as the uninformed are filling our backlog with items that cannot be broken down.

And the best - the tool training uses a team's per-iteration completion of story points as one of the metrics.  IOW, they expect every team to maintain a high rate of finishing business value. 

That won't have any effect on the estimation process, nosireebob.

Like Neo in "The Matrix"

...I dodged a bullet with panache yesterday.

A couple of weeks ago, I got an email from Blizzard, asking if I was interested in a position there.  I said I was at least interested in listening, so a phone screen was set up for yesterday.  And on Friday, I read in the trade press that Blizzard is rumored to be planning a significant layoff by Feb 12.  So I take the call on the 11th, and the recruiter was totally silent about the layoff.  But since they are not at all remote-work-friendly, the interview was pretty short.

It's like working for Jello

So, about 2 years ago, I was asked to spin up a web interface for some data our project produces, to interface with another project.  They had a lot of hidden requirements, and turned out to not have a viable business case, so they went away. 
In the interim, I had to maintain this interface, modify it every time our intermediate communications paths changed, handle the massive increase in data volume, etc.
When another tool dropped export support, my boss looked for a replacement that was found in another project he manages, and the lead of that project suddenly was really keen on developing a replacement for the web interface.  And my boss was falling over himself to say we would switch to that interface. 
Fast forward to yesterday when we were meeting to finalize some details, and it suddenly becomes a bake-off. We have to run some tests and list pros & cons.
Then today, it becomes back to using my interface, until the other guy mentions some things, and the pendulum swings back that way.

Basic Technical Competence

Most companies have a mix of skillsets needed in the employees, and so you end up with the technical folks doing technical work, and folks managing them, who are typically less technical.  But there is a basic technical competence level that needs to be maintained, or the managers end up wasting everyone's time with bad ideas.

Case in point:
Our application generates a ton of data.  So much that the clients need to be in the same datacenter to get it at the rate we produce it.  The remote datacenters do not have enough incoming bandwidth to receive the data in a timely fashion.  One day we were discussing this problem, which limits the locations of our clients, and one of our project managers suggested "Why don't we just use the cloud to get it to the other datacenters fast?"

I mean, ya gotta have the basics in your head to play the game right, y'know?

Doing the absolute minimum is A BAD FUCKING IDEA

This blog has become my vent for all the crap from The Job.

Ok, so we have a system that sends data into a central routing system, built by another group.  In order to be able to prove that any delays in the system are not due to our system being behind, we have a subscriber program that reads the data and checks transit time.  Because that project may get moved to other servers, we wrote a minimal subscriber to output just that info.

Cow-orker is tasked with writing the script to analyze that program's log files to track the time.

He write a program that expects every message output to be the one with the data he needs.  Absolutely no filtering by content at all.  So if we alter that message, or add other messages, that script will fail. 



All it would have taken is to filter for the 2 words before the data value to guarantee that only relevant messages would pass into the script.  But No!

sheesh.

I really wonder about people sometimes.