Never trust a developer who says 'I can fix this in a few minutes'

Project manager?

you mean the guy who writes the plan for how the software will work, who will write it and sets a thousand milestones, but thinks a "systems requirement" means which version of windows you use?

Trust

Never trust a developer who says 'I can fix this in a few minutes'

And never trust a manager who allows a developer to get into this situation and believes the answer too.

Just another day in the life

Just another day in the life of IT world.

You should see the project I'm working on now. Same old same old. The left hand doesn't know what the right hand is doing and the client is up to the same old trick of trying to sabotage the SLA.

Many days I wish I'd become a forest ranger.

There was a contingency plan!

" why the PM had not just gone for a back-out when it went wrong? That would have restored service, albeit on the old version, well within the change window"

I've been on projects (and in the middle of one now) where the main supplier has no concept of contingency planning, believing the best way forward is to simply burn the bridges and fight the fires as they arise. Current project is just such as case, the system was supposed to go live 10 days ago, well parts of it did - sort of, however,the client's Finance Director is starting to get shouty, as still she is without a functioning accounts system, something the main supplier was supposed to have ensured would not happen...

Being On-call was the worst job I ever had. 1 in 3 and like the scenario here really it is 3 in 3 as if the shirt really hits the fan you would have been expected to go in, what really frustrates me though was the bosses that didn't seem to realise you need a life too and it is a lot of pressure being on-call, even if you get no calls.

The best calls were from those clients which refused to pay for night and weekend cover but would ring up anyway because "the problem is so critical it can not wait till Monday"! Ok, first let me explain to your the concept of not paying for cover, we don't cover you. Usually I'd have a quick look at whatever their issue was but about 50% of the time end up telling them to jog on as the team which deals with their account does not provide a 24/7 service and I have no idea about their system. Also advising them if they paid for 24/7 cover then their account would be moved to a 24/7 team rather than the much cheaper office hours service. It actually costs to have us around the clock you know.

What a surprise

Just confirms my opinion of Project Manglers and the majority of developers I have had the misfortune to meet.

Planning in real life

I've had the misfortune, over the years, to be at the sharp end of implementing various IT projects with my staff. All coming from some bright idea of the people above.

No one had ever asked us what we needed.

No one had ever consulted with us in the planning stage.

No one had ever tested usability with us.

No one had ever sat with us and worked out when would be a good time to make the change over.

No one had planned a test programme on live data.

No one had ever planned for the contingency when the thing falls over.

And every single one then took months of work to make the thing useful ( if it ever did become useful).

And yet over the same period I was able to work with the engineers to implement a number of smaller projects that we had requested that they support. Some of which were then rolled out to other teams in a similar line. Making sure that those teams were similarly consulted.

And without causing disruption or pain.

Sales

Project Managers were, in my experience, people who were dropped onto you only to give you grief, provide you with charges that made no sense and never spoke to you but only told you things.

You'd get a PM for your 'team', aka yourself, after Sales had sold an application or project to a client which hadn't been designed or written yet. Sales droid would have been in the pub for a lengthy drawn out expenses paid-for marathon with client and have decided on the train home, pissed-up, what was required and when it was to be delivered. If there was an element of consultation then it would have only have been between Sales droid and PM over another lengthy pub session.

Then and only then would I hear about it. Of course a pretty chart from PM being the only form of project requirement and he having a near fatal hangover he wouldn't remember what was required to any useful level. The Sales droid would by now have oozed over to another client and all I was left with was a chart full of milestones and little clue as to what I was supposed to do.

I now work for myself.

Sales people

It puzzles me as to why in this day and age sales people are such a nightmare at promising the impossible to customers, I've seen it repeatedly throughout my entire 20+ year career to-date.

It p*sses off the customer, (and thereby reduces the chances of repeat business), it p*sses of the development team.

I suspect sales people are more interested in hitting their targets and getting their nice fat bonus.

Trust

"Never trust a developer who says he can fix it in a few minutes". Developers probably can fix it in a few minutess, but the developer is giving a time estimate of their work only and not thinking about the rest of the activities that need to be completed in order to make a release.

I'd still trust the developer, but it's my job as the project manager to give a realistic timescale and know all the other activities that need to be undertaken.

Simple install.

One of favourite "fix it on the fly" gags was a software upgrade that had gone through testing and proved to be a pile of poo in live. Many weeks of tweaking later all was sorted and the go-ahead for further rollout was given.

The developers had provided a nice, self-extracting, install, migrate and configure package that tidied up after itself. Trouble was, its only real run in anger had been the original "pile of poo" installation and much tweaking of its contents had occurred since.

The result was something where you pressed a button, it shat all over the environment and then removed all traces of itself (leaving only the thoroughly stuffed remains of the system) so you couldn't see what had gone wrong. Oh how we laughed......

Don't understimate managements ability to fuck up

I worked for a Japanese company some time ago.

There staff had gotten together (outside office hours) to write a hardware neutral systems requirement, including orders of magnitude for the various elements of the system. All they cared about was it got the job done, not what it ran on.

And then the the CEO played golf with CEO of a software house.

Game over. No requirements needed.

I've also cleaned up the mess of one of those "can do" coders, who can indeed "fix" any software problem in 5 mins.

Provided the PM schedules another week to fix the fix afterward.

Back out first. Then fix.

Spent a while in a similar industry.

General approach I used to always take used to be to spend 5 minutes or so doing some analysis, then if I didn't know what the hell was going on, revert to a previous version. Allows you time to do a proper fix and apply regression tests etc to ensure you're not even more in the shit than you were at the outage.

That said, I've also had enough angry PMs yelling at me at 11pm. Easier said than done when the shit's hitting the fan!

PM

Ironically I would love to have a decent PM at the moment, even one who bombards you with spreadsheets, project plans and conf calls to ask why you haven't done something. Some examples why:

We don't need those servers in that colo any more, decom them. 3 weeks later, we need severs in that colo, put them back.

We urgently need two servers in this colo, ASAP, this is really important etc. The servers are rushed in and then sit there unused for two months. And then it is decided one of the servers is urgently needed in yet another colo.

November, please implment a middleware setup to do X. It is implemented. Flash forward to April where they expect X to work instantly in production at a day's notice, despite the fact no-one ever tested it. They claim they did test it, but it was using boxes in the same subnet. So it didn't do any inter-colo stuff or pass through any firewalls etc which is where a problem surfaced.

To cut costs it is decided that in a colo we will decrease the amount of cabinets we're using. So someone goes ahead and decides on a date when the lease will end. All this is done without consulting anyone else on the how/when/who of moving kit out of those particular cabinets.

Being told that there are 40+ servers that can be decommed straight away as they're not being used. So we ask for a list... and 18 months later we're still waiting.