Customers don't want cutting-edge stuff
But they still want cutting edge results...
Adi had posted about my recent series of posts about getting the best tools for the job.
Guilty as charged about the suggested. I argued that that we can get better productivity and higher quality, at the cost of having to train developers that we pick off the street. Adi think that I am overlooking the cost here:
I would like to refer to this post for backup. There is a tremendous amount of effort already invested in the tools. This means that I wouldn't have to build it myself in order to get the functionality that I need. Hell, something as simple* as MonoRail's [DataBind] can drastically reduce the amount of code that you need to write and maintain.
At the end, the job has to be done, and insisting on trying to do it via custom code is simply NIH. There are cases where I say that whatever exists out there is not going to work for this scenario, and I roll everything from scratch, but to get to the point where the official policy is "either Microsoft or hand-written stuff, nothing else" - which was an actual statement made by a client to me is a long shot.
About training, I do not think that it is too much to invest three days to a week in giving a new guy a chance to learn all the stuff that you are using. I had to bring in three new developers into my projects, none of them had any previous encounters with any of the technologies that we are using. All became productive in a very short time, one of them is exteremely annoying in managing to find the wierdest corner cases in NHibernate. They are all good developers, but I never even thought to ask them about whatever they knew about any of the stuff that we were using.
As an aside, I keep talking about the first steps of interviews, because I stop so many interviews there, but one of the things that I do in an interview is find out what the candidate doesn't know, and have them write something trivial with that technology. For instance, one candidate didn't know GDI, so I asked him to draw a line on the screen.
One of the worst candidates that I interviewed was someone that actually had NHibernate experiance, he was one of those that could not reverse a string...
* Simple is defined in terms of usage, not implementation, the data binder is certainly not simple.
Comments
I think you meant couldNOT reverse a string right?
Yes, sorry, fixed.
Maybe he knows Ruby, so he only knows how to do:
"Hello World".reverse
Enjoy :P
Oren,
What you do have to realize is that that's 1 manweek of your time you spent, 1 manweek that they (the client) might not be willing to give you, and 1 manweek that they might not be willing to give to their existing and subsequent developers. Likewise, when you're gone, how will they be sure that they can replicate the quality of your knowhow?
I understand the merits of your arguments, but we do have to work around the parameters of the real world, and a big chunk of the real world do not appreciate OSS productivity tools, or refuse to specifically because they are OSS.
They may "work stupid" in your perspective, and at least in theory I agree with you, but in their perspective they're just being pragmatic.
That was "my" man week that I estimated, that was a general estimation for most developers.
In general I am building big systems, which mean that you simply can't just sit down and start hacking at the code without a guided tour first anyway. This mean first understanding the business domain, then understanding the approach that we took to solve the issues, and only then understanding the technology.
"a big chunk of the real world do not appreciate OSS productivity tools, or refuse to specifically because they are OSS." - Yes I know, I simply think that this is the wrong approach.
For a developer it's much more valuable it's capacity to learn new things than what he knows already. So if you are hiring for what he claims to know instead of how fast can he learn, you are in trouble. That's a major cost.
@Eduardo,
That is a very good approach. I am going to use this argument in the future.
I agree that a good developer should be able to learn new stuff quickly, but not every developer has that capacity.
And sometimes you also have to work with that kind of developers...
Ok, so it's the quote of yesterday - i'm a day behind and I have two of them from The Same Post. Ayende...
Comment preview