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?"
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.
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.
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.
"I'd rather be a lightning rod than a seismometer." -Ken Kesey
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.
Javascript + Nintendo DSi = DSiCade
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"
I'm not a very experienced developer. I've worked at two different companies so far, where I was lucky to learn from some people who were.
The way I'd see this is whether or not you have a one-size-fits-all framework that will be useful in many different situations. But you have levels. For example, you can do pretty mcuch everything with VB.Net or Java, from web apps to desktop clients. So at that level you should pick a good, mature, supported platform that fits your basic needs (Linux, Windows, whatever).
The next level would be the stuff you pile around the base language. That's where it gets interesting. Some people swear by one ORM library (Hibernate) and others prefer whatever they used at the last project. So if you dictate Hibernate and Struts, people who were used to something else might not like that.
But if you don't standardize, you'll find yourself trying to wrangle nine different stacks that might do the same. How much is that worth? It's a waste of time and treasure. My company currently runs MS SQL, Oracle, Sybase, Ingres and MySQL. Why? Probably because at some point someone said "screw Oracle, I'm doing this with Sybase because I like it" and the rest is history. Extricating yourself from that can take years.
If the person making the decision to standardize on LibraryX is knowledgeable enough to make that call and he is making it based on the requirements of the company and the skill levels of the developers (current and future), then the standardization will work. The developers who work there will have to adapt and learn if necessary. Less-experienced developers (like me!) should not dictate what the company uses to ship applications just because they like a given library or toolset, because we choose what we *like* or what is cool rather than what is sustainable.
Anyway, good luck. I've seen how hard all that can be, especially at large firms.
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.
Support the 30 Hour Work Week!!!
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
All major languages are isomorphic and equally powerful (see Church-Turing thesis), so it should be possible for any programmer to use any language he or she wants to when working on any project, no matter what the existing code base is in. Sadly, the current generation of developer tools does not support this, though there are some promising next-gen projects which may solve allow this. Google "language-oriented programming" for more info on this.
In the mean time, the best approach is different languages for different tasks. If management refuses to accept this, I suggest you recommend INTERCAL as the standard language. It's a mature language (>30 years old) with many features not found in any other language.
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.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Comment removed based on user account deletion
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.
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.
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...
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.
Table-ized A.I.
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.
body massage!
So you have tried emacs too huh.
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!!!
Consider globalization as a solution. The single biggest overhead cost of any set of software projects is the Upper Management Staff. This group of people do not necessarily need to understand how the process is made, they only need to just find other ways of doing some process cheaper. By hiring staff that would cost roughly 30 cents on the dollar from some 'nth world government, the Investor/Owner can reap 70 cents in profit by reducing Upper Management. With the added benefits of not being slowed down by those not directly involved with the product. But the saleability issue is unignorable. For large groups of software projects, like the D.O.D. a different globalization solution would work more optimally. By using A.I.Alturnitives for the handling of such things as Logistics, the DOD can effectively reduce their cost savings by 90 cents on the dollar. The DOD does not really make anything. The vast majority of officers act as redundent support staff. One person could do the job of project effectiveness as an entire team of Middle Managers. As one Combat Engineer said, "Can Do." With the devaluation of the U.S.Dollar, one has to consider lifestyles of other cultures. The worst thing that could happen to the Owner/Investor is the giving back of profits to the Market. The only reliable solution for this is to convert to some other currency than the U.S.Dollar. I cannot help but think that Upper Management should be asking the question, "Should I stay with this firm? In this country?"
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.
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.
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.
If all your company does is make websites(or web 2.0, cloud computing or whatever the buzz word is this month) this might be fine. If the company makes a variety of applications for different purposes or targets, then this is a really bad ideal. The engineers attached to the project are the people who should be making the decisions about the tools and languages that are used to actually make working code. Management above the project level is to far removed from the actual work that will have to be done to be making that kind of decision.
I was thinking something similar; the hardest part of moving between projects is picking up the domain knowledge rather than the technology. Standardizing languages/tools/IDEs/etc does very little to address this.
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 bank. The bank had its own developers and their PHBs wanted to standardize on languages (C# in this case) so that our teams would be completely interchangeable. They had this pipe dream that if one of our team members was out for a couple of weeks that they could send up one of theirs to as a drop-in replacement, and vice versa. The problem with that is that our company was doing something completely different and a replacement wouldn't be able to learn the business processes quickly enough in such a short time to do anything useful. The PHBs acknowledged that this was an issue but refused to abandon the idea that someday, somehow, our teams would be completely interchangeable.
"Seek first to understand." - Socrates
If this is a major factor when ramping-up a new engineer on a program, then your application domain is probably so easy that your jobs will be outsourced to Albania soon anyway.
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.
http://saveie6.com/
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.
"herding programmers is like herding cats" --- I love it! First time I've heard that expression.
What's even better is the video.
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
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...
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
I love all the flame comments on these threads. Especially the assumption that management is stupid. Not that there isn't a reason for this perception, but the same perception exists that engineers/code monkeys are introverted trolls that never voice their opinions to management to help them make the right choice...
Anyway, being in management myself, (but having been a code monkey for 10+ years) I can understand the viewpoint that many here are taking.
But that's not what I wanted to reply about. That was just my flame-bait! Really what I wanted to say is that I have a pretty good idea why the original poster's company is thinking about implementing a common tech stack. First, they have probably been burned by one or more of the following:
1. A critcal piece of their system is written in an obscure/unsupported language that no one at the company understands any more, and even though they are willing to invest in updating it, the $ required to basically stay par with existing functionality is causing some heartache.
2. A critical piece (or even non-critical) of their system has been found to have used a non-licensed or too restrictively licensed library that no one realized until just now, and they are facing legal risks unless they re-engineer it out of existence.
3. The company has grown quickly and people now realize that there are at least 3-5 different code repositories on different source control systems and no one really knows where certain pieces are or which repository has the "latest" deployed version.
4. Projects keep spending time writing and rewriting the same component multiple times, aka re-inventing the wheel.
5. "Key/core/irreplacable" engineers insist on promoting NIH (Not Invented Here) practices which people in the company are starting to realize come for free in certain modern environments.
6. In an existing product, the company released a service pack to customers, but as part of the work, an engineer upgraded a library/ide/runtime/etc which caused huge instability, and the QA team didn't catch it because they were assured that it was a very minor release.
I'm sure there are more, but those are 6 things off the top of my head that have happened to me both as an engineer and as a management-stooge type. And while a common tech stack doesn't eliminate these types of things from happening, they can help give better visibility into seemingly innocuous choices that engineers make almost every day.
Most policies like this are because something bad has happened somewhere in the company and people are trying to limit future exposure to risk. Now, I'm sure as you're reading this post you're thinking that you are a damn fine engineer and these things would never happen to you. And maybe you're right, but are you better than the other people that are reading this post? While I'm sure that you are surely God's gift to the engineering world, not everyone in the engineering world is. People make mistakes. Maybe even you.
These kinds of initiatives aren't necessarily all bad if they aren't implemented in strict black and white. If they are used as guidelines that can be bent and broken for the right reasons, then it can be very beneficial. Even that process of getting permission to go outside the guidelines can cause good dialog to occur that can result in an even better idea to bubble up.
Whew. That was more than I intended to type. Go ahead and rip me apart now.
"It's a dog eat dog world, and I'm wearing Milkbone underwear..."
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.
Management see physical engineers using a relatively small set of standard tools (screwdrivers and wrenches) that they can easily carry around and ask (quite reasonably) why isn't there a set of tools for developers that is like that?
They make two mistakes
(a) Yes there is, it is called a PC and a Word-Processor
(b) A programming language is not a tool in the sense that they think of tools. It, along with req. gathering, project planning, and testing tools is effectively the entire engineering dept.
You choose the skill-mix in an engineering dept to suit the project in hand. The same should be true of the tools in the development chain.
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.
Developers aren't a commodity resource you can happily swap around.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Programmers shouldn't be reallocated at all, if they are it's generally the project manager fault: bad planning. Programmers shouldn't be reallocated, not because of the language, but because of the context. For big projects it might take more time to learn the new project than a new language/tools. Plan well my fellow project managers, you all know changes are harmful to projects.
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.
Don't thank God, thank a doctor!
Malarky. You must be pretty young.
I've been a professional programmer for 25 years. In that time
I've been paid to write software on many OSs, in many languages,
including....
OSs: AppleDOS, PRODOS, DOS, CP/M, TOPS-20, WANG-OS, VMS,
UNIX(various), Windows(various) SymbianOS, RIM-OS, J2ME,
WinCE, WinMobile, and others.
Languages: BASIC, Pascal, Assembler (3 types), Modula 2, C, C++, Java,
SNOBOL, Symbian (very variant C++), SAIL, and others.
Which is my favorite? Well not Symbian, but all the others
are fine. You pay me, I'll use it.
The inflexibility you describe is career death.
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 they're relatively layoff-proof since the alphas and betas would have probably seen the writing on the wall and already split. Meanwhile they've been around the longest and most likely to be productive... right.
Both of which argue for management moving people around. It gives the alphas room to grow and they don't feel like it's professional suicide to stay, and it kicks the deltas out of their nest so their new projects can identify them as deadweight that needs to be trimmed.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
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'.
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 parsing built in, he had to hand-code his own. The result was temperamental, consumed vast amounts of maintenanced and didn't support many RTF features. But he was insanely loyal to it, and resisted switching to a more common scripting language to the bitter end.
Another co-worker at my current company wrote a bunch of tools that we still use a lot. Basically, he wrote them in Perl. Except Perl wasn't expressive enough for him, so he wrote his very own preprocessor. And it's a beautiful piece of work, his Perl code is very concise. (Brilliant guy, really.) But he never documented the thing, and he doesn't work here any more, so if any of his tools need maintenance, we are SOOL.
Programmers need to get over the idea that they can do every little thing their own way. Your employer's role is not to provide you with a playground for you to do things the way you want. The company needs to sell stuff, and has hired you to make that stuff. Yes, it's a creative job, and you need some leeway. But if there are no rules or standards at all, then everybody's working at cross-purposes and nothing useful gets done.
I've worked at software companies where this was the case. Very unsatisfying places to work because at the end of the day, you really had nothing to show. Plus you spent all day battle everybody's ego trip. That's my idea of workplace hell.
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.
Contrary to the popular belief, there indeed is no God.
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.
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.
demi
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 projects, and replace them when they eventually leave that drives me nuts.