I read this article twice. I still don't have a clue what it's about.

is to create more consultancy.

In this case, the obvious thing to do was to agree, that these routines were complex and needed a lot of time to complete. .... Sooooo. how about hiring one or our people to help out with the workload. Your guy might take 40 hours to do the job, but ours are much more highly skilled and could do it in ,,,, oh, 30 hours?

Once in the door, your guy gets to do all the juicy work - like writing the code while the incumbent gets to do the donkey work, such as documentation and testing. Testing is a particularly good job to give someone who you want to cast in a bad light. Since it's pretty much the last activity in a programme of work, it's obvious[1] that if any delays happen, it's their fault. Testing also uncovers the problems. While we all know that the problems are really caused by crappy coding or design, it's always the messenger who gets shot. Soon the permie will be associated with all the bad things that are happening: delays, poor quality code, more delays and budget overruns. Meanwhile your guy whispers in the right ears that maybe the company really should bring in an experienced tester - and your consultancy happens to have one available ...

[1] to the management mind, who only works by what MS Project says

I find the least of my work is the actual technical fix. Mostly I am there to tread boldly where others have tread on eggshells to broach the unbroachable and name the unnameable to managers who can't, frankly, manage that drinking party in the place where they make the beer. 90% politics, 10% tech.

Interesting. Recently I was brought on at a biopharm company ostensibly to provide some analytics support while the regular analyst was out for a few months but I was subsequently terminated after about 5 weeks. The reasoning: There was such a huge gap in support and engagement processes between the group I was in and a support group that things needed to be fixed between top management. I wasn't quite sure if that was the truth but after reading your last sentence, I can see how that would be better broached by an outsider than internal staff.

What's the point of this article? That unionized thinking and fair HR practices have undermined managements ability to govern? That the company in this story had terrible management and was unable to fire someone.

What's the point?

Work in HR.

So wrong about Testers these days - we might get squeezed on timescales, but taking the blame? I think not....Testing is at the end of the day all about arse-covering, and a good Tester will make sure his arse is covered as well - thats why we have acres of documentation and many, many signoffs. Plus we're all evil :)

BTW Im talking about Testers, not the People Who Test that a lot of companies think they can get away with.

Seriously unless you know how to do a task, you have no clue if it should take 4 hours or 40 .....

I also think not sharing their suspicious with the consultant was the way to go. That way you get an truly unbiased assessment.

...

The interesting thing its its entirely possible that the guy who is overestimating the time requirements by a factor of 10 isn't lazy or incompetent.

He might have multiple area's of responsibility and multiple bosses ...... and he needs those 36 hours so he can upgrade patch security vulnerabilities or get the backup system working again ...

Then again he could be playing WOW all week.

I know people have been very creative with their time estimates for both reasons.

I think it's perfectly fair to quote that amount of time, but then i am a developer, although not with specific experience of what is mentioned.

I wonder if the consultant considered that most companies don't allow you to just go away and code things and ran his proposed solution by the company architects and then handed over a nice set of documents that had been approved by three or four people, all done within that 4 hours.

I think sometimes people forget that coding is just one small part, not the complete job. The truth is, it may only take 4 hours to code a change, but it could very well take a week to design, document, review/walkthrough (7 people in a meeting for an hour is a man day of work remember!) and get sign off before you're even allowed to start coding.

In my mind, no matter the size, any code change includes investigation, pointless meetings, technical meetings, arguing with whoever controls the budget that doing it cheaply is not the best way to go (every single time!), design, reviews, walkthroughs, actually coding it, unit testing, handover, test support, implementation planning & actual implementation (these last 2 are subjective based on what sort of project it is, i generally have to release code to hundreds of thousands of distributed clients without interrupting work. "I don't know what will happen if it goes wrong" is not a good thing to say).

All of that needs to be accounted for not just the coding time and I would hope that management were seeing this time as a whole and planning for it, or they are going to be in for a nasty shock when they just allocate 4 hours.

you were complicit in workplace harassment, took the cues from some guy in the corridor who didn't know how the system worked. And instead of saying that the system was cost ineffective due to HR and the Project Manager, you picked on the developer.

Normally developers underestimate the times, and consultants who don't have to do the work tend to estimate even lower, hmm, my guess is you caused problems, sure you weren't given the ramifications, but how much personal liability did you have in the efficient running of that system.

I will give the same advice I give to many companies, you want to get rid of a person just grow a pair and do it. All the cloak and dagger stuff does is build case for industrial tribunal, if you think someone is not returning to the business and contributing to profit just ask them to leave on those grounds, no business has to keep a loss on.

Sometimes the shoe is on the other foot...

I worked on a web interface for a while, and fixed it up pretty good; Some home-brewed AJAX, a dash of CSS and some third-party javascript stuff to tie the knot. However, they didn't like my GUI. I am not a graphic designer. I am however an old-fashioned systems developer with more x86 assembly skills than java, and I am more at home on the back end of things (developing my own AJAX library works OK, but designing a logo would result in a stick figure doing what appears to be a naughty gesture).

In short, I got the sense that they were a bit disappointed with my progress.

So they (at my advice) called in some professional web designers (slash ad-agency). My boss asked me twice (possibly thrice) to confirm the estimate, because it seemed a bit on the high side. But as far as I can tell, the GUI in question takes quite a bit of work. I certainly would not complete it faster... (to be honest, if someone supplied me with a proper stylesheet and the necessary images, I could probably cut some hours here and there, but not significantly) Besides, they had done respectable work in the planning stage (nice layout and ideas), so I felt they deserved the job. (and if they deliver the goods, the result will be worth it -- a small investment that will pay off tenfold)

