Same Dev Tools/Language/Framework For Everyone? 519
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?"
Choose them all under one. (Score:5, Interesting)
We frequently encounter this issue with our clients (government, military, and commercial). We know that this can be a very bad thing if they capriciously apply it across the board. What we have recommended allows for the most flexibility, while minimizing the "tools". In order of importance.
1. Cygwin (0$)
2. Eclipse (0-250$)
3. Teraterm (0$)
4. Adobe CS whichever (900-2500$)
5. Microsoft Office 2003. (400$)
This would allow any team member to move from one workstation/area of work to another without too much effort.
As to the language, we recommend that one be chosen for "prototyping/scripting" and another for "enterprise" development.
With Cygwin you get the CM tools, build tools, perl/bash/etc. (Already included tool set under Mac/Linux/Unix...) With Eclipse you get every thing too. (works on all OS) Teraterm nice term, just don't like putty myself. (not needed outside of windows) Adobe for those that like spending money. (Mac/Windows) Office, they are going to buy it anyway.
Re:Choose them all under one. (Score:4, Interesting)
Re:Choose them all under one. (Score:5, Funny)
If it's big enough you can rely on picking the right tool for the job... developers simply chose the tool and compete based on who can implement the software best measured by customer satisfaction reports, rather than bugs or performance. Rather than directing outcomes we foster a system based on evolutionary theory. Developers are pitted against each other, and the weak developers get stabbed or maybe scalped. The Head Developer wears a necklace of threaded ears and walks around the office taking his share of the women and of food and clothing. Every night a fire burns and the drum beat calls developers out to compete for their very lives. Generations later Alpha developers will rise to feast on their flesh, crush our enemies, see them driven before us, and we will hear the lamentations of their women.
This will really only work at large companys though :(
ps. Hi gordon in #jelliffefans...bring your A game!Re: (Score:3, Funny)
>Developers are pitted against each other, and the weak developers get stabbed or maybe scalped. The Head Developer wears a necklace of
>threaded ears and walks around the office taking his share of the women and of food and clothing. Every night a fire burns and the drum
>beat calls developers out to compete for their very lives.
So Intel hasn't really changed at all?
I wish (Score:3, Interesting)
In our dreams.
In this reality, the alpha developers get fed up after a few years and find more interesting and/or lucrative work elsewhere. Or they just feel it's time to move on since they aren't learning new stuff (read: remaining competitive) because somebody higher in the food chain thinks you should leave developers in place once they've become the experts.
The deltas, on the other hand, know they have it pretty sweet since they won't get canned unless they really screw up or there's a layoff... and the
Completely Off Topic... (Score:3, Interesting)
crush our enemies, see them driven before us, and we will hear the lamentations of their women.
I know this is completely off topic, but you would be amazed at how many people don't know what the word lamentation means. My son's name is Conan, so as you can well imagine people are regularly quoting the movie at him. 9 out of 10 people will either mumble out the word 'lamentation', or outright apologize for saying it in front of a small child. Not for the quote, but for the word 'lamentation'.
Re: (Score:3, Interesting)
How bizarre, I've never even heard of this. What do they think it means?
Re: (Score:3, Informative)
They may be using a 3rd party commercial Eclipse package like MyEclipse.
Re:Choose them all under one. (Score:4, Informative)
Even a free tool has a TCO. We use Eclipse but we have a team who support it (as well as numerous other tools) in our environment. They do things like setup/configuration, installation, investigating new plugins, developer support, etc. I don't think it amounts to a significant amount per developer but it is a non-zero cost.
Re:Choose them all under one. (Score:5, Insightful)
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.
Re: (Score:3, Informative)
So yeah, perforce doesn't give you much over SVN with a small/medium dev team, but you do start noticing some short-comings, and little quirks with SVN when you start working on larger projects. e.g. Branching and (especially) merging. I'd definately go with perforce for a large scale project - if only for the relatively pain free merging....
Re: (Score:3, Informative)
We use perforce here. I've been using it for about a year now, and honestly, the benefits of it must not be at the end user level. It's substantially the same as SVN, CVS, etc. I suspect the advantages are at the administration level (reorganizing, branching, merging, etc).
From a user perspective, it actually feels like a step backward from the old standby, CVS. It requires you to "lock" a file before editing it, and often seems to lose track of what files you have "checked out". It also seems to have
Re:Choose them all under one. (Score:5, Informative)
[..] I suspect the advantages are at the administration level (reorganizing, branching, merging, etc).
Having gone from an svn shop to a Perforce shop, I can definitely say that branching/merging is much easier in svn than in Perforce. Also, the whole "client" concept is a bad alternative to file system state files (i.e. .svn or CVS directories).
I'm not saying that using the filesystem is the best alternative possible, but it's the least worst right now.
Re:Choose them all under one. (Score:5, Insightful)
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.
Comment removed (Score:5, Funny)
Re: (Score:3, Informative)
If someone is good at something, ferchrissake KEEP THEM THERE!
I see that finishing a project appears to be a foreign concept to you.
-jcr
He's a maintenance coder, apparently. And likes it.
Re:Choose them all under one. (Score:5, Funny)
Re: (Score:3, Insightful)
MEMO
It has been brought to our attention that in our company
jewelers, stonemasons, blacksmiths, framers, joiners, bricklayers, welders etc
all use different hammers.
This cannot go on!
From now on everyone will use the Craphammer 1.0, so transfers between groups will be much easier.
The Management.
Re:Choose them all under one. (Score:4, Funny)
Re:Choose them all under one. (Score:4, Interesting)
My first guess is that he may work for an accounting and or payroll function and he might not be suited for a training department or operations programming. (or vice versa)
Were I work there are several different departments all with different programming needs. It helps to know some intimate details about accounting in order to give them the right tools to do their jobs. It would also be a pretty steep learning curve for that same developer to put their accounting knowledge on the bench while being tasked to write a program for the operation of the company. Without knowledge of the processes that go on in the operation, they will likely create software that's useful, but not very elegant or meaningful for the front line supervisor that needs to update numbers.
Where I work, they have a dedicated development staff, and the projects they roll out are very well planned, organized, and managed. Unfortunately though, there are some things the operation needs and wants in short order that would help them perform better and they can't wait for a full 2 year project plan and all that. That's where the fun happens. It used to be tasked to some poor supervisor or someone that might be a hobbyist programmer in an area to create something in Access to get them their numbers or perform the task of training someone... yes, they would train people with Access because that's all they had to work with.
Recently though, there has been an upstart of a group that handles "mid-level" operational reporting tools and rapid development tasks in order to take on these one man projects and try to standardize them across the company instead of having 80 odd programs in different states and countries doing the same things (frankly wasting time solving the same problems all areas face.)
Is it the best solution? Probably not. But it's been working. The "start up sub group" has been able to quickly roll out applications (web apps in this case) to the field so they can perform their job easier and more efficient. If they run across something that requires more development, it's pushed up the chain to the dedicated development/systems teams to do a corporate assessment. There's something to be said for project planning and all that, but sometimes it's ungainly slow and cumbersome. In this small group, the developer is usually tasked with talking to the requester, laying out the design and functionality of the application with the user and coding it up on the framework in place. Granted, it's a lot of work on the developer, but they gain a knowledge of what the field needs and can better layout what that niche of the company needs to do it's job in a rather short period of time where the common standard project time line for the dedicated team of developers would take way too long to gather that knowledge, lay out a plan, and code the application.
Re:Choose them all under one. (Score:5, Insightful)
My first guess is ......
That being the main problem with this entire topic: He has not provided enough information about what his company does for us to come up with a sensible answer.
I can think of some cases where forcing everyone to use the same tools would be ridiculous. I can also think of some cases where it would make sense. Without knowing how big his company is or having any idea about the longevity of each project or how different each project is we have no idea what makes more sense for them.
As far as we know he is talking about two teams of 3 developers who interchange between similar projects on the same web application. He also might be talking about a company of 1000 developers for hire work in long term projects where each team develops an entirely different application. In the latter standardising on a single language would probably be impossible.
Re: (Score:3, Interesting)
If someone is good at something, ferchrissake KEEP THEM THERE!
I see that finishing a project appears to be a foreign concept to you.
-jcr
Project != Product
Obviously one will finish work on a particular software release, and move on to the next one. But there are usually multiple product lines within a company, and the infrastructure for each can be dramatically different (even using the same tools/languages). It can take weeks to get up to speed, not to mention working your way into a new team dynamic.
IMHO the grand-parent is talking about switching product lines, which is clearly what the original questioner's company is contemplating when
Office violence (Score:3, Interesting)
If someone is good at something, ferchrissake KEEP THEM THERE!
I see that finishing a project appears to be a foreign concept to you.
And I see some members of the upper management haven't been beaten enough with the "Mythical Man-Month" book [wikipedia.org].
Developers aren't a commodity resource you can happily swap around.
Re: (Score:3, Informative)
Woosh, you totally missed the point.
He's saying that programmers will need to move on to something else once the project is done. You know, when there's nothing much else for them to do? When the project's finished?
He's not saying that the company should be shuffling people around different projects all the time.
Reading is fundamental.
Re: (Score:3, Insightful)
The company I work for has an extensive set of systems. As a systems architect I like to know that for any new project I can go to the developers in that area and get advice on how to design and implement the project solution, whether it affects them and how they woudl design their part.
I rely on knowledge growing in each area. And it takes years to get to know the code in each system really well, and the business rules which the business has forgotten about which are mastered there. Yes, people write it do
Re:Choose them all under one. (Score:4, Interesting)
You really work for lines in your CV?
I should add "hitting my boss because he had complaints about my smoking habits and some nasty phrases about my mom" then.
But seriously, if I do some work, I make sure I do it for the best of my abilities, and noone can say anything about that. Personal differences are another matter, and they usually arise when my would-be boss doesn't like what I do when I'm done with my work at that time.
For some reason, my bosses seem to think that if I don't appear as working at a particular point in time, I'm not working at all.
Back to your comment, I really do care about productivity, it's just that I don't define it as "appears as though he has something to do, always".
Re:Choose them all under one. (Score:4, Funny)
Re: (Score:3, Funny)
I've found that no matter how ridiculously much you're actually goofing off, if you do it with a vaguely annoyed and frustrated expression on your face, people will think you're working your ass off.
Give it a try.
Re:Choose them all under one. (Score:4, Interesting)
You should take a job-related book with you to your smoke breaks. Crack it open whether you read it or not. Or some kind of PDA.
Re:Choose them all under one. (Score:4, Funny)
Or some excel printouts, with graphs. Vaguely scribble and circle bits of them at random. And make it so the lines are always trending up.
Re: (Score:3, Interesting)
Re:Choose them all under one. (Score:4, Funny)
It helps job security though. Who cares about productivity when they are paying for you to add skills to your resume.
I can surmise by your post you are not a coder. As a recovering coder (I've been code free for 12 years) I can tell you that once a coder is addicted to a particular language changing languages is the equivalent of cutting off one of your limbs. Withdrawal symptoms can be severe and disruptive including the shakes, paranoia, and a condition that strikingly resembles turrets syndrome. There have been coders in recent years that appear to be able to switch languages with relative ease but studies on these coders have not been conducted and it is suspected that they could go off in a fit of rage at any moment and should be approached with extreme trepidation.
Re: (Score:3, Funny)
Withdrawal symptoms can be severe and disruptive including the shakes, paranoia, and a condition that strikingly resembles turrets syndrome.
You forgot the night terrors. [shiver] It's hard to get past the night terrors...
Re: (Score:3, Insightful)
Which was the reference to Intercal in the parent post. If the key piece is written in a language that only a couple of staff members know, then you don't have the flexibility because there isn't "an equally skilled member of the team".
If the language and environment are standardized (I'd be more worried about the language, libraries, and framework than actual development tools), then there are plenty of equally skilled team members that can pick up where someone else leaves off.
Personally, in answer to th
Re: (Score:3, Insightful)
Sorry, I cannot take anyone seriously who proposes to "standarize developement tools". As others have pointed out that's such an obvious productivity killer - you're in the wrong business if you even think about proposing such a thing.
Everyone knows the ancient proverb that says it all: Right tool for the job. Period.
If java is the right tool for everything in your company then fine, standarize on that.
But in reality it normally makes more sense to write the application in java, write the admin-scripts in p
Re: (Score:3, Insightful)
Depends (Score:2, Interesting)
It is OK if the tools are equivalent. Sort of like only using metric tools on your car. It is wrong if you can't use the best tool for the job and there are no reasonable alternatives (sort of like having a wrench when you need a screwdriver).
This type of micro-management usually fails because herding programmers is like herding cats. Programmers work best when they can creatively solve problems. They work worst when they are forced into a suit-mentality.
Answers to your 3 questions (Score:5, Insightful)
1. Slashdot will think that you should be able to use anything you damn well please as long as it's Open Source.
2. Yes, especially if the people who sign you paycheck tell you that's what you have to do.
3. Maybe. A lot depends on how well the team is managed.
Re:Answers to your 3 questions (Score:5, Insightful)
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.
Re:Answers to your 3 questions (Score:5, Insightful)
1. 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!)
2. 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.
Whether your statements are true really depends on whether you are running a software company as a business or as a private playground for developers. Micromanagement is bad, but no management is worse. In my experience it pays off to compromize, i.e. to give developers some freedom but at the same time subjecting them to certain rules. Leaving a bunch of software nerds 100% free to do what ever they want is a major mistake. I have had dealings with companies that failed to effectively supervise their developers and the result was usually a mess. The developers working on different components of major projects went for radically different technologies that often caused major problems or even turned out to be partly or even completely incompatible. Often they seemed to do this simply because they had never written anything in, say, Ruby and wanted to try it out. There seemed to be no concern for whether Ruby was actually the best choice for their project. Not that there is something essentially wrong with Ruby, sometimes it just isn't the best choice. Another wonderful side effect of this policy is that you end up with a portfolio of products written in an ever growing set of languages: java, .net, perl, php, ruby, c, c++ and delphi..... It's kind of like a hauling company having a fleet of 30 trucks where no two were made by the same manufacturer because they have a policy of letting the truckers choose their rides at will. There are benefits to be had from standardization of equipment. In the end even a Software company is a business and it will benefit from standardizing on certain tools and languages. It minimizes lead-in time for new developers, makes it easier to replace developers who have left the company.... the list goes on.
Re: (Score:3, Insightful)
1. Slashdot will think that you should be able to use anything you damn well please as long as it's Open Source.
There is nothing wrong with standardization, but it shouldn't be taken too far. For instance, worked at a Java shop on a project that automated deployment of new software which occasionally meant deploying a new version of a JVM. Since much of the deployment code had to run on the server where Java was being deployed to ... well Java wouldn't be an appropriate choice.
2. Yes, especially if the people who sign you paycheck tell you that's what you have to do.
Yes, everyone should in the end listen to the dude signing his paychecks. That misses the point entirely which is "what are the best busin
Make sure it's not a half-assed standardization (Score:2)
Well, as long as your approved toolkit contains a sufficient variety of tools, there shouldn't be any problems. Make sure you aren't writing file crunching applications in C... there should be a quick and dirty language (perl? python?) available for analysis/protyping/instrumentation.
Oh yeah, everyone should use the same compiler and/or interpreter. There is nothing more annoying than attempting to reuse code that has been written for the .NET 2.0 framework when you are limited to the 1.0 environment.
Standardize the RIGHT tools (Score:5, Insightful)
Management invariably tries to standardize the wrong tools because they have no idea how software development works. They think in terms of the IDE as "the tool set" rather than the MAKE or ANT build systems, compiler toolchain, version control, and other behind the scene tools.
If you want the standardization to go well, make sure the build tools are standardized. Once anyone can build the project (IDE or no), it won't matter what the "standard" IDE is. (Unless it's Rational Application Developer. That's just a piece of shit right there. Universally agreed upon.) Developers will still download their own editor or IDE tools to make themselves happy without disturbing the greater whole.
Re:Standardize the RIGHT tools (Score:5, Interesting)
Re:Standardize the RIGHT tools (Score:5, Informative)
That combination is better than just free as in beer... it's also free as in free speech! Subversion, Ant, and CruiseControl are all Free Software.
Re:Standardize the RIGHT tools (Score:4, Insightful)
Now that's logical, exactly the right answer. They'll never buy it though, unless you can write book about what you just said, and invent a catchy new buzzword to describe the concept. Something like Dev 2.0..., or better maybe an acronym, like PEAT
Re:Standardize the RIGHT tools (Score:4, Funny)
Developer Centric Individualized Standardisation.
Look forward to my upcoming book on the subject:
Development 2.0 : Practical Perfection With The "DeCISt" Paradigm in the Enterprise.
Seriously, a year or so ago, a friend of mine and I were just about ready to write a book about the benefits of procedural programming in C using a simple text editor, and then just buzzword the shit out of it and hype it up like Xtreme Programming and such, and pretend it was a new revelation. For the life of me, I can't remember what we were going to call it. Something like the Post Object Paradigm, or Modern Objectless Development, or some such shit. We would have made millions if we weren't lazy asses.
Re:Standardize the RIGHT tools (Score:4, Funny)
I was making fun of extreme programming. Honestly, I don't have a problem with it. It is just one of those things that, if you investigate the core philosophy, is all eminently reasonable, and is something that evolved to address real world concerns. OTOH, if you move beyond the core philosophy and talk to some of the narrow minded ideologues and idiotic buzzwordologists, then extreme programming can move from something perfectly reasonable to being something perfectly in need of being made fun of! :)
My only real issue is all the hype that surrounds "XP" and "agile development" such that some of the virtue gets lost of the noise of "exciting" and "new." If I could pull off that kind of buzz for Xtreme Classless Proceduralism, I'm sure that PHB's everywhere would be lining up around the block to learn new and exciting ways to force their developers to upgrade to my special 800 dollar version of vi, so that they can code in new and exciting C.
Which reminds me, I also need to figure out someway to write a book about a paradigm called "Write Once, Run Once" to promote development of incredibly unreliable code.
Re:Standardize the RIGHT tools (Score:5, Insightful)
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.
Re: (Score:3, Interesting)
Management invariably tries to standardize the wrong tools because they have no idea how software development works.
Hmmm, in my experience at several small and large companies, management tends to leave Tech management to Tech managers, who tend to know very well how software development works. Their reasons for making choices you don't agree with may well be sound and rational, or forced by circumstances. They usually don't just have your to consider, but all the other projects, as well as future projects and still supported projects from the past. Hiring and training is very expensive.
You may save development time for
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
I've worked in a situation where behind the scenes tools where standardized but not IDEs.
There are a couple of issues when everybody has their own IDE, mostly to do with being able to help each other out (when you have to go help a colleague with a piece of coding or debugging but you have trouble working with their IDE) and with setting up the project or new project features (5 IDEs means 6 places to change - each IDE plus the main build - and thus 6 different sets of possible problems and there's always s
A gross misunderstanding of the process (Score:5, Insightful)
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.
Re:A gross misunderstanding of the process (Score:5, Funny)
Sure, and while they're at it, let's give all the mechanics just one size of wrench and screwdriver.
I am so sick of this analogy, as it's completely inaccurate. Programming languages, at least full featured languages, are a whole set of tools, not a single tool. Comparing Java to C is more like comparing Craftsman to Snap-on, different brands of tools but they can both be used to do the same thing. If you can give you mechanics a single tool that can be used in all their tasks, like a sonic screwdriver, then do it. If the language isn't full featured, or cover all your needs, then don't use it.
And conversely, each project team should be free to evaluate the best tools to get each job done.
This is exactly what you need to do if you want to guarantee that you have to continue with the team you have or hiring nothing but experienced senior developers. Keep the number of tools simple and you can have a small number of leads and many interns to do the same amount of work with a much higher over all quality and considerably less cost.
If anyone thinks that limiting a computer scientist's choice of tools is a good idea, you should kick that manager to the curb.
If anyone thinks that hiring computer scientist's to do anything other than research and theory is a good idea, you should kick that manager to the curb.
Re:A gross misunderstanding of the process (Score:5, Interesting)
Sounds like Stanford taught things the right way.
Just last week, I was thinking about this. The University of Texas (where I went) had a similar philosophy when I was there as well; the goal was to teach the concepts and how to learn new languages. We groused about it incessantly at the time, but looking back over how my career has progressed and how I've been able to adapt to new technology, it was absolutely the right education.
Consider this: At the time I started my Freshman year in college, the Fall of 1991...
The most basic elements of what we develop with today didn't even exist, and those that did exist were in nascent forms that they today barely resemble. Even ANSI C got a major update 8 years afterwards with the C99 standard -- which is nine years ago.
But wait, there's more!!!
When I was in grad school at UCSD, I took a class on Software Evolution. The instructor would give us a project, and every couple of weeks ask us to make changes to the project as our next assignment, to expand the project's capabilities. We were given the freedom to choose whatever means we wanted to pursue this goal. The initial assignment was to generate a simple web page.
A friend of mine chose to use Perl. I asked him if he knew Perl, and he said, "No, but I can learn how in the time it takes to implement this in any other language, and with each new assignment I can just write a whole new script."
He was the only one in the class to finish every assignment.
The moral of the story is not that Perl is something wonderful, but rather that Perl was the appropriate tool for the job and that learning how to use the appropriate tool takes less time than using a tool you're familiar with that doesn't work so well. Consider chopping down an overgrown pine tree. If you know how to use a hand saw but not a chainsaw, the guy who uses a chainsaw is going to hack the tree down in less time regardless of whether he has to read the manual to learn how to use it. (And then after that, he'll know how to use a chainsaw on other trees, too.)
So... yeah.
Re:A gross misunderstanding of the process (Score:4, Insightful)
Standardization of software development tools and languages has to do with optimizing the process at a higher level than most developers are used to.
The point here is to optimize the way a whole company (or at least a whole division) produces software:
Standardized support tools (build tools, version control, etc) mean that there will be things like shared project templates and a higher average level of expertise with the tools being used (if everybody uses the same tools, there will be more experts with those tools around).
Standardized languages mean that in-house developed libraries and frameworks are feasible and can be reused all across the company in many of the projects being developed.
Standardization in tools and languages also increases predictability of results - everybody, including managers, gains a better grasp on how long it takes to do something since they have a lot more experience using that set of tools and languages.
Standardization also means that it's a lot easier to find and train replacements for those that leave or (even more important if you're a developer) those that progress in their career to new tasks and responsibilities and don't want to be stuck "maintaining the software I did 4 years ago".
When you are working as a part of a team you work with the team and don't just go away and do your own thing 'cause you know best and everybody else is an asshole.
To use your automotive metaphor (this is ./ after all):
- If you work in a garage you get many different cars with many different problems so you use whatever tools are appropriate for the task at hand.
- If you work in a car factory (say Porsche), you use the specialized tools you are assigned to use for the tasks you're supposed to do. This applies even if you're one of the designers of a new car - you don't just go out using your own CAD application 'cause you think you know best.
Re: (Score:3, Interesting)
The theory sounds about correct.
That said, I've had the experience of working in a corporation for some time where everything was too standardized.
That means that (for example) we needed to all use the company developed CRM (because we ate our own dog food) that had two speeds: very slow and not working (very slow here means that is was web-based, with the server in another country - over VPN and with a single webpage loading in 40 seconds at times). Performing a code change required loading about ten reloa
Start sending out resume... (Score:5, Insightful)
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...
Re:Start sending out resume... (Score:5, Insightful)
Re:Start sending out resume... (Score:5, Funny)
The only thing worse for it is hiring "managment consultants" to "streamline" the process.
Well-well look. I already told you: I deal with the god damn customers so the engineers don't have to. I have people skills; I am good at dealing with people. Can't you understand that? What the hell is wrong with you people?
Re: (Score:3, Insightful)
Well-well look. I already told you: I deal with the god damn customers so the engineers don't have to. I have people skills; I am good at dealing with people. Can't you understand that? What the hell is wrong with you people?
So, what you're saying is that you stop the engineers talking to the customers, so that the customers don't get what they want built, and the engineers don't get to know what's going on?
If your engineers are embarrassing to the company, and don't have people skills, hire different engineers.
Re:Start sending out resume... (Score:4, Funny)
Whoosh.
BOB SLYDELL
So what you do is you take the specifications from the customers and
you bring them down to the software engineers?
TOM
That, that's right.
BOB PORTER
Well, then I gotta ask, then why can't the customers just take the
specifications directly to the software people, huh?
TOM
Well, uh, uh, uh, because, uh, engineers are not good at dealing with
customers.
BOB SLYDELL
You physically take the specs from the customer?
TOM
Well, no, my, my secretary does that, or, or the fax.
BOB SLYDELL
Ah.
BOB PORTER
Then you must physically bring them to the software people.
TOM
Well...no. Yeah, I mean, sometimes.
BOB SLYDELL
Well, what would you say... you do here?
TOM
Well, look, I already told you. I deal with the goddamn customers so
the engineers don't have to!! I have people skills!! I am good at
dealing with people!!! Can't you understand that?!? WHAT THE HELL IS
WRONG WITH YOU PEOPLE?!!!!!!!
http://www.imsdb.com/scripts/Office-Space.html [imsdb.com]
it's not terrible if done in moderation (Score:5, Interesting)
I'm in academia, where just about the opposite prevails: you can use whatever you damn well please, and generally PhD students don't even get that much in the way of hard-and-fast rules from their advisors, so they use what they please too, as do half the research scientists and post-docs. The results of that are why companies consider standardization.
The main problem is that, while experimenting with lots of languages and using languages perfectly suited to a particular task is nice, doing it too freely makes for a nightmare if you ever want to combine things, have a programmer of one system help out on another project, etc.---just the sorts of issues that prompted this question.
My current research project's codebase, partly inherited, partly pasted together from components that were lying around the lab, and partly of my own doing, using nine languages, as a result of everyone using whatever seems like the right tool for each job. There's a C backend for one part and a C++ backend for another part; an AI component in Lisp; some GUI and glue-y stuff in Python; other GUI stuff and some other AI stuff in Java; some text-munging scripts in Perl; some number-crunching in Ocaml; some parsing and god knows what else in Haskell; and some other AI in an in-house language that compiles to Java.
Now some of those tools were indeed exactly the right tool for the job. But this is not ideal to maintain, and it's nearly impossible to ship to anyone who isn't me in a way that a mere mortal could get the code built and running.
Oh, and there's some other projects in the group that use C#, and one that uses Scheme, if I want to go for double-digits...
Re: (Score:3, Interesting)
I couldn't agree more. Saw this happen at the Associated Press. Senior management is devoid of anyone with a clue. If you have one, get out now. Outsourcing is next. Process reorganization is imminent. Town hall meetings with lots of Powerpoints are coming. Team building exercises, interpersonal skills development, and IT management consultants are on your doorstep. The gas-heads minding your store will be an easy sell for them.
Fast forward 4 years...
The 'good' programmers are mostly gone.
The gas-he
Workplace Hell (Score:3, Insightful)
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.
Maybe not, but there has to be some standardization. If every programmer is allowed to do things their own way, you end up with a code hodgepodge that's unmaintainable.
Mild example: I knew a guy once who had a weird thing for Javascript. He had found an engine that allowed him to run it outside a browser, and he used it for everything. (Ironically, he had no occasion to use it for a web application!) He even used it to write an RTF parser. Never mind that Microsoft supplies very nice libraries with all the
Re: (Score:3, Informative)
What features does Java need, that it doesn't have?
It needs to not be object oriented. The paradigm just doesn't suit compiler writing.
For parsing, functional languages can easily have Domain Specific Languages embedded into them, which makes writing parsers as easy as transcribing the grammar.
For working with the tree structure a compiler is commonly written in many "micro" passes each of which does some subtle optimization on the tree. Because the idea is that you do lots of different small passes, you want your code to be tiny, that's where pattern mat
Type of Company? (Score:3, Interesting)
In my line of work, the industry has been migrating from Cobol and Fortran to C/C++ in recent years. I have seen small bits of Java on tertiary projects. I have seen vastly different development toolchains.
My 2 cents? Standardize intelligently. Let experimental groups explore whatever they want, but reign them in when it is time to make evaluations.
One area that I love seeing standardization is in the tool for managing the software repository where you commit your periodic code changes. There are also benefits for standardizing on compilers and code libraries that you use.
One area that I hate to see standardization is in text editors. Let people pick whatever fancy or simple typing program suites their needs best.
Obviously, this post is not geared towards whiz-bang web developers who actually need to push the envelope a little bit to stay ahead of the latest trends.... but there is something to be said from the benefits of specialization and so I generally agree that *most* areas of company code development should be locked down and projects at the company that are not in compliance should have good reasons.
It depends on how varried your projects are (Score:5, Insightful)
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
No way. (Score:5, Insightful)
Where developers must interface, such as coding style, source code repository or corporate blog? Yes, it makes sense. I may not *like* a coding style, but if management at a large company told us to use one, I'd at least understand why. IDE? OS? Compiler (except for the one that actually builds the product)? No, NO, NO!!! A thousand times, no! Why? Because you're just going to stifle creativity.
Management point: IT needs to work on the same thing. Counterpoint: IT is often clueless. Developers can almost always troubleshoot their own systems.
Management point: Ensures software licensing compliance. Counterpoint: None really, they kind of have you there; but since most companies have a policy against installing unlicensed software anyway, punishing developers by forcing them into a cookie-cutter workstation isn't going to solve that problem.
Management point: puts them all on the same page, builds team. Counterpoint: It makes development less a "collegial" environment, where diverse ideas are explored, and more of a "command" environment. Developers are notoriously intolerant of following orders simply for orders sake.
Newbie developers coming right out of school might not mind being told to use all the same tools; but experienced developers might feel otherwise. If you want to annoy experienced developers who know all the ins-and-outs of their particular toolset, then go right ahead. Then, wonder why nobody comes up with new ideas, makes comparative observations of one system against another, or develops an alternative approach that goes beyond the status quo. Wonder why people who don't drink the kool-aid on your particular toolchain leave for greener pastures. Wonder why you don't have any in-house expertise on any other system when your chosen flavor is no longer sweet.
Re:No way. (Score:5, Insightful)
Unless they all operate on the same meta-data the foreign tool is out. My boss thinks the same way you do, every one is allowed to use any damn tool they feel like, with absolutely no bounds.
I work with a guy who insists on using Visual Studio, as nearly as I can tell, because he's unaware that there is a multi-tab text editor outside of VS. So, everytime I have to take over a project from him, I have to go figure extract what files are being build, and then port it into the production system, every other developer on the project uses. Because this is such a hassle, the guy will do updates and commits on an interval measured in months, where as every other developer does them on intervals measured in hours. So along with everything else we have to deal with, when he commits his code, he generally will blow away months of someone elses work because he can't be bothered with learning how resolve conflicts, and it'll never integrate cleanly. We'll spend a week just trying to undo all the damage he'd done. All because he can't be bothered to use the same toolchain everyone else on the team does. It also means I have no commit history, no commit comments, and nothing I cause use to do research on to figure out how the software evolved.
Because he uses Windows, Visual C++ compiler, on an AMD 2.8GHz machine and does all his profiling, it's trivial to go make improve his codes performance on Linux, g++, on an 1Ghz Via C3 (which is the deployment environment for the embedded system). As he works on the single most performance critical aspect, it's more then a bit frustrating. Especially as the code has extreme and unnatural things done to it to the parts that are slow under his one off development environment, but those aren't the parts that are slow under production.
For things like Java, I've learned the hard way, that we'll only have one setup of meta-data. It's terrible frustrating to have all of the corporate standards setup correctly in say Eclipse, (checkstyle, code generation, auto-formatter, unit testing, test coverage, find bugs, PMD, warning levels, etc, etc), and then have some jackass continually commits code that upon contact with a properly configured environment will be flagged as a violation of the coding guidelines, or generates huge numbers of warnings if only he'd turn on the already agreed upon warnings.
I've learned, that there is one set of production meta-data used to do a production build. While we can argue over how we maintain that set of meta-data, once that decision is made all tools must use that meta-data directly (they can translate it from one format to another, as long as it does that automatically, like Maven can for some IDE's). So if we use Eclipse, you can use any tool you want, as long as it reads Eclipse meta-data. If we choose Ant, then you can use any tool you want, as long as it does Ant meta-data. If we choose GNU Build system, you can use any platform and compiler you want, as long as it uses the GNU build system. The one hard and fast rule I have for the meta-data is that it must be possible to build from a command-line in an automated way. It can be obscenely difficult to do (like say Eclipse), but it must be possible.
I've generally learned that anybody who won't agree to use a consistent set of tools with the rest of the team, is a prima dona and is in dire need of a lesson. Yes, I know my toolchain stone cold (gcc/g++, and Eclipse). However, if there is a consensus to use a different toolchain, I'll learn a second one stone cold. I've learned tons about bash, gcc, g++, the Borland compilers, Visual Studio, a number of embedded compilers, Watcom, XCode, the NeXT Objective C IDE, NetBeans, Eclipse, CVS, SVN, Git, Monotone, Arch, Mercurial, Ant, Maven, GNU Make, GNU Auto{conf,make}/libtool, SCons, and probably a couple of others I've forgotten (I've known bits and pieces of several scripting languages, but none well enough write home about). I've learned the best practices of them all when I used them. Given m
Re: (Score:3, Insightful)
Re:No way. (Score:4, Interesting)
You hit on an important point - "developers are notoriously intolerant of following orders simply for orders sake". If all your developers loved CoolToolABC, but then you ordered them to all use CoolToolABC, they would rebel and feel stifled. There's a lot of creativity in software development, and to ignore the psychology of it is a big mistake that I've seen many corporations make.
It's dumb. (Score:5, Insightful)
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.
Re: (Score:3, Interesting)
I'm going to disagree with you to a point. Having a standardized application framework makes a ton of sense when used for a for a specific class of product, and once chosen, should NEVER be deviated from. Having a "default" set of tools for an organization also makes sense, so long as the process for allowing deviations is reasonable. (EG: peer review by other techies, etc)
There is a *lot* of value in having a standardized framework for application development - working with one, it's a breeze to reassign p
Re: (Score:3, Interesting)
Programmers are not generic as much as executive management would like them to be.
If your application is sufficiently complex, being in the same language buys you very little.
And there are huge costs to using an inappropriate language to solve a problem.
If it were just me, I'd go with Java all the way because at least it is fairly reusable on unknown future hardware.
And that being said, it would completely suck to try to work on certain classes of problems and platforms only in Java.
At my current company we
Re: (Score:3, Interesting)
I'm an executive. I'm also a programmer. I will do just about *anything* to avoid the 10x decrease in productivity you mention.
I've seen it - so far, we compete aggressively with companies many times our size, and trounce them handily by trusting our developers and maintaining a highly consistent code base with lots of comments and purposefully simple SQL queries. The results (so far) have been eye-popping.
BTW: our bread-and-butter app is written in LAMP (postgres) with a fair amount of php-gtk for the clie
Microsoft (Score:3, Informative)
You should look at what the majority of the developers are using to make this decision. If you are a Microsoft shop, and cost is not a huge issue, the combination of VS 2008, .Net 2 or 3, and C# and VB.net will fill your need and just can't be beat in terms of getting large teams to work together. Plus, you can always add php via VS.PHP. Unfortunatly, if you are using php, or something else, your choices are going to be all over the place for IDE and framework.
Better to choose a process than an environment (Score:5, Insightful)
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.
Two (Score:5, Interesting)
A similar question came up roughly a year ago on slashdot. My recommendation is to chose two: one "scriptish" language (PHP, Python, etc.) and one strong-typed language (Java, Eiffel). C# is sort of a compromise between the two, but marries you to MS (so far), which may bite you in the future like VB6 did.
Does everyone know the same languages? (Score:5, Insightful)
Perhaps your environment is unique, but I've rarely seen an organization capable of moving people around at will, simply because not everyone has the same skill sets. Even within the Web development paradigm, there's always the "SQL guy", the "CSS guy", heck, even the "regex guy" who's been writing Perl since he was a kid. making that guy use Eclipse instead of vim and puTTY seems counterproductive to me, even if you happened to have someone with those skills on each team.
Doom!!! (Score:5, Insightful)
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...
I have mixed feelings.. (Score:5, Insightful)
I used to think that a programmer's tools are sacred and you should basically let people use whatever they feel they are most productive with, but I'm starting to see problems with that, at least in big organizations..
First, IDEs - I've worked on teams where 3 different IDEs were being used by different members of the team - IntelliJ, NetBeans, and Eclipse. It worked fairly well and no real problems came about as a result of the different IDEs. I've also been in training sessions where everyone is using the same IDE except for some crackhead insisting that their IDE is better and that they can't switch to Eclipse even just for the training, and everyone in training has to wait for half an hour why the instructors try to help them figure out why stuff isn't working in their IDE.
Second, platforms/libraries/frameworks - There are really a lot of valid reasons for standardizing the platforms, libraries, and frameworks your organization uses. You have better internal support, can leverage work done by other groups, and training is easier. Being able to switch people around easily is perfectly valid as well - people leave, get promoted, need a break from their project, want to explore different career goals, etc.. Plus, I think it is good to send people off to other projects to learn and share good practices. Having a standard set of tools makes this relatively easy - all you really need to learn on a new project is the business side of things.
That said, there isn't a one-size-fits-all solution, so it probably makes the most sense to pick a standard set of tools for common project types. If a project needs to deviate from one of those standards, that is fine, but they need to make their case for doing so.
So for full-blown enterprise apps, the standard may be Java EE. For smaller apps, it might be Rails or Grails. For desktop apps, you might mandate .NET. Then if someone says "Hey, it would be cool if we wrote this small app in Python", then they could do it, but they would have to show that the benefits gained by using Python in that scenario would outweigh the costs of using a non-standard platform.
GCC + Make + Emacs (Score:5, Interesting)
Makefiles are text files, and completely tool agnostic. By standardizing on Make, you don't paint yourself into a corner with a single toolchain.
Emacs has editing modes for many languages and file formats. By standardizing on that, you don't paint yourself into a corner, unlike a single language IDE. (Also, those who prefer vi can still use Emacs in viper mode, so Emacs is a more flexible choice than vi for the company).
GCC is a compiler collection, with support for many languages. By standardizing on that, you don't paint yourself into a corner with a single language.
Best of all, these tools don't take up a lot of RAM, so the development machines will be responsive without beefy hardware.
Root cause (Score:5, Insightful)
There is definitely value in having the members of the development team agree to a set of tools around which they can share common experiences and exchange solutions for problems that come up. That's fine. What scares me about your question is that it is driven from above,
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.
Developers are not plug-compatible interchangeable parts that can be slotted in and out of various projects according to shifting needs. It doesn't matter if they all know exactly the same toolset or not, dropping Jane from the accounting project who has been around for a couple of years in to replace James in the supply-chain project who left because he got married and his wife is taking an internship at a distant hospital and expecting equivalent results demonstrates a vast ignorance of how developers become productive.
Nearly every company's management wants to imagine it can standardize developers for a lot of bad reasons -- because they believe that gives them leverage over someone who has deep domain knowledge and can't easily be replaced with a junior programmer for example. Or they imagine they can save money by buying bulk licenses for a product from a vendor. Beware of management playing golf with software tool vendors, you'll get stuck with some POS for sure.
Perhaps going to management and suggesting that the developers collaborate to nominate a selection of acceptable toolsets from which management can select would work, but that kind of suggestion never seems to be taken very well by the suits.
Choose an ide platform (Score:3, Interesting)
Management is stupid indeed and like another post said they do not know the difference between a language and an app. Management loves one big app such as peoplesoft or something that integrates and assume languages or like software programs to lower costs.
If you pick Netbeans or Eclipse you can then use other languages for it and management wont realize it. You do not have to be stuck with java even if the ide is written in it. Management assumes everyone is using the same thing.
Or if your an ms shop vs.net can use perl.net and python.net for small scripting and text searching while all using the same .NET framework for small admin jobs while still retaining your web (C#) and desktop C++/VB languages. This ensures your on the same platform but can still choose the right language for the job.
I read here on /. that Catupiller uses C for everything including shell scripting and its obvious its a very bad idea as one language such as java has vast api's for serving dynamic pages while C is good for getting close to hardware and using assembly calls.
Maybe recommending 2 or 3 languages using the same framework (.net) can be a selling point as they can integrate and retraining is low. But yes web programming is not desktop nor low level hacking as different tools are needed for different things.
Standardize on 3 and chose a common framework for all. You do not have to use .NET if you do not want too but its commonly used. Java is getting better for non server use. But try to sell the ide as a language to get around any dumb requirements. ALso remind management that every language has a sub language within it like AJAX, SQL, etc so its its impossible to standardize anyway.
It depends a lot on company size&diversity (Score:3, Interesting)
We have the same issue come up in my company(~500 developers).
Obviously with such a large number of programmers working on so many different pieces of software complete standardization is very problematic.
We are finally deciding to create a set of 2 or 3 software architectures to choose from.
And have them prioritized, and a process of getting an architecture approved. The idea is when starting a new project you should use the preferred architecture with minor changes unless you have a good reason to pick architecture #2 or #3. however You will have to have very compelling arguments to run your project on a totally new architecture and explain yourself to top executives.
An architecture will include both development and production environment for example we may have the M$ option: win2003+IIS+mssqlsever+C#+Link+Visual studio+TFS
or our java option:
Red hat+jboss+hibernate+java swing+java web start+eclipse+SVN
The problem is setting a process to update the architectures with time, we want to move forward with time but we don't want to be dragged in to new adventures every week.
We can put a person/team in charge of a specific architecture but we still don't have a good process for phasing out an architecture and introducing a new one.
How do we decide we are ditching C# and moving to Ruby on rails? This remains an open problem for us.
Me.
Solve the right problem (Score:5, Insightful)
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.
A quote from a friend (Score:5, Insightful)
"Management standardizes that which they do not understand, to relieve them of the responsibility of having to think about it any more..."
dave
Devil's Advocate (Score:5, Insightful)
Yes, there are almighty drawbacks. Things aren't nearly as simple as management tend to believe.
However...
That doesn't mean the reverse isn't often true as well.
Just like 95% of drivers know they're in the top 50% of all drivers, I know this'll piss off a lot of indignant engineers who know they're far too smart to fall prey to this...
But, the truth is, a lot of engineers are absolutely terrible at picking the right tool for the job too.
The right tool is not "anything other than the tool I used last time because I know that one has lots of flaws now." Every tool has flaws. There being a devil you know doesn't mean the other option is a blessed saint. It just means you don't know its flaws yet.
I've watched countless engineers choose tool A, decide they hate A and want to use B because it solves X that they didn't like about A... Then decide B does Y badly so they move to C... Then discover C screws Z up but A has a new version that's supposedly much better. And then they repeat... Every time, writing lousy code because a decent tool that's poorly understood is often worse than a bad tool that you understand deeply enough to avoid most of the pitfalls of.
Conversely, the right tool is also not the one that you know and won't put down because you're scared of the learning curve and don't want to look bad compared to other engineers when you're safe and secure in your existing kingdom.
The right tool is also not the one that'll make your resume look really cool and cutting edge. Yes, it's often exciting to learn new skills and they make you look really advanced. Learning tends to have a diminishing rate of return. Say you can learn the first 50% of a language in a month. You can probably learn the next 25% in the next month. Two or three years in, you're hopefully smart enough to still be learning but you're only improving by fractions of a percent of what's out there each month. It's tempting to pick something new and learn 50% of a whole new language... but that doesn't actually make it the right tool.
Engineers also tend to be very bad at understanding what makes the business actually work. Yes, I know there's deep moral righteousness but, here's the interesting thing... if the business can't find anyone in the area to help you ship a product on time because you chose too obscure a tool... if the business goes bust because they're paying too much for trendy skillsets... it's still the wrong tool. If the business isn't in business anymore because the tool ignored financial realities, it's the wrong tool.
In short, there are a lot of ways that engineers tend to make very, very bad decisions about what a good tool is.
Yes, I know you're not one of those engineers. I know bean counters make even worse decisions. I know I need to go to hell for suggesting this.
But the right tool is often a combination of factors. Some engineers tend to get, some engineers tend to be very bad at getting, some managers tend to get, some managers tend to be very bad at getting.
Being open to identifying the flaws in decision making processes and finding ways to make better decisions is how we really get to the point of picking good tools. In some companies, for certain processes, that may mean standardized tools, in others it won't. Smart people are open to all ideas and pick the best from them for each situation.
Not dev tools. (Score:3, Informative)
Two of us run Linux, two of us run OS X, and two of us run Windows. On OS X, one uses vim and one uses TextMate; on Windows, one uses Visual Studio and one uses Eclipse; on Linux, one is a tester, and I use Kate.
While I'm at it, two of us use the Dvorak keyboard layout.
To force us all to use one platform, and one environment, would be to drop our productivity severely for the learning curve, and permanently as we all work on a platform that doesn't as closely match the way we work.
Now, forcing one language/framework, I can understand -- we mostly use Rails, and pretty much entirely Ruby. But what would be the point of forcing one dev environment?
Is it so that they could easily give my laptop to someone else, or give me a different machine? We basically get a budget with which to pick out our own hardware. This laptop is mine but for a technicality: if I ever leave, they'll take it back and reformat it for the next person.
I agree with many of the other sentiments here -- programmers should not be moved from project to project. But depending on the projects, it may be at least as difficult to learn the new project as it is to learn a new language/framework.
But unless you've made an exceedingly poor choice of language/framework, you should still be able to pick (mostly) your own dev tools.
Screwed (Score:3, Funny)
This is one of situations where all I can say is:
If your problem requires this solution, then it is actually unsolvable, and you are all screwed.
Languanges (Score:3, Insightful)
There's a lot about the idea that's dumb, but I just want to talk about language standardization, since that's an idea that suckers even smart people.
For a decent programmer, switching languages is not really a problem. On the other hand, there's not a lot of point in having a proliferation of quite similar languages.
You're basically going to always have to write some C, whether you're doing some low-level control or interfacing to an API or whatever. For most business applications, this is a marginal task--that is, it takes place on an application's margins.
You're going to need some kind of scripting language, and you can make it object-oriented if you like--that's not a bad way of organizing some programs and helps keep a handle on the sometimes complex applications "scripts" become. These tasks are also marginal (they're management or stopgap or interfacing or, literally, scripting server-side resources together). I wouldn't choose Perl here, it would be Ruby or Python; but really, any of those are fine.
And then you'll need something for the really important stuff. And this is what kills me. Time after time, productivity studies show that terseness counts a lot for programmer productivity, and for quality (a programmer produces the same number of lines of code per unit time, regardless of language; and makes the same number of mistakes), and can otherwise show that Java is utter garbage for this task, but it's most frequently chosen anyway.
Java's not much better than C for terseness, and it's full of typing misfeatures that have never been shown to increase code quality. On the contrary, Java is such an unmanageable beast you have to use a program to type chunks of your program for you. About the best thing that can be said for it is that the JVMs aren't bad and can sometimes be used to run non-Java languages.
For the important stuff you'd think people would pick a family of languages that have been shown time and again to result in faster, higher-quality development: functional programming languages. But managers and developers alike resist it (unless the developer actually has experience with a functional programming language). Lots of people have speculated why and I'm not going to restate all that here.
I'll put my word in here for Erlang because it comes with so much technology and fills such a need in the non-marginal problem space of so many business applications. But Haskell or PLT Scheme or whatever would be good choices, too.
I recoil at the idea of picking a language because it might be popular with "average" developers. Who sets out to hire a large number of mediocre, interchangeable developers? If you choose Java, that's essentially what you're aiming at: a large number of minimally productive programmers producing reams of code that doesn't do very much.
None of this should override compelling external factors. Sometimes you really need some FORTH because you want to embed an interpreter in something. Sometimes your embedded wiki is in Perl and you're going to extend it with that, your corporate standard of Python be damned. And, yes, sometimes maybe Java is the right answer (though if it is, I haven't come across the question yet).
Now, look, we all know "any programming language can do anything." And we have all heard the religious arguments about all these things before. But surely, if a company is serious about "standardizing" it must do so on the basis of actual programmer productivity data and not on the basis of wild-ass guesses and the popularity of books? Continue to accept orthodoxy and be prepared to suffer a lack of excellence.
Re: (Score:3, Insightful)
Re:Depends (Score:5, Interesting)
It's lame to reply to myself, but I forgot something re: development tools.
Don't dictate what your developers use, if it's possible. Case in point: In my current company we are building a VB.NET web application. There are six developers and five of us use Visual Studio, but the tech lead does not, he uses VIM. I was amazed by this, but after seeing him wrangle some text with that thing, I can see the value over an IDE, although I still prefer its warm confines because I've come to rely on the bells and whistles.
BUT, this works only because he has a build system where he does not rely on the VS project files, only the source code, resources, images, etc. The end result is the same as if you had compiled the thing inside Visual Studio, except that you used only the compilers. This is very cool, and while I don't fully understand the build files, I can see how that's a definite advantage. The scripts even pull the source off CVS and everything.
My point I guess is that you shouldn't tie yourself to development tools, if possible. That's just common sense, and at the same time you'll allow developers to use the tools they prefer. That makes for happy developers.
Maybe one of these days I'll try VIM or EMACS, or maybe I'll just stick with the IDE. But at least I know I have the option.
Re: (Score:3, Informative)
The need to show "how good you are" with VIM is extremely lame!
Well, you're thinking that the VIM guy really gives a tit what everyone else thinks. If he still codes 2x-20x what all the IDE people use, and he's happy, and his code works, he's not going anywhere soon.
I've worked with more than a few crack developers who can hunt-and-peck faster than I can touch type, which isn't slow... Oh, they happened to know as much of the internals of the business as the business people did...
Re: (Score:3, Insightful)
Your company probably has all those RDBMS because somewhere along the line they bought an accounting package, say, that runs on Sybase. No, let's get real, Oracle Financials. HR somewhere got onto a package like Lawson or JD Edwards, because Oracle HR was too bloody expensive and the moneybags did not want to pay any more for Oracle DBAs than they have to. So it's Lawson or JDE on Sybase or SQL Server. And then maybe there was some budgeting, forecasting or other Enterprise-y application (say, data warehous
Re:EPIC FAIL! (Score:5, Funny)
Re: (Score:3, Interesting)
If it were my company I would be interested in finding out the real problem that the PHBs are trying to solve. Are there too many different toolsets in use or do they think that by standardizing they will make everyone into neat little interchangeable cogs?
I worked for a company owned by a ban
Re: (Score:3, Insightful)
A programmer that brings his own tools is a cowboy at best, especially where I work...
Agreed, but who drives the decisions for what software to buy at the shop? If it's anyone but the programmers, you're in trouble already.
Re: (Score:3, Interesting)
What I'm discounting is the one-size-fits-all mentality that seems to pervade management circles. There's a fine line between preventing things that are unsupportable (MIPS Assembly Language) vs. preventing people from using better tools for the job (Python / Django for a CMS-like application vs. Java and Struts for the same application). It's the myopic pipe-dream of management that by standardizing on "the one true platform", they can hire the same type of programmer, interchange them efficiently between