Fog Creek Software
Discussion Board




Confusing Job Specifications

In the continuing theme as to why its so hard to marry the right individual to the right job...

I was just rung by a recruitment agent looking for someone to fill a long term contract.  She read out the requirements emphasising the need for detailed experience in Java and Swing, at which point I stopped her and said since I've always rejected Swing for projects and I don't want to be out of the country at the moment that I would disqualify myself.

Then she went on to ask me if I knew anyone else (as per usual), and so I asked her a bit more about the specification and she read out the rest when it became obvious that they wanted someone to design the architecture, document and integrate blah blah...

I pointed out they were looking for two kinds of jobs and yes someone that does both development and architecture would fit (hey, I do that), but that if they're looking for an architect but they're only interested in specific implementations that they'll get inundated with the wrong kind of applicants, and actually it sounds like the 'right' kind of applicant would steer clear because all the critical architecture decisions had been made already.

None of this was the agent's fault.

Simon Lucy
Monday, May 19, 2003

I often get the feeling that if you ask them really closely, clients will admit to their methods...

"So, you have no-one in the building who does IT?"

"No."

"So how did you decide to do this project in Java?"

"Well.. Maureen-who-answers-the-phones[1] has a nephew who's at university[2] and when she asked him what languages he'd heard of, that was one of them."


Actually, I think it's enourmously disrespectful to turn up and be told what tools to use by people who can't tell them apart. Companies seem to have this trouble with hiring a professional IT person and letting them make the decisions.

I sometimes wonder if other people have this issue; Maybe these companies do hire a plumber and then won't let him use solder because they have this plasticine that should be fine instead, after all the salesman said it would...


[1] There's always someone known like this.
[2] And therefore is emminently qualified.

Katie Lucas
Monday, May 19, 2003

Actually, I think that 'architect' has somehow replaced that other impossible committee animal, the analyst programmer.

Simon Lucy
Monday, May 19, 2003

The standard language at Camel is VB.Net. Why not C#? Because all their developers knew VB6 and they wanted the language that would be easier for their installed base to learn.

That should've told me everything right there, really.

Philo

Philo
Monday, May 19, 2003

I guess the first question I might have thought of about Camel was why .Net?  It might be a reasonable choice but in that application it seemed an unnecessary choice.

Umm well a premature choice might be a better phrase as they hadn't managed to scope it properly

Simon Lucy
Monday, May 19, 2003

"Because all their developers knew VB6 and they wanted the language that would be easier for their installed base to learn."

Looks like perfectly reasonable decision for me.

Alex R
Monday, May 19, 2003

I've been on the flipside of the hiring problem you state at the beginning of the thread.  I was at a company as a java developer where we had a group of good developers who functioned well as a team and had already selected an appropriate architecture and begun construction.  THAT is when an architect position was created and filled.

WHY?

Internal politics.

A falling out between the Director of Technology (my boss) and the President of the company had led to the creation of a VP of Technology position, filled by someone loyal to the President.  An extra, superfluous, layer of management created entirely because of a personality conflict. 

The VP couldn't get anything he wanted done because:
1. He was generally incompetent.
2. All of the developers knew this and were loyal to the Dir. of Tech.  We would nod our heads at what the VP said in meetings, then go build what the Dir of Tech told us to.  Really, it was the only way to actually get anything BUILT.

The VP created the unneeded architect position and filled it with someone who would be loyal to him to get some control over what was being developed.  The developers now had two people that they would nod their heads at during meetings, but otherwise ignore.  The architect eventually ended up doing a several month project to come up with a new package structure.  And another project to pick a logging framework.  Busy-work that was created by the Dir of Tech, sold to the VP and dropped onto the architect to create the illusion of work for the two of them and otherwise keep them away from the developers who were getting some work done.

Unfortunately the marketing types changed what it was the software (and company as a whole) "did" on a near weekly basis.  We managed to get 3 customers in 3 years.  With VC funds running out, the CEO bailed on the exact day that his 18month non-compete agreement with his former employer expired, and the company folded (just over a year ago).

Ken Klose
Monday, May 19, 2003

---"Because all their developers knew VB6 and they wanted the language that would be easier for their installed base to learn."------

Why bother learning a new language in the first place. Why not do it in VB6?

Stephen Jones
Monday, May 19, 2003

Because you can do a lot of things in .NET without trouble that were either a pain in the rear or impossible to do in straight VB6.

I remember having quite a few of those "it can't be this easy" moments when I first started with .Net.  Usually I was wrong, it was that easy.  But, sometimes I was right.

Steve Barbour
Monday, May 19, 2003

But if you remember the Camel project Steve they only had six months to implement it; they were told they didn't even have time to interview the users!

Yet they were asking everybody to learn a new language!

.

Stephen Jones
Monday, May 19, 2003

Well, uh yeah...there is that I suppose.

Actually, I can see a case for it going either way, depending on the developers.

Personally, I haven't found VB.NET to be that difficult.  It took me about two weeks to get to the point that I was productive with it.

Is what I'm writing the best code?  Probably not, but it works and is at least as readable as VB6 code.

But you're probably right, if they were going to pretend to hit the 6 month schedule then they should have stuck with VB6.

Steve Barbour
Tuesday, May 20, 2003

*  Recent Topics

*  Fog Creek Home