I Demand You Use Metric Wrenches!
From Zanecorpwiki
More often than not, the clients I engage with come with a pre-determined technology stack. I don't have a problem with this, and in fact, I consider it one of my strengths to be able to adapt to both new technologies as well as deal with the fallout of bad technology choices. So as far as I'm concerned, pre-determine away because I'm going to charge you for it.
Sometimes, there's good reasons for this. It's an existing project so of course there's baked in technology. Even on new projects, maybe they have some in-house talent that's not so adaptable so it makes sense to conform the technology that limitation. I understand there are plenty of good reasons to push towards one technology that have nothing to do with the products technical requirements.
As often as not, though, there is no reason why the technology should be pre-determined. Nine out of ten of the completely new, virgin territory projects I come across are describe as: "We want to build XYZ app in Rails" or PHP, or Java, or whatever. I find it both amusing and useful because when individuals who have never written a line of code in their life describe the tools that should be used to build software, I know know two things:
1) I'm going to mock them in my head, and that's fun.
2) They'd be a terrible client to work with an I'm glad that they've given me this clear signal at the outset.
PHP, Java, Rails, etc. are all just tools. Demanding what tool a developer should use is no different than going to your mechanic and saying, "I want you to fix the knocking sound in my engine. And by the way, I demand that you only use metric wrenches to do so because I think the metric system is better." Now, it's likely the mechanic will still be able to fix your car, but it's also clearly clearly a stupid idea to insist that he use the wrong tool for the job.
But when it comes to software, everyone's read or heard or been told something about how XYZ technology is the bee's knees, and so--despite having no training or experience necessary to evaluate the claims or assess applicability, nor even the basic understanding of what's being discussed--you get requirements that include what amounts to a random selection of tools. I'm not entirely sure why this is.
Clearly clients often see themselves as "project managers" and developers as menial workers and so they feel that specifying the tool set is part of "managing the project". Many developers are just menial workers, so I can see reasons for why this came about. What isn't so clear is why everyone knows the difference between a doctor and a nurse but not a software engineer and some guy that read a book on PHP. This dynamic exists in many professions: architect and construction worker, master gardener and guy with lawnmower, financial strategist and accountant. It's not necessarily surprising that the average Joe doesn't realize that there are engineers and there are code monkeys, but why is it that otherwise smart and mature business people make this mistake?
Maybe it's down to the culture itself that sees the ideal developer as capable of both design and code and tends to look down on the "pure architect". That seems like a part of the dynamic, but how that translates into the client whose understanding of software is literally non-existent thinking they should take on vital engineering questions is not 100% clear.