Oh... that is probably worth some consideration: When we system developers help create a system, the payoff is usually substantial for the customer. We OTOH often get paid very little in return for our services... (why are the services of a movie screen actor worth more than our services?)

Is mainly a scapegoat so that senior management doesn't have to change their dysfunctional ways. Bring in consultant, conslutant finds something wrong, fire the consultant for having created the problem (because found = created), then declare the problem solved because the messenger has been shot.

Lather, Rinse, Repeat.

I've done several of those, and although it pays well, by the end of it you just want to strangle the incompetent, self-serving, pointy-haired bosses who keep doing it.

"D'Oh! Cough, please" should evidently be "Cough! Dough, please"

I remember a consultant mate of mine of a job he took once. He'd been hired by a certain international financial organisation for their IT "transformation" project. Turned out after a while that the bit that he was really needed for was to fly to a certain European city where said finance house had its home base and announce to the IT project staff there that all project work was being consolidated in London and that they were all redundant. The problem that required a consultant to solve was that none of the management had the required ovoid components in the trouser area to fly back home and do it themselves.

Was part of a team developing an in-house replacement for a wonky custom-built MES system. A "new MBA" was hired to lead the financial systems guys... and soon started poking his nose in everywhere. Didn't have a clue about technology, his rule of thumb was "if a corporation is big, their technology must be good". So he set about convincing the IT director that Windows was the way forward (this is in the days of NT 3.1/3.5).

Brought in some so-called consultant to look at everything and then say that "NT can do it". What a waste of productive time! This guy wasn't from the firm's regular fleet of consultants - he was cherry-picked to give the answers desired by mr "new MBA".

Fortunately the sotware we were doing was going to use existing hardware (HP unix boxes) - so just the operator stations went onto NT. Except they didn't - it couldn't cope with running Oracle Forms and an X server and two screens all at the same time.

So, often consultants are brought in to whitewash management's preconceptions.

There are also a lot of consultants that are a walking health risk - the dodginess of the system we were replacing could be directly traced to the inaccurate and incomplete specifications produced by consultants from a well known accounting firm that sounds like sanitaryware.

There are often cases where the conclusions of a consultant are the same as those of the staff - however as the advice of the consultant cost a lot more the management are more willing to listen - Money talks

I implemented a monitoring system with some very loud vocal disagreements with the manager concerned about how it should be configured. While I was away on a course, he brought in a consultant to review my implementation and write up a report.

Unfortunately his report completely vindicated all my decisions but one (where he didn't like what I called something as it was a little vague - fair point). How do I know this? The other Sysadmin at work snuck me a copy of the report, which ended up getting buried in "R & D", along with the 3 grand it cost to engage this guy.

Fair cop to the consultant, he gave an honest and accurate report and didn;t deliver up any ammo. But if he had, I would have been down the dole queue pretty quick.

Good point, I actually find that the most important code to write is appreciated about as much as a wet handshake. Stick a banner on it though and something that moves and "ooohh"

Its fucking pathetic.

As someone who has worked as both employee, and consultant, I know many of the tricks involved with this kind of work.

At one place where I was an employee, I was part of a small team looking at implementing Active Directory, on a world wide basis.

We realised that the policies we would need to implement would not go down well with some parts of the business, and some members of the IT staff.

Managements solution was to bring in a group of consultants to review and implement our AD.

This let us off the hook in their eyes, but the small group were more than willing to do this ourselves, and would have been able to talk to the parts of the business rather than just dumping on them from a great height.

From the consultant side of the fence, I was brought in to rectify a lot of basic problems found on a very high profile project. It had been implemented as part of a sponsorship deal with a large consultancy/outsourcing company. To my eyes, they had carried out the implementation with the minimum of financial input, and deliberately made fundemental mistakes, so that they could then come back later and charge for putting the problems right.

Specifying PC's running NT4 with 8MB RAM was never going to work, just as backups once a week to a single tape would never have worked. They also specified fibre equipped switches, and had fibre installed, but then used Cat5 running at 10MB to connect them together = Cheep upgrade, due to using kit installed during the build phase of the building, rather than retro fitting it.

Sounds like you need to look into the Agile methodology - it will be difficult to sell, initially, but the benefits are huge.

The REAL WTF is that...

Oh, hang on, sorry, wrong site...

Too true, spent 4 years telling the company (along with the rest of my team) to implement a proper data warehouse solution, which got ignored. Then they hired some consultants to do it for £4M.

Irritating, especially when the database spec's and the ETL jobs were all written by the team that had been trying to get this done for years.

As others have said, though, good coding takes time and effort - I remember going 50% over-budget on a project many years ago. Lots of complaints from management, got shat on for my performance review and bonus. That same code is still running today, 12 years laterand hasn't required any maintenance or adjustments due to changes elsewhere, as it was written to cope initially. Don't get any fucking thanks for that, though.

Since the author does no seem to engage with the bloke at the company to see if other factors made him set such a time to develop anything, e.g. other work, bad change management or continual changes to requirements, this comes across as a massive willy waving exercise by the author saying "look at me I'm enormous".

Excellent response. Thx.

The Project Manager now is pushing the developer to finish things with no slack whatsoever. Granted the developer was abusing the system before, but what will happen, in my opinion, the developer will soon leave and the company will struggle to find a replacement resource.

The Project Manager now is typical, and he's much more optimistic in allocating tasks to this developer, and that's a risk. (check this article, http://www.pmhut.com/the-art-of-scheduling for more on this issue).