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.
I think it depends on the size of the app. Small and maybe mid-sized businesse apps would be able to get away with such a requirement, as their apps will probably not be pushing the limits of modern computers (and hardware upgrades are cheaper than software optimization). Enterprise apps should probably be done with the best tools available.
No comprende? Let me type that a little slower for you...
Someone already tried that whole "One tool to rule them all..." bit. (Just remember, the last guy died)
You. Lose.
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
If management insists on standardizing on one language it will likely be something like Java, C#, or Python. These languages are jack of all trades, master of none.
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.
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.
Are these all greenfield projects, or is there code maintenance of existing projects? If there are existing projects in various languages that need to be maintained then how does it really help to standardize new development since you're already maintaining the skillset around those other programs. Also what languages are any large third party apps written in, for instance your CRM, ERP, etc platforms. Sure most now support web services, but are you on a version that does? Oh, and does a significant enough percentage of your staff have mastery over one language so that you won't be wasting resources while everyone ramps up on the new standard?
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
It seems a bit restrictive nowadays. For example, you could use the same framework and features in every project but use a different syntax, like the .NET Framework can be programmed through C#, VB.NET. J# and 50-odd other languages meaning people can actually leverage their existing skill set instead of learning the "one and only" skill set.
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!!!
Common development practices result in increased productivity and easier training for employees. The result is decreased flexibility (especially when new projects are evaluatedand) and long-term success. If management thinks they have a great thing going, good for them, I hope they don't run it into the ground, cuz they could kill any long-term momentum they have going.
So, it comes to this.
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
After some number of features implemented most time is spent on maintaining those compatibility layers and not implementing core logic. Code monkeys breed, creative people become bored and leave.
Personally, I think your company is doomed, long term at the least. More nimble competitors will end up eating your lunch, while you end up saying "me too!". I've seen this before, alas. Monocultures are always brittle, and too frail if hit in the right direction.
There are two schools of thought as far as management goes. The first is that managers are all knowing, and send down orders from "on high". That the minions must faithfully implement.
The second school is that managers help and support their engineers on the frontlines. They provide overall, general goals and guidelines, and let the engineers do what they're being paid to do. Part of that is making the right decisions as well as implementing them.
The best managers look ahead at what their engineers will be needing in the future, and make certain that they have that when they need it.
It sounds like your "upper" management is of the first school, and don't realize that software development isn't a factory.
Good luck recruiting top engineers to work for you. Something tells me you'll be facing an losing battle there, as it sounds like you're doing your best to drive them straight to your competitors.
Choose the right tool for the job.
Caveat: C# is not the right tool for any job.
everyone knows programmers have become fat lazy pigs. It's time for a return to the old days of squeezing out the maximum performance and proper utilization of resources...
I think it's time for everyone to go back to assembler and stop being so lazy... I say x86 assembler since everyone (almost) is using PCs anyways, it's not much of a stretch
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"?
It really depends and unless you have a very good dev management you will need an architect to make those decisions.
Sounds like a way of slowing development
It only makes sense if all programs the company develops are able to fit the same cookie-cutter and do it well.
You are in effect forced to choose a language and framework that is mediocre, but suitable for everything, rather than a language that is preferred for the current need.
Basically, it pretty much means you are probably forced to pick Java or C# and .Net.
Since some apps are sure to need a higher-performing, compilable language.
It's just mismanagement of development given a 'feel-good' justification. Since the mediocrity of any choices that will be suitable for a wide variety of applications, means every program will need many more 'utility functions' and classes not provided by the standard API.
Every application will need its own set of complex APIs, that developers have to learn before they can start coding on that application.
Either that or you wind up with one hideously-large bloated "framework API" that all the programs use.
The fewer application-specific tools the framework and language provide, the more of those tools will be specific to the application and have to be developed by hand.
(And then learned by developers before they can start coding on that project without breaking things)
The best language for one product may be a terrible choice for the next product.
A certain PHP framework may work extremely well for a certain type of web application -- and allow it to be developed in a few months, instead of a year.
Of course, cookie cutter frameworks only work well for applications that fit the mold.
One application may take 2 months in framework X to write, whereas other different applications may take a year to have written, just because of the framework.
Also, while PHP may provide acceptable performance for a web application, it is not acceptable for a desktop application.
Scripting languages are unacceptable for certain types of high-performance applications.
Compiled languages like C, C#, or Java are extreme overkill for a majority of web applications.
But using a common framework leaves no choice, and there will be much suffering.
There will be even more suffering if you can't write Makefiles or Ant build.xml files, and instead have to write your build procedures in java, because "java is the standardized language we're using"
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.
The point is that there is a cost to having a multiplicity of development environments. It makes it very difficult to move developers to other projects, and thus tends to increase headcount. Uncontrolled use of technology means that developers can implement systems with little oversight from other developers, as other developers do not have the skills to do proper review.
I am not saying that we should decide to use only one language, but a small subset of languages and skills seems to be able to get most jobs done. Supporting languages and tools needs to consider more than just technical considerations. What is the availability of skills in the job market? What kind of vendor and community support is there? What kind of productivity can be expected? Will the technology be supported in future, or will we be left with a white elephant?
Part of the best tool for the job is one know by other people at your organization. If you get hit by a bus, somebody needs to take over your work. If the first thing they need to do is learn a new tool, it slows down the ability of your replacement to do the job. Furthermore, you will have a lot harder time discussing problems if you are the only person who knows the tools and language.
That being said, having a variety of tools does have its benefits. The big one is learning good ideas from one and applying it to others. Some tools do some jobs better then others (manage a large amount of data in flat files with C vs SQL DB).
These need to be balanced. Developers should not just bring in the latest tool they heard about into a major development. New languages and tools should be evaluated and tested on side projects, then if they bring sufficient benefit, incorporated where appropriate.
At my company, I watched (and fought against) a developer who brought a new tool in on his whim. He made incredible claims of the benefits while ignoring that nobody in the company knew much about the tool, including him. What he thought he needed and what he actually needed were two very different things. The interaction of the software he developed with the rest of the system caused massive problems. Unfortunately he was allowed to do all his development in isolation, prior to the rest of the system being in a state that could interact with his part. He declared his success, finished the project, and left the rest of us with the mess. Nobody wants to support the software he wrote. None of the benefits have been seen. Management does not want to pay to re-develop the software. It is a bad situation.
A one size fits all approach is usually a business decision to save costs rather than apply the most appropriate tool for the job. Your management is going to find that they will be able to address each project but they'll have the same type of solution bent to fit the problem. Good luck with that!
http://www.gibby.net.au
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...
It can be a good thing if implemented properly. If you have several equivalent applications/IDEs/languages then trimming some out is very helpful. ... sure you exploit the best area of each but when debugging or maintenance comes around it's a horrible, disjointed mess of spaghetti. (In the above case I would do everything with a good php framework) ... If you can find one that handles everything you need, go for it.
For example no need to use perl, python, and php for a web app, just do everything in one. I've seen some setups where you have php rendering a page, perl doing some text parsing, python as a script glue *shudders*
As far as IDEs, you may get little 'weirdnesses' like whitespace not aligning right, peculiarities with a SVN server, etc
On the other hand, nothing sucks more than needing a particular tool and it not being available due to some stupid policy.
If you need a particular tool because no other is suited for that purpose, then use it.
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!
...is don't f--- it up.
Managers who come in and immediately institute sweeping changes are usually gone just as quickly was they arrived. What you are talking about is a strategy, not a mandate from a king on a throne. A strategy is something you move toward that guides your decisions. So maybe you standardize on two or three standards that can be used, and you get much of the benefit that way. But then again, if this is all about upper management's ego, then only one standard will do, of course.
And finally IT is not a plug and play commodity. If your IT department sucks, it is not because you need to standardize on a development environment. Maybe the company should "standardize" on hiring intelligent, qualified people and "standardize" the HR policies on paying them what they are worth.
I Heart Sorting Networks
Your workplace is probably about to go to hell. So why not have some fun with it?
First off, update your resume. This is perhaps the most important step herein.
Next, recommend tools that are as bad for the job as possible while still not raising objections from your colleagues, or better yet, get them to go along with it.
Watch it fail utterly, quit in disgust, and watch as the company falls apart. ...
Profit.
... Application Maintenance!
The biggest cost for any enterprise application is not the cost to develop it but the cost to maintain it. A company may spend a million dollars to develop an app, and then spend that much per year to keep it running, add enhancements, test OS/DBMS/AppServer/etc patches.
So by standardizing on a common set of tools and frameworks, the company can train all of its incoming staff on these tools and be able to deploy them where needed. It then allows the company to move staff among the various projects as needed without incurring additional costs to train on a new set of tools/frameworks/etc.
So, with this approach, you will never get the best tool to fit the job but you should end up with an adequate toolset.
Thus sprach higg.
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.
Well of course you should all be on the same version of Visual Studio.
What... theres something else?
If I had a DeLorean... I would probably only drive it from time to time.
Management should strive to enforce a policy in which projects/code are checked out and built with a minimal set of compilation tools. i.e. javac, gcc, etc. libraries, dependencies included. "Development Environments" have clouded our view of simplicity. I do believe that a company should provide a standard base image so that developers can get up and running, but the real issue is eliminating the dependencies of IDE's and tools that people have grown to think that they need. I believe I should be able to check out a project and build it with a minimal amount of effort. Further development can take place with whatever tool I choose. Its about code independence not tool dependence. As for choosing the language... This is a hard fight unless you are an architect. Companies will usually dictate this.
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.
I might be wrong (am sure some Slashdotter will enjoy correcting me in this), but the difficult part of moving between projects is not differences in language. It's differences in the mindset of the who wrote the existing code: the naming conventions they use, any nomenclature specific to the project, what classes are responsible for what functionality, etc. Learning all that malarkey is the difficult part.
Obviously extremes are bad, if your company is using tens of languages, you might want to start looking at ways that can be slimmed down. However I would argue that choosing a small group of languages that complement your core business is preferable to attempting to shoe-horn one language into doing every job.
Think of it as being like reading books by different authors: Java is Virginia Woolf, and PHP Charles Dickens, a book is like a chunk of code. Both authors have different writing styles, but anyone can still pick up a book written by either of them and understand the words written within.
What the PHB's in your company believe, is the difficult part of understanding the storyline in a book is getting to grips with an author's writing style. So everyone should standardise on one author to save time. The reality is, people will get to grips with a new language within a few pages, but won't understand the concepts of the whole until they've read most of it.
I know: most borked analogy ever. But hey, I'm bored of hearing about cars. :)
Man... if my company ever made me move out of VIM as my editor, just for the sake of standardizing tools used, I would show them just how insanely it impacts my time. Then I'd quit. Working for incompetent management is hell on earth.
What these uppers need to realize is just how valuable a talented developer is, and give them good reasons for staying (and cleaning up the garbage). It's not a f***n factory... not everybody can do the same job in the same way. Lower management can help them realize that. That's the only way you'll get the job done more efficiently.
I hated it, having to support it as one of the infrastructure engineer, but Domino pretty much did everything, in an OK manner.
Our main developer was the head corp attorney, who decided he hated law and started working as the IT dept in the company. He learned Domino out of necessity, as the new CIO brought it over from the financial / insurance arena.
I hired on about a year / year and a half into the migration from MS Mail / BS apps to Domino. I stayed for about 2 years. Everyone that did domino dev talked big shit about it, but they all agreed, at the end of the day, it pretty much did EVERYTHING the company needed, in an OK manner, and did more in a lukewarm way than anything else could come close to delivering (read this as, it will do almost anything, although it might not do some things the most efficiently).
I don't even know if it is still around, but I'd check into Domino / Notes / etc. I hated it, we all did, but it did work. We even started collaborating it with stuff that HAD to run on OS/2 (Timberline) and some stuff that had us running Win 3.11 on some workstations (post y2k).
YMMV, of course.
--Toll_Free
Upper management also decided to removed everything but a #2 phillips bit from the maintenance departments toolbox citing the rising cost of supplying 4 different kinds of screw drivers.
in blue and black trunks we have the MS fan boys with their fat manuals and their Vista-bruised ego's. On the right in the rainbow trunks we have the OSS junkies with their man pages and up to date Firefoxes. Let's get ready to rumble!!!!
Winkey shortcut mapping for 64bit windows. WinKeyPlus
And not because of the particular number of languages. It's the thinking behind it: that programmers are just commodities. The idea is that if we standardize on, say, Java - that we can just replace one Java programmer with another and there are thousands of those on Monster.com. This type of thinking betrays a deep misunderstanding of development and if your management doesn't get this now, someone will have a lot of educating to do. Either way, I'd rather have a route canal than work there.
If everyone at your company is doing similar enough thihgs this should work out OK. I doubt you will see any bump in productivity though.
However, languages are tools. Like carpenters, software developers should use the right tools for the right job. Forcing everyone that's building your house to use exactly the same kind of hammer for every task doesn't give any benefit and will result in worse, not better, construction.
The idea of a homogeneous environment is attractive -- it is obvious why management would be interested in this. But it probably will not succeed, or if it does it will hurt your company.
It will be costly, as your company goes through the inevitable investigations, debates and infighting to try and choose a plan. Then come the struggle to port every product to the new environment; during which time you won't be adding features. But once you actually get everyone on the same platform, you are not done.
What if you acquire another company? Will you port that technology to your platform? That is likely to be even more difficult and expensive.
How will you upgrade your processes? No piece of the system can be replaced unless it is feasible for every part of the organization. I guarantee there will be some nasty old projects that will hold back everyone else. Every toolchain decision will have to go through the CIO. I hope they have a lot of extra time.
In sort, while your company is navel gazing, your competitors who aren't locked down will running ahead.
A foolish consistency is the hobgoblin of little minds.
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.
In most enterprise applications you'll be using multiple languages whether you like it or not:
- A multi-purpose high level language for n-tier apps (data access, domain logic, presentation): Java, C#, Ruby, Python
- A database language: SQL
- Web interface (if it's web-based): JavaScript, DHTML, Flash
- Integration and Middleware: XML
As long as you're within one product boundary, one general purpose language is the way to go. Across products (from same vendor or from different vendors): different languages + well standardized protocols (XML or binary serialization) is the way to go. Mixing more than one general-purpose language in the same product is usually a bad idea IMO (unless the languages share a common framework; e.g. C# and VB.NET)
The thing that ties everything together, whether using one or more languages is the development process and tools:
- Source control (SubVersion) -> provides change tracking, branching, merging
- Automated build environment (Ant, NAnt) -> can build code, database, tests with the push of a button
- Continuous Integration (CruiseControl) -> detect and fix integration errors early
- Unit Testing (xUnit) -> ensures predictable behaviour in the face of code changes
- Bug tracking (Bugzilla) -> track defects, plan fixes
- Documentation (Wiki, DocBook, code comments) -> inform your peers of your public APIs (i.e. how they can use what you have written), and possible extension points (how you can use what they have written); inform stakeholders how the system works (concepts, architecture, business scenarios); inform your users how to use your system properly
A good project manager ties everything together and keeps everyone on schedule.
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.
Does it mean that if all engineers in the World use Autodesk CAD for their jobs - it would be easier to put buildings architect as a part of space ship architectural team, then?
I mean - are the tools really critical here? Hardly, IMHO. The problem the team working on is the most critical thing. Tools are tools and are changing still, we have to accept this. Changing the tool (to some degree) is peanut compared to changing (business) problem You are working on.
Also, please send Your management copy of DeMarco's "Peopleware" copy... And hopefully the will finally know that developers ARE NOT INTERCHANGEABLE, whatever You will try to do.
The church of flying spaghetti monster:
http://www.venganza.org/
That and make everyone on earth speak Latin... I'm sure it will all work out somehow.
-M
Find a new company. And let us know which, so we can divest. Stock symbol? Riddle? C'mon.
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
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/
It depends on the situation. What sort of company? What size?
If everything you do is web, then standardizing on [PHP|Python|Ruby] for all your web stuff makes sense. They're all close enough functionality-wise, and it will make mixing and matching your code and coders easier.
Similarly, doing server-side programming sometimes in C#, sometimes in Java is probably wasteful. They're both close enough in their approach and capabilities that having to learn and remember both is wasteful.
Standardizing that you'll use [C#|Java|Python|C++] for every line of code written? Nonsense. That's over-standardization. In at least some cases any one of those is going to suck royally.
Standardizing your source control system? Definitely a good idea, unless you have to interact with a 3rd party open source project that is using something else. Even then, you should use just one for all of your internal stuff and then make sure someone knows how to use whatever the 3rd party uses. (I suggest svn myself, but some people prefer distributed RCSes. Pick what you like.)
Standardizing your IDE? Only if you want to make 2/3 of your developers less productive. I can see an argument in favor if you are paying per seat for the IDE and want to only have one vendor and site license to deal with, certainly. But if you're paying that much for an IDE, you need to switch to an open source IDE anyway. :-) At my company we offer a standardized IDE for all programmers, but half of them use something else at least half the time. That's fine, as long as they get the job done.
Same framework? Same argument as language. Within a given realm, sure, it makes sense. Use one, or maybe two, frameworks for your web stuff. Use one for your desktop stuff. But don't presume that you MUST use that for EVERYTHING. Just make it your first choice to try, not an absolute mandate.
So it's all about balance, and picking the right battles. There are benefits to standardization as long as you don't over-do it and create a monoculture.
--GrouchoMarx
Card-carrying member of the EFF, FSF, and ACLU. Are you?
Management is deluding itself if it thinks the use of a standard set of tools will make developers more portable.
The learning curve for a skilled developer lies in learning the ins and outs of the application being developed -- not learning the development tools.
When you transfer a developer to a different project the first thing you do is give the developer some programs to look at so they can figure out what is going on. I'll grant that if you give a visual basic programmer a java or c++ program he/she may be a bit slow for the first day or two, but (assuming a skilled developer) he/she will come up to speed in the new tools very quickly.
Much more quickly than he/she will develop a full understanding of the application.
Gosh, this is a great idea. I'm sure you'll save so much time you'll have plenty to play whole round of golf with a 7 iron!
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.
There are advantages in using a common set of tools across the board. It eliminates a lot of effort when people switch. Unfortunately it also eliminates innovation and creativity and it treats all people like androids who think and work the same way.
"herding programmers is like herding cats" --- I love it! First time I've heard that expression.
What's even better is the video.
least common denominator engineering. Wonderful idea, its up there with outsourcing American engineering to India.
Call it $COMPANYNAME.build or similar, and just have it as some way to bundle all of the assorted tools that everybody needs. Extra points if it's a ghost or similar deployable disk image. Addition of any extra things that were not initially thought of can be argued as an upgrade.
That's really really funny!
I nearly shot dr pepper out of my nose.
Sign me up if you need an evangelist to do an engEDU-style talk.
If your upper management is telling the engineering management HOW to develop software then your company/organization is screwed. If your engineering management is going along, then you are beyond screwed.
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.
The only problem with "one toolset" is picking the set of tools to be included. If people are suggesting tools that are new or had major changes in the last year or two then you're probably screwed because people are just heat-seeking to the latest trendy tool chain.
Any set of tools you pick is going to look pretty hairy in a couple years, and to be worthwhile a "one toolset" initiative really needs to be stuck-to for 5-10 years in a typical business environment. Anything less and you might as well just pick a new toolset for every project, since you're not going to get the benefit of standardization except over a long period of time.
So my recommendation when people suggest this is to require them to pick a set of tools that existed two years ago, and restrict versions to things upwards compatible to what existed then.
When forced to go through this exercise people tend to go "ewww, who wants to use that old stuff", but that's exactly where you're going to be in a couple years, and you need to be sure you're not using the "one toolset" initiative as a way to sneak in someone's idea of what this year's sexy hot new tools are.
The trick is sticking with your choices long enough to get the benefits, and not just abandoning them as soon as the downsides of your tool choices become apparent.
In general I think there's great benefit in making a "one toolset" decision, but only *if* you can actually stick with it through all the eventual pain and suffering. But I've never yet seen anyone (voluntarily) achieve that. If you try this then best of luck, and try to get buy-in from the people who own the company, not just the IT director of-the-week who might leave in 18 months and get replaced with someone with totally different ideas.
G.
One of the basics of the UNIX philosophy... Distrust all claims for one true way.
There is C++, Java, and Python. Almost everything is in those 3 languages.
Sure, there is a lot of javascript for the web apps.
And of course http://labs.google.com/papers/sawzall.html is used for processing logs.
Oh and a bunch of people like bash scripts for various things.
And there are loads of domain specific languages for RPCs, data files, AI systems, etc. etc.
But if you need continuous remote unit-test support? Use Python, Java, or C++.
Want 5 minute distributed builds? Use the big 3.
Find a compiler bug and need it fixed ASAP? Big 3.
Want to integrate with other parts of the Google code base? B3!
Need an expert to sort something out? You get the idea.
You can standardize on a base toolset, but you can't exclude the right tool for the job. It's a simple cost/benefit analysis: If the benefits of using a particular tool out way the costs of straying from the beaten path, go for it. Otherwise, it doesn't hurt to standardize.
http://brandonbloom.name
You've already stated the key tradeoff: developer mobility vs tool leverage.
If you have many small projects, then it's a huge win to standardize on one tool. Tool leverage won't help much, but having to swap dev platforms frequently leads to bad code (little experience with a single tool) and high overhead (for learning the tool).
For larger projects, some specialization should be considered. Even within (for example) the Java stack, different teams could use different APIs (e.g. JBoss vs Spring) for their specific tasks. As long as you have a few people good at integrating them when needed, you'll be ok.
The larger the project, the less a factor the tools are vs the sheer mass of the project. Then advantages brought by tool selection should be considered carefully.
Care about electronic freedom? Consider donating to the EFF!
Not that I would force it down anyone's throat, but two languages should do for most jobs: One loose and fluffy scripting language and one tight and hard compiled language.
The choice is simple, really. The tight and hard one must be C (or C++) because of its total dominance in its domain.
The fluffy one should be JavaScript (don't laugh) for at least two reasons: 1. Some part of your organisation probably has to deal with JavaScript anyway and 2. JavaScript's syntax so closely matches that of C that it is possible to automatically generate completely transparent wrappers for absolutely any C function.
So that't what I've been up to on my spare time for the past couple of years: http://jsext.net
P.S.
If you don't take JavaScript seriously as a programming language (most programmers don't), you probably haven't watched any of Douglas Crockford's talks. Check them out. They're online.
Let me translate the original post so non-programmers can understand it:
"Upper management at the car garage I work at recently declared that all car repairs should be done with a single tool. The main rationale is that people can be relocated from one car repair project to another faster, because they don't need to learn a new environment when they switch. Of course the tool 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 repair tool for every repair 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' mechanics will be forced to use?"
"Management standardizes that which they do not understand, to relieve them of the responsibility of having to think about it any more..."
dave
And now they're trying to push their god damn "framework" on the organization, and management buys into it because the product they support is such a success! It's bullshit. At all costs fight it. Settling on some ridiculous "framework" (most especially one built in the company) will kill your innovation and ability to be agile. Fight those fuckers.
PHP + Symfony + Aptana + MySQL + Subversion + RSync + Gimp The open source swiss army knife!
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..."
The new languages I see making inroads in the enterprise (yes, I'll just say it: groovy and ruby, etc.) are major sell-jobs for consultants and niche employees: see how quick I can whip this up? And if you can't refactor it and no one else gets it, that's just great for the guy mining this vein.
What's a poor manager to do?
I think they have eliminated the reasons why people become good programmers.
and put it together with 47 different kinds of screws.
One organization should standardize. It makes sense.
There is no such thing as one size fits all.
Focus on process and your tools will standardize themselves to a sufficient degree.
Try this: For each type of application, standardize on a platform for the production application -- OS version, language (compiler, libraries) version, database version, hardware platform. You will then develop a natural movement toward standardizing the build environment to the extent it makes sense.
Like it or not, people will specialize. Maybe you'll want to move them around occasionally to minimize ossification, but keep in mind there is a reason that people specialize as DBAs or web app programmers or sysadmins. They all involve programming, but aside from that the disciplines don't share much. Many folks will naturally straddle disciplines -- use that to your advantage.
A heterogeneous dev environment will help iron out your code, so let developers pick their platform. Just make sure to have a *process* for releasing code to users. You know -- QA, branch, staging, release.
Beyond that, let people work how they work best. Never touch the editor preferences or you will see a sudden increase in carpal tunnel issues.
If you've gone so far down this road that one programmer is the same as any other programmer, you're screwed. Sharpen your resume before your title gets changed to "programming resource IV."
In my opinion, there is no ideal process, tool and language. It always depends on a lot of things like type of customer, software/hardware architecture, expected team size, etc. I've seen a lot of companies trying to standardize on requirements and/or software configuration management tools but failed because they were unable to unify their process. Small teams work differently than large teams an usually require a different approach. Project managers should analyze their project and choose their process and tools on beforehand. Experienced developers, architects, requirements, test and configuration managers should advice the project manager and make a decision in best interest of the project. In my opinion, that would be a good foundation for a succesful project. Standardizing on one process, tool, modelling or programming language would just be stupid since you would restrict your company in their ability to optimize their productivity and quality.
If you only have a hammer, all the world is a nail.
Ever tried hanging wallpaper with a hammer ?
You could I suppose.
This sounds like the road to destruction. Once higher management starts making rulings into basic operations you should be alarmed. You should probably try explain to management about the term in CS called "Mystical man month" and why trying to create interchangeable resources won't work in the way they imagine. Somehow I get the idea from your post that your management tries to create the seemingly perfect environment (in their perspective) for developing software tool wise. It is hard to say can this be accomplished without knowing what kind of sw business your company is into, but in case of enterprise software i doubt this possible. In embedded software maybe? As one reply in this chain already pointed out the thing that management can and should focus on is the development process. Having appropriate and efficient processes will let developers more easily to integrate into existing teams and starting new teams, the tools are just something that can be homogenous inside each team. Creating some ready tool frameworks for possible project scenarios might be useful to help quickly start projects, but projects should be allowed to choose and tailor the best environment for themselves. Decent programmers shouldn't be limited to any one language or tool and not willing to learn anything new. CS in general develops at a fast pace and this means so do programming languages, related technologies and different IDEs.
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.
The obvious answer is to choose a "best of breed" tool for each class of problem. Otherwise you'll end up writing device drivers in Javascript. Or browser scripting in C.
My employer is very much a "Microsoft shop", and C# is the tool of choice. But bear in mind that across all the projects that we bring C# to bear on, knowledge of the following is needed:
C#
SQL
HTML
CSS
Javascript
XML
WPF
MSBuild
SOAP/WS*
My Karma: ran over your Dogma
StrawberryFrog
I think one of the most important aspects of Software Engineering - and Engineering in general - is to choose the right tool for the task. There is no silver bullet in Computer Science. There is no "one size fits all" platform - every platform has its own set of advantages and setbacks, and its up to Software Engineers to decide the "least worst solution" to stick to. Sticking to a single platform is going to lead to wasting resources since the company often won't be able to use the best available solution.
Also, it is going to seriously decrease the technical elasticity of the company; most of the trendy platforms out there today, like Java or .NET will become obsolete eventually, and the migration to a modern platform will really hurt if the whole company is tied to a single platform.
In one line: This is the stupidest thing I've ever heard. (Bill Gates)
If you are an all Microsoft shop and intend to stay that way, then use the MS tool set.
If you have several different platformas to support then you may may want to look at something like Java/Eclipse.
I also think whatever setup you choose you will have several "languages": Java, SQL, probably a scripting language like Javascript, Flash, a reporting system, something to pull data into management reports or Excel eg VBA etc.
So I guess I would have to say that one language is impractical except within a particular limited scope eg Website serverside, website clientside, management reporting, database...
Seriously, depending on what kind of company it is and te focus of the project types.
.NET server environment or a proper Java server environmnent. With Java, maybe toss in some cool tech like Google widgets or another "Web 2.0" technology.
.NET SDK and Qt both are very good for this purpose.
In my company for example, we would have to standardize on C with some cross platform GUI system like GTK+ and intially development time for every project would be inflated 50 fold over a more intuitive system since training time would be substantial and we'd have to let go a lot of junior developers that never learned how exactly object oriented languages work. Oh, we'd probably need to use Intel's compiler since then full x86 assembler would be supported.
In a company that develops retail products which should be able to run on different platforms, I highly recommend C++ with Qt as it's the only polished environment for end to end product development I've come across in 16 years of large scale retail software development. Of course, getting locked into Nokia might be an issue.
I a company that does no low level development, I would highly recommend C#, Visual Studio, Subversion, and the full kit, or Java with Eclipse and Subversion. It's a judgement call there. C# is generally a better system for Windows application development since the UI system is focussed on Windows... but it works on other platforms. For Java, even if you program with SWT, the look and feel is never quite right on each platform. So it would depend more on wht kind of developers you have and what your platform needs are.
For a company which does nothing but database work, I'd still suggest the previous two options and add either a proper
I personally would try and get TrollTech Qt or Visual C# into the system since I am a big fan of short time to market and
I wish you luck whatever you choose.
Sounds like the guy is a net drag on your team. It also sounds like your boss is either blind to the factors that make software teams effective or is so reluctant to have a difficult conversation that (s)he puts up with a woeful situation rather than fixing it.
Suggestion: implement test-based development. Have regression and unit tests for code. Implement a policy that commits breaking the build will simply be rolled back by the "build cop" (ideally it's best if someone else is the build cop since this defuses the interpersonal aspect of the issue). From what you said, I would guess that the guy who doesn't commit frequently is going to find that all his giganto-commits are rolled back because they cause breakage. The pain of the poor practice is therefore felt by the person with the poor practice, not by everybody else. This will put pressure on them to improve their practice in order to meet their goals/deadlines/whatever.
You might understand e.g. the GNU tool chain backwards, sideways and upside down but still be totally at a loss moving from a nice clean project to a cookie cutter one. (closes eyes and thinks of all those one line shell scripts on a project I picked up ages ago).
In any case, expecting to hot desk developers from Project A to B with instant results is totally totally insane. Go make your managers or PHB read Brooke's (still relevant even today). Programmers (even the code slaves) are not cattle.
Unless the projects are very closely related in philosophy, style and substance expect anyone moved to be unproductive for at least 2-3 weeks.
It gets worse though. There is a vast army of Sheeple programmers out there who only know one tool chain, won't learn anything else, and depending on the range of tools you now use you may be faced with the cost of re-training (or major use of throwing axes).
Andy
This thread is a bunch of blaming managers for making bad decisions limiting toolsets, that developers should be able to use whatever they want. What about operational impact and maintainability? If different components/tiers/layers of your app are written in different languages, any new developer will likely need to understand all of the languages and be familiar with reams of library documentation before getting any work done. It is true that a good programmer should be able to program in any language, but in order to be useful and efficient, that programmer needs to understand the libraries that come with that language as well. It's a huge waste of time to make everybody learn more sets of languages than absolutely necessary to get the job done.
The other problem is operational; in the worst case, you will have people writing apps in different versions of software. I remember once I worked for a company where this one guy wrote an app in PHP5 (developing in a vacuum). The servers we were supposed to deploy it on ran PHP4 and were running an old app that hadn't been tested on php5 (and didn't work on php5). Is it really worth the setup and configuration nightmare of installing another apache, setting up new libraries, etc, that would be required to run both versions of php at the same time, or would it have saved time to standardize the platforms? Also, what happens when different programmers use different versions of modules (say Perl modules) which implement different features? Standardization there is very important too.
The last problem I'll bring up is maintenance; so you let every engineer program in whatever language they feel like. Does anybody realistically think that these new languages-du-jour like Lua, Factor, Groovy, and what have you will actually be maintained in 5 years? Is your code that throwaway that you are willing to wager that it will not be in use in 5 years?
So there is a lot of pain, and the only REAL gain is a little bit of developer pleasure at being able to geek out the way *they* want. Unless the management is REALLY incompetent, they will define some standard languages that make sense, and everybody will be able to live with it. A good programmer can pick up any language relatively quickly, but even a mediocre programmer can usually get the job done in the most common languages.
...like they're really in control of things, right?
Every company I've worked for thought of that one. They enforced it in the coding standard. Same reasons you cite...always. And always, they build a team of generic code monkeys that only know and work with one language, and by extension, they get too specialized.
Then, one day, a salesman gets a customer that really needs a piece of software written that integrates with some device...and the company can't turn it down because they need the business. Then, generic (company standard) language programmer Jim finds out that the device doesn't have a compiler written that compiles to its platform, so the company ends up hiring a guy who specializes on that device and its platform.
Whoops. Just broke the standard. No biggie, it's just a short term deal, right? Well, not always. They might get more work on that platform. That platform may open doors to work on other platforms...at a catch. Their "corporate standard" language suddenly can't be enforceable or it would directly cost business.
I think the last 5 contracts I've worked have all been like that. And I'm EXPENSIVE for short terms. It would be cheaper if they had salaried people on hand that were more experienced with multiple platforms and languages (like me!). I always was brought in to work with a language that wasn't the corporate standard...and the corporation looked the other way. Which makes that standard silly because the code I wrote would have had to be maintained by me or by one of the code monkeys who only worked with the standard language. It's better to set a priority for languages, if platforms can't do the top choice, try the second, third, etc. rather than force down a single language.
"We're going to standardise on [insert favorite desktop application platform/framework] for all our desktop application develompent unless there's a strong technical argument for using something else" might be sensible.
"We're going to standardise on [insert favorite DBMS] for all our server-based SQL database work unless there's a pressing need to use something else" = fine.
"We're going to standardise on a single combination of development tools, language, and framework for absolutely everything" = we're not sure what a "framework" is but the salesman was very persuasive and had a nicer suit than our senior software engineer - so we're going to spend a shitload of money despite the objections from our developers and then go into denial about any problems. Update your resume now.
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
this is a great idea with everyone running exactly the same framework it will make it much easier for virus writers
think I'm wrong - look at windows....
I think it all depends on what the company does.
If they are a web application development house, then they could, feasibly, decide on PHP, or Java, (or C#/ASP if their clients all use IIS) or whatever and all would be fine. If the company has a narrow range like that, then I'd say you'd probably be better choosing one set (eg PHP) than having several, with each developer choosing their favourite (one uses PHP, one uses Java, one uses ASP, one uses Python, one uses C++ etc)
But if they are a general purpose software house which does all sorts, then, try writing device drivers in Java, or web applications in C/assembler and good luck with that... Pretty much the only language which could do almost 'everything' would be C (you might need assembler for some things, but that might be going too far) and using that for everything would drive productivity through the floor.
OTOH, to a degree, slavishly using the 'best' language for the job can cause problems. Sometimes the weighting of developer familiarity & experience into the 'what is best' equation is ignored. For instance, if you need to write a quick utility, and the only developer you have handy is a web developer, then it may be best just to use PHP, rather than teach that developer how to write in C++.
Each job really has a range of languages that could be used for it, the actual "best" to be used to do that job by one group of developers may be different from the "best" used by a different set of developers (assuming "best" means "getting the best productivity, accuracy and reliability" rather than "having the language features which most closely match the job requirements")
"get out of there it's gonna blow!" "Master, master, wheres the dreams that Ive been after? Master, master, you promised only lies Laughter, laughter, all I hear and see is laughter Laughter, laughter, laughing at my cries Hell is worth all that, natural habitat Just a rhyme without a reason Neverending maze, drift on numbered days Now your life is out of season" [fade out with evil laughter].
There is paid software on the desktop - It is a poor financial decision because it does not make sense to pay for licenses not being used. Unless you have floating/site licenses for everything (unlikely).
All development tools are free - create a minimal standard set and provide freedom to developer to add more.
In principle, the idea that languages are tools for the programmer is good. I would not go to a mechanic who claims he will solve all my car problems only with his favorite wrench.
To a man with a hammer everything looks like a nail.
O this learning! What a thing it is - William Shakespeare
I am currently taking a project management course and this is the stuff that they are pushing. It might not be a perfect solution for every job, but will overwhelmingly save the company money. A particular job might take a bit longer, but it's a helluva lot shorter than training someone.
Programmers are like the old Tareyton Smokers
Given: Most programmers love one programming environment and hate all others.
Given: Most programmers, working in the programming environment they love are more productive than they are in all others.
Given: Most programmers, confronted with working in the programming environment they do not love, will spend a lot of time arguing with everyone trying to switch their project to the programming environment they love.
If managment decrees, we are a Java shop, do not hire ANY programmers who love C#, even if they could program in Java, you'll just get a religious war and a huge amount of wasted time.
The whole 'right tool for the job' argument is only appropriate for about the top 1% of programmers. The vast majority picked their favorite tool at some formative point in their programming life and are not mature enough as human beings to move from language to language over time.
I'd say, if your programming group has "upper management" then its large enough that everything is doomed in the first place, so if you don't want to work on projects that will fail to produce something useful 50% of the time and be despised by your customers 100% of the time, RUN SCREAMING from this workplace.
WHEN you work on project teams with more than 5 people and you have no interaction with the actual people who will use the software you write, THEN your project is going to end in failure, even if your lower and middle management pretend otherwise and throw a morale event and print a banner on a big wide HP printer every time the whole mess builds.
They picked Ada. /sigh
It's crap. And the premise is wrong. The thing that takes the most work to move from project to project is the acquisition of the domain knowledge and the architecture of the project, not the development tools and language.
Best of luck.
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.
But how much tool reuse is expected when designing a conventional engine and drivetrain vs. a hybrid wheel motor engine and drivetrain in the same company? And how much tool reuse is expected in companies that make diverse products, such as between Sony Pictures and Sony Electronics, or better yet in the 1980s when Coca-Cola owned what is now Sony Pictures?
I think everyone using Eclipse as their IDE sounds reasonable. I think everyone coding in the same language is only a good idea if you only code one kind of application. If you code client-server apps, stand alone apps, web apps, big apps, small apps, stable apps, cheap apps, GUI apps, command line apps, or any other type of vareity, that choice would be stupid beyond all reason.
Truth is, programmers can already switch languages pretty easy, especially if there's another person on their team who knows the language.
As to the language, we recommend that one be chosen for "prototyping/scripting" and another for "enterprise" development.
Everything the submitter asks about, but particularly language and framework, depends first and foremost on the nature of the projects. If you're building websites, you need different language and framework than if you're building hardware drivers. If the company does both, then using a single standard is a terrible idea.
If the company does only websites, then standardisation makes a lot more sense, but even then you need to ask: what kind of websites? Some frameworks are better for highly interactive websites, others are better for efficiently caching large amounts of dynamic content. If you're company does only one of those, you can standardise on one of them, but if not, you'd be seriously restricting developers.
Also, if the company wants to be innovative, it's important that programmers are free to try new things.
In short: standardise on what projects and programmers need, not on what management thinks is cool.
The rule here is that I've got to be able to check it out with one command and build it with one command. The goal is that I can take a stock PC (Windows and Linux in our case) with NO software, take a CVS snapshot CD, and download, install, and build in an afternoon.
Disaster recovery needs to be part of the build process.
Java is a good language to use for an organization standard. It eliminates several classes of errors (wild pointers, buffer overflows, and memory leaks) and may have less of a learning curve as a result. Today's enterprise code is far too large to avoid problems like these cropping up somewhere. For this reason I think that Java should be used for everything that doesn't require either a scripting language or direct control over hardware.
"all new development should be done with a single combination of development tools, language, and framework"
Run for the hills!
I work at a successful smartphone company, and we have a variety of teams with a variety of different tools. The way it works here is that we all use (pretty much) the same tools to access our data (SQL, sub version control, bug tracking), and use any variety of tools to develop. It works out well because different teams have good/bad experiences and we always learn from each other.
If a company all used the same tools, everything would be unified. It would be easier for people to switch teams, but you'd never learn anything from it, and many of the projects probably wouldn't fit with that framework.
Stick with variety.
I think it's asinine for an employer to mandate the use of certain tools. What they should worry about is whether the data produced as work product is uniform or at least compatible, regardless of how it's generated. If code follows the coding rules, who cares what editor was used? If a spec is readable and editable by everyone who needs to read and edit it respectively, again, who cares? The problem is that achieving a certain level of file-format compatibility sometimes effectively forces use of a certain tool. Let's look at some examples.
What many of these examples have in common is that the functional requirements applied to employees' work product often do end up practically forcing use of a particular tool, but that doesn't mean one should lose sight of the real goal - document compatibility. Requiring everyone to use MS Office, for example, might actually sacrifice document compatibility when half the company switches to a new version of Office and the documents they create are mangled or unreadable for those still using the older version. Been there, done that, more than once. Ditto for people using Mac versions of either Windows or *N*X software, when those versions are subtly different. OmniGraffle sure makes pretty diagrams, but if most people in the company use Linux and they need to be able to modify those diagrams then you'd damn well better save them in a format they can use and if you don't then you're out of line. The goal should be that all code is in a format that everyone needs to edit code should be able to edit, and all specs or manuals is in a format that everyone who needs to edit specs or manuals can edit, all diagrams is in a format that everyone who needs to edit diagrams can edit, etc. What tool you use shouldn't matter except to the degree that your choice of tool affects whether others can pick up your data and run with it.
Slashdot - News for Herds. Stuff that Splatters.
It would be ineresting to see if the benefits were worth more than the drawbacks. Why don't you take some measurements and use it for a study/paper/thesis?
If they choose a reasonable language it will work fine and you will learn your tools well. I hope they
didn't pick a microsoft languagre. It will be made obsolete in two years and your experience will be wasted.
-- Programming with boost is like building a house with lego. It's a cool but I wouldn't want to live in it
This is one of those ideas that has a very reasonable justification, but can go badly wrong if the policy becomes more takes precedence over the goals it is supporting.
This decision is very simple in principle: you choose the tool for a project that benefits the organization the most. In practice, it is often more difficult than making the decision by top-down fiat.
When I was a team leader, I always looked at projects for the "take away". The "take away" is the thing you got from the project that made you better on the next one, that allowed you to quote lower or to make your proposal stand out. The key idea is this: you should learn from every project and improve.
You don't learn anything if every project is done exactly the same way, with exactly the same tools and methods, and with code cut and pasted from the last project. But you don't learn much if you do every project in a different language and platform using different methodologies each month. This is so blindingly obvious that it hardly needs discussion, except that this is the kind of obvious thing everyone dismisses as obvious, then goes on to blatantly ignore.
Organizations go dysfunctional when people get stuck in black and white, narrowly paradigmatic thinking. Each end of the spectrum has a perfectly valid paradigm that shows its position is the correct one. The problem of real world management is striking an effective balance, a policy that is disciplined, but flexible.
Yes, you want to steer developers into using the same techniques and tools, so that you maximize your depth of knowledge in those things. But from time to time you should try things differently. If you are a Java shop, you might try a C# project, so you understand what the competitors are using. It may also encourage you to look at new ways of packaging your Java code, say as web services, which brings new knowledge to the organization that will be valuable even on other java projects. No competent Java programmer is going to be flummoxed if he is called upon to contribute to a C# project, especially if that project uses the same design philosophy (probably more important than platform) as the projects he has been working on.
It's also the case that inflexible standardization can sometimes make the learning curve worse and the expenses higher.
Suppose you are standardized on SQL Server 2005 as your database, and you have a project that requires storing and manipulating map data. SQL Server 2005 doesn't have primitive types or operators for geographic data. You can create your own idiosyncratic ways of doing things (expensive and nonstandard). You buy an entirely new platform from ESRI that stores geographic objects in standard RDBMS tables, which means (a) buying more products (b) learning to administer another platform and (c) using whole new set of APIs. Or you can do the project in Postgres or Oracle or even SQL Server 2008, in which case you are just using the same old standard SQL with a few simple extensions.
The brainless form of standardization in this case is to use the same product, then have to create or buy new products and platforms as a consequence. The more intelligent form of standardization is to stick to the techniques that you have been using, and know to work, which sometime requires a product that isn't your standard one. It might be reasonable to choose the former, but only if you understand this is actually a more experimental approach.
The platform choice should be guided by a number of principles, which should be able to overrule the policy:
(1) The project must succeed.
(2) The company must profit.
(3) Future support for the platform must be assured.
(4) The project should have "take away" potential.
(5) The company should continually learn and grow its capabilities, so it can respond to technological and competitive change.
This last principle is important, and the degree to which it applies de
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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 ]
If you look at the more efficient (overall) companies you'll see that they standardize on a few tools and get really good at it. For example, in the airline business, Southwest (one of the most consistent profitable airlines) flies only 737. This makes maintenance, pilots and service much easier. The less efficient airlines (e.g., US Air) fly a combination of almost everything--Boeing, Airbus and whatever. UPS has standardized on one or two types of vehicles for each need (local, long distance) again improving efficiency.
The era of the cowboy programmer is pretty much dead at large efficient companies. Random tools and processes might be ok for very small teams (less than 5 people), but they don't scale very well. Any project with more than 10 people lasting more than a year is likely to have turnover (given that the average employee stays on the job about 4 years...so over the 2 year project life, there will be 5 new employees). This forces management to impose development standards--image if every new employee decided that they want to use their own development environment, tools, naming convention, etc.
Professionally managed projects are more likely to be "slightly above average" -- an occasion cowboy (aka skunk work) project may be a spectacular success, but they are more likely to be a quiet failure. For big projects aiming at slightly above average isn't a bad goal.
/. readers are excused from all standards because they are all super programmers, save the company tens of dollars by using free stuff (or cracked warz) and are all brilliant.
Always use the right tool for the project. One language can't do it all well. If you narrow it down to two or three languages and pick one or two IDEs that can do these languages, that will cut down on problems.
Figure out naming standards and using source control would help quite a bit.
Mike http://thenextgenerationofradio.com
This is absolute crap.
Standardize tools ? Hell, why don't we GLUE everything together or perhaps use nails instead of screws (1 hammer can do what 50 screwdriver types do) or drill single size holes (avoids having to buy lots of drills) ...
Tools are build to acchieve a certain goal. Not all goals are the same so tools are not the same. If that were true we would use PL/SQL or something to write applications because we need SQL to access the database and PL/SQL (or equivalent) comes standard with it)
No there are different classes of toolsets. Low level (e.g. C) or middle level like (C++/Java) or high level (Like Prolog or 4GL).
In my experience the higher the level of the tool the more restricted it's usage.
M2C
This is a real issue, and the sooner developers realize:
1) Programming is secondary to their role. Business / Functionality expertise is primary, programming is just how they express it. This primary knowledge is what makes them most valuable/irreplaceable to management. - Those that cling to their programming skills as primary are replaceable in any scenario, not just this.
2) There are real business drivers as to why to standardize the SDLC. I will try and mention a few.
a) code re-use
b) common build / project management / source code versioning / test case execution / package management / software distribution / config management have huge benefits to any company. does not mean you have to limit yourself to 1 language. This saves money, time, ability to transfer between projects (good for developers career mobility), helps take care of regulatory or firm governance and reporting requirements.
c) a common ide can make things even more automated. The reason I say a common ide is it helps concentrate / focus automation / plugin development, although no reason this could not be done across several ide's... if there is justification and the company is willing to pay for that.
It's the 80/20 rule. Identify the 20% of what you do that makes you special (and I hope for your sake that is not the IDE you use, unless of course IDE development is your job), identify the 80% that you share with everyone else, standardize and automate as much of the 80% as possible/practical and put all your creative juices into that 20%.
You will be happier, your company will be happier, everyone wins.
Why is this modded troll? The AC is giving his opinion on the topic just like everyone else. Did I miss some other more sinister context to this post?
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.
Decide a minimum set of tools that will be needed to work with any project. All projects must comply with these rules. Here's a hint on them:
* Make
* Ant
* Gcc
* Gcj
* Bash
* Mercurial
* Git
* Subversion
and decide a minimum set of standards that every project must fulfill, such as 'there will always be a README file in the top directory with information about this and that', 'there must be a suite of tests that is good enough', 'no commits will be allowed if the tests are not passed ok (you can actually automate this)', 'the default target in the top dir's makefile will always compile the whole tool automatically', 'there will be no dependency on environment variables',...
Most of those rules you can read in some coding and project standards and many open source projects do work with that.
If you define a minimum set of requirements that guarantee that any programmer can contribute to the code if she has the minimum set of tools, then every programmer will be able to use whatever program/framework/IDE she wants as long as everything she uploads does not create a dependency on that IDE.
The languages thing is much more difficult. Rather than deciding what language can be used, I would decide what languages (plural) can be used and what compatibility layers must be provided so that every module can be called from another written in
a different programming language. I mean, if you have to program something, the key point is that you actually write the code. I don't care if you write it in ADA as long as I can compile it and I can understand it. Just give me a C interface so that you can use the programming language you want and so can I.
This will even allow you to use prolog if the program is a 5 lines predicate that turns out to be a 40 lines Java program, as long as you can link the object file with others written in Java/C/etc.
Upper management is not trying to be the market leader anymore, they're trying to look good in one way or another.
Either they want to package the company for acquisition, and want the company to look like it has a bite-sized IT burden. or....
This sort of thing can also happen when one of the people in management is trying to get rid of some of the better programmers who can accomplish more when they use additional technologies. In my experience it's been because the Manager wants to seem like they are the smartest person in the room, and they can achieve that if the tools that they standardize on are the ones that the manager knows. Anyone who disagrees with their wisdom can also be branded as not a team player and forced out as well.
I've worked for a company in a similar situation, and was painfully forced out. Now I work for a company that will use the right tools for the job, and expect their employees to learn new technologies to suit the jobs that come up. Each employee documents every aspect of the project, so other employees can come up to speed on the project quickly... and it works!
If your company is trying to standardize on one set of technologies, chances are that they are in financial trouble, or trying to hide some drama and want to cull the team.
Celebrate Excellence!
This move tells you everything you need to know about that company. If you were able to read the mind(s) of the executive(s) you'd find that they have similar opinions of staff. You're all the same, just cells in a spreadsheet. And software development is a linear process, just like building a house. They don't value you. They don't understand that programming is a creative endeavor. They think success is a matter of accounting. Let me guess... You sit in a cubicle, right? How high do you have to climb the ladder to get a private office? VP? My advice is to get out now, don't hesitate, just move on.
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!
Had very few competant program managers in my experience. Its the "Peter Principle": those who cant program get promoted into management.
Believing that something good, overall, will come of forcing every developer to use the same tools emphatically proves that said management should not be involved with software development in the first place.
Probably the only answer a management thinking that way can understand. Hurry up guy, get a new job elsewhere and fast!
I've seen when upper management wants to standardize and treat their developers as interchangeable cogs in the machine that they're planning on exercising that interchangeability. You might want to update your resume, since you'll likely be replaced.
I'm forced to program in Fortran because that's the only thing the dinosaurs in charge know how to use. It's painful and verbose and it takes about 100 times as long to code anything as it would to just code it in ruby, even if it ran 10 times slower. For God's sake, someone please help me.
Seriously though, the most efficient language is almost always the one the majority of your developers are most familiar with. And many projects lend themselves to using multiple languages/technologies for various different parts. LAMP and WIMP are okay, but personally, I like the PHP/IIS/SQLite/Subversion. For Scientific programming, I often use C/Unix/Nginx/Tcl.
How many different tools do you need? Is there one tool that is the right tool for every job? Is there even a small inventory of tools that includes the right tool for every possible job? I think the only answer is a resounding NO. Any fixed tool set is sure to omit things that are essential for particular types of jobs. And, any fixed tool set must exclude all newly developed tools, and hence must exclude those future innovations.
I'm sure you have heard the one about the man who has only a hammer. Hammers don't work very well for installing screws. Hammers work even less well for cutting wood. And they don't work at all for cutting steel or soldering copper pipes.
The construction people realized, long ago, that they need carpenters, masons, plumbers, and electricians. Each of the trades has its own set of specialized tools. They just had carpenters and masons for thousands of years. A few hundred years ago plumbing was invented, and that required specialized tools and knowledge. Then, just about a hundred years ago, they invented electricity, and that also required new tools and knowledge. New innovations sometimes require new tools and new specialists.
In software development, we do need specialists. Some of use work on algorithms or protocols. Some work on databases. Some work on presentation or human-interaction. Each area has its own tools. Each has its own specialized languages, libraries, and environments.
And, depending on the task at hand, it is sometimes appropriate to acquire or develop an entirely new tool. Several times, I have developed a new application-specific language extension before starting to develop a big application or a set of related applications. Each on of those extensions was used to generate huge volumes of code that would have been tedious and error-prone to develop any other way.
Now, when you propose to bring a new tool into the shop, it is prudent to consider the costs and benefits. If you use a new language to develop a production application, that new compiler will have to be maintained, and the programming staff will have to maintain the knowledge of how to use it. That adds cost to the enterprise, even if the tool itself is free. So a judgment call is needed as to whether the benefit of the new tool exceeds that cost. Some tools turn out to be silly or ineffective, and others turn out to be extremely useful and cost effective.
The decision to forbid all new tools is just a decision that there cannot ever be a new tool that will be useful and cost-effective. That manager avoids the cost of the new tools, but also avoids the benefits. And he eventually loses his competitive edge over his competition, his staff, and maybe even his job.
Just keep in mind that if you're not willing to standardize on a single tool then there is some group of programmers on another continent who will be perfectly happy to all use the same tool for half of what you get paid.
Sure, there might be a "best" tool for the project (more likely it's probably just a favorite tool), but is it so much better that it's worth the additional cost? Does a Rolex really tell you the time 5000 times better than a Timex?
You never really know how close to the edge you can go until you fall off.
Would you like to be operated on by a Surgeon who has only metal tool to work on anything from skull fractures to gut perforation?
quit
take your skills to a good company.
I did it and it was the best day of my career.
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.
The benefits of a standard toolset are unlikely to realize any real gains even in the long term.
Even standardizing on which VCS to use is really a moot point. Just pick one for the central repository. If the dev is more efficient in mercurial than subversion; there are scripts to convert between the two transparently.
It's the product that matters. Follow the path of least resistance when it comes to productivity. Laziness is a virtue.
I don't understand why anybody would go to great lengths to standardize. The context of the development will always take longer to learn than the toolset unless you are doing minor development. However - analyzing the real motives will yield better answers:
1) Flexibility of workforce. Hiring 1x Perl, 1x Java and 1x Ruby programmer is not as flexible as hiring 3x Java programmers. Any Java programmer can be redeployed - whereas you can't push a Ruby programmer into a Java role (All this from an HR perspective - not a "Programmers should theoretically know all languages").
2) Licensing of Software
3) IT Management - yes big companies pay a lot more to their IT departments and or IT management partner if they have too many configurations.
4) Best of Breed perceptions. It might not matter to you and me, but it might matter to the board of directors and therefor the stockholders.
5) Salaries - VB.NET programmers are just plain cheaper than Java ones and a Excel spreadsheet normally compares yearly salary against yearly salary.
6) Job Market - some types of developers are rare
7) Management Background - managers prefer managing things they have experience in.
8) IT Support Turn-Around time. Having a developer spending two days installing their favorite OS after a hard drive crash is not an option for most companies BECAUSE downtime = money lost.
9) Hardware support. Depending on the supplier of the hardware, it might only support a limited number of OS.
While we might scream at the stupidity of some of these points they are not necessary invalid from a business perspective.
...you're going to have a lot of things forced into place.
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
OK, in re-skimming your post, it sounds like you're using Java and are heavily committed (no pun intended) to Eclipse metadata. First, I wouldn't code in Java. :), However, assuming that I was stuck filling this guys shoes, I would probably do the same thing I do here: Maintain my VS environment, and maintain Linux in a VM. Before making the final commit, I'd do all the Eclipsy stuff that needed to be done. This is essentially what I do now. Yes, I'm maintaining project files in addition to Makefiles, but maintaining a project file is trivial and takes virtually no time. Yes, I do everything in C and it compiles on Linux and Windows, with platform dependancies isolated. Ask me again why I don't code in Java. :)
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
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.
Every time we write a program and create configuration files that the program can read, we are expressing ideas in a "language". Sometimes we express simple ideas using Windows "INI" syntax, and other times we may write more complicated ideas using Perl include files or bash scripts. Many current versions of *nix allow shebang notation (#! followed by the program name) to shorten the invocation "program cfgfile" down to just "cfgfile" at the commandline, which emphasizes how flexible its idea of "programming language" ought to be. There is no question that a Tower of Babel is hard to manage, but trying to force every programmer to use the same programming language will simply lead to re-inventing elaborate configuration languages. (XSLT, anyone?) A better solution is to have design/documentation reviews at various points during the life of a project to make sure the software is maintainable by the (multiple!) personnel likely to have to maintain it. Failing to arrange for multiple maintainers is much more likely to lead to project failure/obsolescence than allowing proliferation of languages.
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.
This is one of the most ancient, classic mistakes in the practice of software engineering. http://sourcemaking.com/antipatterns/golden-hammer Please tell us which company this is so that we can all assiduously avoid ever working for it.
A lot depends on the specific environment and how dissimilar the projects are. The smaller the organization and the more similar the projects, the more reasonable such a move might be. However, the more projects of divergent types there are....
Not only does that seem like a horrible idea from the standpoint of producing functional, usable programs, but it also seems like a nightmare for the employees on a personal basis.
Why?
If you pick a single language, the employees will be little more than cogs on a wheel, and easily replaceable - at least, that's what management thinks, and will think. Management will likely want to pick something like .NET, which is pretty familiar to most recent graduates and works on "all the Windows platforms".
What happens from there? Could be a number of things. Layoffs, firings, pay cuts... and once one of those things starts, the other two are likely to follow quickly. Can't get a project done on time due to the language you're required to use? BZZT! Fired! Expanding deadlines resulting in increased costs? Gotta get some cheaper developers! Meanwhile, anyone who manages to hang on has to deal with the organizational shit, and possibly a pay cut on top of threat of job loss.
In 5 years the company won't exist.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
Corporate Management wants to view all developers as being the same. Year in and year out, they spout the mantra of "replaceable cogs in the machine theory" that just doesn't apply to technology personnel. That is how Java managed to grow at the pace it did in spite of a number of deficiencies (C#/.Net grew the same way).
Sadly, nobody wants to look at better ways to do things because they're too hard and non-technical corporate management wants to dehumanize (and devalue) their workers.
Ever wonder why offshoring is so popular? If you can reduce anything to a manufacturing process, you can move it where labor is less expensive.
Unfortunately, nobody seems to want to rock that boat because they've been dumbed down to think there are no other jobs out there that might be better nor should they have the right to expect to be treated any differently.
Oh well, the future is bleak......
So how many orthogonal languages ought be chosen, for a complete toolset?
Low bugs compiled infrastructure single-machine code ( say Eiffel )
Problem-domain scripting, single machine ( say Ruby/Python )
Many-machines single-program-instance, massive concurrency ( say Erlang or equiv )
what others, or how should orthogonality be decided?
Sure, and while they're at it, let's give all the mechanics just one size of wrench and screwdriver.
Mechanics don't create machines, they just fix them. They don't have any control over what kind of screws and nuts they work with. You're really talking about hardware engineers, not mechanics.
Machines do need to have more than one size screw and nut. But suppose you have a big machine designed by a bunch of different engineers, each of which has their own fanatical view about what size screw is "best". Or similar opinions about metric versus SAE versus BA versus Whitworth threading. And about Phillips head versus Frearson, BNAE, hex or TORX. Let's not even get into the issue of screws versus other kinds of fastners....
Fortunately, hardware engineers don't suffer from that kind of fanaticism. When some piece of hardware gets designed, somebody says, "we're only going to use metric Phillips screws" and everybody goes along. But when the equivalent suggestion comes up in a software context, rugged individualists like you whine that it's a "gross misunderstanding of the process".
Frankly, you're the one who doesn't understand the process. Beyond the particular pieces of code that you own, most software is a big honking entity consisting of thousands of pieces that have to fit together. When all the pieces are designed according to each engineers personal whims, you end up with a lot of pieces that don't fit together, and the application as a whole is crap.
As, alas, most software is.
It really depends on what kinds of software the company is writing. If you had some groups writing web-based software, other groups working on low-level scientific code, some working on Win apps, and others working on general market x-platform apps, then this would be the stupidest idea I've ever heard.
However if everyone is writing generally the same kinds of software, picking a language for all projects isn't too bad of an idea, as long as there is discussion every 12 months about if it was the right choice and if it will *continue* to be the right choice. (Think about what would happen if you picked COBOL in the 70s and never left it because corporate policy says you can't!)
As for *environments*, I find that everyone thinks different, and to force everyone to use the same environment causes some issues. Indeed, everywhere I've ever worked, we take the opposite tact: *everyone* can choose the tools for themselves. What we quickly found is that the best tool would quickly win-out on its own and everyone would unify behind it (at least, until, something better came along).
Going with one framework simple can't work if you need to do a wide rang of work. For example I've worked on embedded microcontrollers where you have only a few kilobytes of RAM. I've worked on radar systems that used large mainframes as a processing engine and new rocket telemetry. There is no way the same tools could work on those three jobs.
But on the other hand if all you do is general office apps on a PC. Yes then standardize on a few tools
With a standardized tool set we should be able to crank out all that new assembly code lickety-split!
The contest for ages has been to rescue liberty from the grasp of executive power. -- Daniel Webster
using perl 6 and guile both running on parrot.
What's the quickest way to a headache?
What's a language with sucky closures?
What language had a promising start until the convention was to have GhostClassFactoryFactoryFactoryThatHidesLogicBehindAllLayers?
Where can I get the best bloat for my buck?
Where can I find a good way to store a few k of data into a matrix of XML cruft?
That being said, java is reasonable when used reasonably. The current conventions is to use it to produce monumental bloat. It was fine pre J2EE.
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
Answer: One who couldn't find work elsewhere.
Don't do this. You'll lose your best people, sometimes before you've even hired them.
http://outcampaign.org/
Your upper management clearly hasn't got a fucking clue (expletive deserved). This is not usually a problem, since upper management quite often hasn't got a fucking clue about technical issues. However, your problem is that your middle management clearly hasn't got a clue at how to work with upper management. If nobody in your chain of command has a clue then you really need to quit or get promoted really quickly. Since you are asking this question here, it seems that you don't have a clue either, and I'm afraid slashdot is a poor substitute for a good lead. Go out and get a job with a team that has a clue.
To gain perspective, try suggesting they standardize on one business communication method. Say either mail, email, instant messaging, phone, video meetings, or face to face meetings. This would dramatically reduce the amount of support needed from the IT staff resulting in a huge cost savings. It would also save the managers the trouble of learning all of the new communication techniques. If face to face meetings are chosen, then, following the logic, randomly swapping managers from one meeting to another should pose no difficulty as they are already familiar with the format;)
Well,
What would you use for report generation over multiple 20 to 35 million record files?
With multiple summary levels that all roll up automatically without a lot of extra coding.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
The so-called rationale behind this type of standardization of higher productivity for moved personnel makes absolutely no sense. If you allow everyone to use their preferred developer tool of choice, then you will achieve even higher productivity gains because no one will have to learn a new developer tool when they move. Why? Because I am going to take that tool with me with I move and continue to use it in the new environment.
With regards to standardizing language and framework, consider the following hypothetical situation. If project A uses framework B, then the developers can be twice as productive than if project A uses framework C. Developer D is moved to project A. Developer D is twice as productive on framework C as framework B. How many developers have to be working on project A for the benefits of developer D's continued productivity to be canceled out by the lower productivity of the entire team because they are using a ill fitted framework?
I bet you are a Java development house, with an attitude like that...
After reading some of the other replies, I suspect this will not be the most popular response, but here goes.
.PSTs, .DOCs, .XLS, etc. This is probably because MS Office is such a highly used program in the corporate world. In any case, due to the relatively closed nature of the Office document formats, the best way to extract the data we need are the Microsoft APIs and, consequently, Visual Studio/.NET/etc.
.NET code) and money (i.e. software licensing costs) which can be reused or built-upon for future development.
At my current employer, we have a de facto standard on Microsoft development tools. This is not an enforced standard, but rather a recommended standard because the MS dev tools are the right tools for the job.
Our problem domain is the processing of electronic documents for the e-discovery phase of litigation. This includes parsing e-docs to extract metadata and full-text and other relevant information to store in a database, so that each record can be reviewed as potential evidence for a trial.
The majority of documents we receive from our clients (law firms and major corporations) are Microsoft Office format; Outlook
After developing core tools for the problem domain, there is significant investment in terms of man-hours (of
No developer would be actively prevented from using different tools, frameworks, languages, etc. However, it is encouraged to use the standard tool-chain because it makes sense given all the prior work which can be capitalized on for future development. Additionally, a lot can be said for consistency in development environments when it comes to multiple developers working on the same system.
Are they publicly traded? If so I want to short their stock, thanks.
Get your teeth into a small slice: the cake of liberty
>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?"
If all your problems are sufficiently similar, it will be a time saver. This will be the case if your company just builds device drivers for one operating system or does electronic store fronts that are all the same apart from the graphics.
For the broad spectrum of components that go into even a single product (a hypothetical digital video product for the broadcast market might have a high performance real-time system which does zero copy from network to disk and a web GUI) you'll do a lot better with tools that are appropriate for the job. You don't want to do zero copy IO with hard real time constraints of tens of milliseconds in Java. You don't want to do the web front end in 'C' regardless of what library you put on top of it. No popular language+platform covers those two bases acceptably well to say nothing of text processing, distributed systems, ad-hoc query processing...
When you have to use the wrong tools for the job, really good people will use those tools to build better tools which are suited to solving the problem sooner with solutions more likely to be correct and performant. Less experienced or less talented people will just expend more effort trying to pound square pegs into round holes. In both cases where an appropriate tool exists you'll be better off just using it.
I'd suggest you tell management that provided you have developers who know the programming paradigm (functional, object oriented, etc.); know one language in the Algol family tree; and know a good scripting/text processing tool set you're going to loose less time to spinup than using the wrong tool and start looking for a job in case that doesn't work, because
1) in most cases tool and language constraints are going to be both unpleasant and cause productivity (and therefore profit margins) to suffer.
2) management making decisions based on thinking they know more about technical subjects than the technical staff is not a good sign.
I seriously advocate the .net platform. With that get the following:
Open Source:
Commercial:
Of course your version control server/tools are also an important aspect. I currently use subversion but maybe you need a distributed version control (to each his own).
I am rather experienced in both .net and java. I favor .net for web applications and desktop alike and point out that IronPython is a great dynamic language for scripting. Windows communication foundation is also unmatched in my opinion. It allows SOA implementations with virtually no plumbing.
Considering you're moving to a central platform, I'm assuming you can sell windows as the os. I will not mention my preferences but will note that Windows Server 2008 is a great improvement when compared with previous versions. I will also mention if you are planning on writing anything that will use WCF, you really should get 2008 to host it.
I do notice some concerns by commenters above in regards to the non-cross platform"ness" of .net. In response to those comments I point out the requirement of ONE single platform and associated tools. How does one be cross platform when targeting one platform?
Good luck and I hope this post helps you in your decision.
This is what I call one of the "Sure Signs of Stupid IT Management". (That would make a great blog post title, eh?)
First of all, management typically has no clue about the development technologies they are standardizing on, let alone the technologies they are excluding from their standardized set.
Secondly, these management types don't seem to have a clue that the proper role of a software developer is to adjust to whatever language/technology is utilized for a specific project. Learning on the spot is part and parcel of the "daily normal" of a programmer's work existence. Any programmer who can't adjust properly shouldn't be a programmer in the first place -- they need to be in a different profession.
Last, as others have clearly stated, using the best tool for the job is part of the professional decision making responsibility of the (usually senior) software developer. Only programmers can properly make these kinds of technical judgments. When management gets overly involved with such things, projects invariably turn into crap.
Steve Magruder, Metro Foodist
I think you misspelled 'maven' as 'ant'. Oops.
Other than that, I agree with your premise. As long as everyone can check out the project and build from the command line, it doesn't much matter if developers like this or that IDE, vi, emacs, TextPad, whatever. Let them use whatever they find to be most productive.
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
What if I have a huge batch data-processing job to do? If I only have PHP and Java in my toolbelt, I'm in trouble.
Better add PL/SQL or some other batch-processing language.
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
if your company is multinational, or has international clients. I am guessing that this would be as popular as what they are doing now.