Slashdot Mirror
Same Dev Tools/Language/Framework For Everyone?
AC writes "Upper management of the company I work at recently declared that all new development should be done with a single combination of development tools, language, and framework. The main rationale is that people can be relocated from one group / project to another faster, because they don't need to learn a new environment when they switch. Of course the chosen language / framework used by everybody does not need to be the best tool for the job, but it should be good enough to allow every project to get done. What does Slashdot think about this? Is it OK to use the same development tools and language for every project, instead of choosing what fits best? Will the time saved be sufficient to offset the time lost to the 'not the best tool for the job' environment developers will be forced to use?"
Sure, and while they're at it, let's give all the mechanics just one size of wrench and screwdriver.
This policy shows a gross misunderstanding of the engineering process, and of what computer science is. Any computer scientists worth his/her salt should be expected to learn whatever tools are needed to get the job done. And conversely, each project team should be free to evaluate the best tools to get each job done.
It's not unreasonable to have guidelines and even strong recommendations; for example, a company could discourage csh scripts in favor of bash because of the known problems with csh. But to think that C/C++ can substitute for a scripting language or vice versa, or that even a language like FORTRAN has no purpose, completely misses the point.
When I was at Stanford, we got ZERO units for learning different programming languages. We were EXPECTED to learn C, C++, Lisp, and about a dozen other languages, before we could call ourselves computer scientists. If anyone thinks that limiting a computer scientist's choice of tools is a good idea, you should kick that manager to the curb.
Seriously get out your resume and start updating it. Once management starts treating all programmers as interchangeable is the day that all things start going to hell. Programmers are not interchangeable, and all languages are not interchangeable. I sure hope you guys don't do anything that requires AI or if you do I sure hope you don't do anything that requires graphical interfaces because you are screwed either way if you need to pick one language.
I am sure we could all make due building every road out of steal, but it would certainly be a little expensive, because if we need to build everything out of the same material because all road builders need to be interchangeable, than we would never be able to build a bridge over say San Francisco Bay with using stones...
We were all warned a long time ago that MS products sucked, remember the Magic 8 Ball said, "Outlook not so good"
It depends on how varied your projects are; if all you ever do (as a company) is produce slight variations on a single theme, it should go fine. If you need to develop everything from hard real time embedded apps to web 2.7 social networking goo, you're screwed.
--MarkusQ
27 years experience and I've heard this idea before. It is dumb.
2-3 languages- sure. One for gear-head, one for report/data mining at least.
5 languages at the same company is a problem- but 1 language is a problem too.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
Languages are just details. It's far better for developers to standardize on a set of processes - documentation, as-builts, code review, unit tests, TDD, scrum, FDD ... pick a set of development processes that make sense for your company and project. Some methodologies always make sense - if developers write clear, concise docs and as-builts for their set of coding responsibilities (yeah, right :rolleyes:) then a good developer can pick the code up and run with it regardless of the language.
Language is just syntax. (OK, it's mostly syntax :p) But the primary point is that most developers have had a wide range of language exposure. I don't know Ruby nor Python, but I've done a helluvalota PERL, JavaScript, and C/C++ and it'd be fairly trivial for me to pick up a well documented Python app and maintain or extend it. Just give me a good O'Reilly book. It takes longer to figure out what the actually code is doing than to understand the syntax and semantics anyways.
to pronounce my name, I would have to pull out your tongue...
Whoa, whoa, whoa! You forgot the most important thing: source control!
Perforce is probably good for larger companies, while Subversion or Git should be good for small/medium companies.
Project management tools: version control, bug tracking tools, etc. Are important, and should be mostly standardizable without impacting upon any project.
These are supporting tools, but your version control system is not a development tool like your compiler or IDE is. (It's more of a development tool like Visio for making your UML diagrams or Word for making your documentation is).
Adjunct tools are all readily standardizable, and useful to standardize (everyone uses Visio or uses DIA, or Poseidon -- so everyone can read your files), just stay away from the language the code is written in and the exact tool used to type it.
It makes sense, even to use a common repository for all projects, and one private web site to track bugs for all projects (divided into their own categories/administrative domains, of course)
Just don't standardize on windows-specific tools like VSS or SG if platform development is mixed (I.E. some software needs to run on other platforms), or use version control that has to be IDE-integrated.
Unfortunately, many developers rely on their IDE like a crutch and need it to be able to build things for them.
They are particularly fond of tools like Visual Studio that try to do everything, even decide how building will work
Build processes are inherently project-specific and depend on which files need to be compiled and which libraries need to be linked.
Builds are not much more standardizable than choice of language.
But should be standardized for each project. I.E. Everyone working on a project using language X, should use the same compiler, so developers will have consistent results.
And there should be standardized (non-conflicting) build tool installs for various projects that use build tool X, so again, there are consistent results when different developers attempt to run a build on their workstation.
Look for another job. When upper management sticks their nose in with the rational that you described, doom is just around the corner. The problem is simple. How do you get the best performance out of your best people? The answer is not: Fit them all into the round hole. The correct answer is: Let them use the best tools possible as they perceive them to be.
Okay, languages need to be standardized, but after that, the environment needs to be perogative of the developer.
Nuff said...
Beware the wood elf!!!
WTF is this crap of "any team member to move from one workstation/area of work to another"?
If someone is good at something, ferchrissake KEEP THEM THERE!
There's nothing more devastating for a developer than to be ripped out of context and forced to learn something entirely different, but just as difficult, just because some braindead accountant thinks all developers are alike.
Please stop that. I think it has a more than measurable impact on productivity, not to mention staff morale.
Translation: everyone who thinks programmers are interchangeable should go fsck themselves with a chainsaw.
1. Slashdot might as well think that you should be able to use anything interchangeable enough not to make a difference in the long run. Emacs vs. vi comes to mind.
2. The people who sign the paychecks hired you because you know what you're doing, not to be an interchangeable code monkey in need for micromanagement. (Right? If not, RUN!)
3. If you don't "force" the devs to use tools they hate, this is not an issue. If you do, there is no "time saved" to speak of, and management can do nothing about it.
First of all, it's a pile of shit and it stinks.
I can show you two programs written in Java that are so different that you wouldn't know it was the same language if you found them in the wild. As remarked before, switching languages is almost never the problem.
The problem is that developers in different divisions are not interchangeable like parts in a machine.
Newsflash: developers are not interchangeable.
If you hire and train in a smart way you might get developers that are smart enough to deal with somebody elses messes and that leave messes that can be dealt with by somebody else.
The first thing that a developer will say when he starts at an existing project: "This should have been done differently, using language Y, framework X. This is a pile of shit!" (Y and X varying among developers and over time). Doing everything with language Y and framework X doesn't fix anything though, because they are in constant flux.
Newsflash: projects are not all the same.
If all your projects are the same you should come up with a way to let the business owners roll out variations on the theme and get the hell out of there.
The interesting bit about writing software is to learn the domain and find the programming model that works best there. Then simplify it until you're done.
This is not to say that developers should be allowed to try anything new. Reducing the choice a bit (dare I mention web frameworks?) makes a lot of sense. Eliminating all choice is just plain stupid.
If you dumb down the organization by eliminating evolution of the programming model and robbing the developers of the freedom to do what makes sense, you will see the smartest developers walk first. The next thing you will see is a huge drop in the rate of change in the products and the responsiveness to the market. The last thing you will see is lawyers.
Show a man some news, distract him for an hour. Show a man some mod points, distract him for the rest of his life.
"Management standardizes that which they do not understand, to relieve them of the responsibility of having to think about it any more..."
dave