Same Dev Tools/Language/Framework For Everyone? 519
AC writes "Upper management of the company I work at recently declared that all new development should be done with a single combination of development tools, language, and framework. The main rationale is that people can be relocated from one group / project to another faster, because they don't need to learn a new environment when they switch. Of course the chosen language / framework used by everybody does not need to be the best tool for the job, but it should be good enough to allow every project to get done. What does Slashdot think about this? Is it OK to use the same development tools and language for every project, instead of choosing what fits best? Will the time saved be sufficient to offset the time lost to the 'not the best tool for the job' environment developers will be forced to use?"
Choose them all under one. (Score:5, Interesting)
We frequently encounter this issue with our clients (government, military, and commercial). We know that this can be a very bad thing if they capriciously apply it across the board. What we have recommended allows for the most flexibility, while minimizing the "tools". In order of importance.
1. Cygwin (0$)
2. Eclipse (0-250$)
3. Teraterm (0$)
4. Adobe CS whichever (900-2500$)
5. Microsoft Office 2003. (400$)
This would allow any team member to move from one workstation/area of work to another without too much effort.
As to the language, we recommend that one be chosen for "prototyping/scripting" and another for "enterprise" development.
With Cygwin you get the CM tools, build tools, perl/bash/etc. (Already included tool set under Mac/Linux/Unix...) With Eclipse you get every thing too. (works on all OS) Teraterm nice term, just don't like putty myself. (not needed outside of windows) Adobe for those that like spending money. (Mac/Windows) Office, they are going to buy it anyway.
Depends (Score:2, Interesting)
It is OK if the tools are equivalent. Sort of like only using metric tools on your car. It is wrong if you can't use the best tool for the job and there are no reasonable alternatives (sort of like having a wrench when you need a screwdriver).
This type of micro-management usually fails because herding programmers is like herding cats. Programmers work best when they can creatively solve problems. They work worst when they are forced into a suit-mentality.
Depends (Score:2, Interesting)
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.
Type of Company? (Score:3, Interesting)
In my line of work, the industry has been migrating from Cobol and Fortran to C/C++ in recent years. I have seen small bits of Java on tertiary projects. I have seen vastly different development toolchains.
My 2 cents? Standardize intelligently. Let experimental groups explore whatever they want, but reign them in when it is time to make evaluations.
One area that I love seeing standardization is in the tool for managing the software repository where you commit your periodic code changes. There are also benefits for standardizing on compilers and code libraries that you use.
One area that I hate to see standardization is in text editors. Let people pick whatever fancy or simple typing program suites their needs best.
Obviously, this post is not geared towards whiz-bang web developers who actually need to push the envelope a little bit to stay ahead of the latest trends.... but there is something to be said from the benefits of specialization and so I generally agree that *most* areas of company code development should be locked down and projects at the company that are not in compliance should have good reasons.
Re:Choose them all under one. (Score:4, Interesting)
Re:Depends (Score:5, Interesting)
It's lame to reply to myself, but I forgot something re: development tools.
Don't dictate what your developers use, if it's possible. Case in point: In my current company we are building a VB.NET web application. There are six developers and five of us use Visual Studio, but the tech lead does not, he uses VIM. I was amazed by this, but after seeing him wrangle some text with that thing, I can see the value over an IDE, although I still prefer its warm confines because I've come to rely on the bells and whistles.
BUT, this works only because he has a build system where he does not rely on the VS project files, only the source code, resources, images, etc. The end result is the same as if you had compiled the thing inside Visual Studio, except that you used only the compilers. This is very cool, and while I don't fully understand the build files, I can see how that's a definite advantage. The scripts even pull the source off CVS and everything.
My point I guess is that you shouldn't tie yourself to development tools, if possible. That's just common sense, and at the same time you'll allow developers to use the tools they prefer. That makes for happy developers.
Maybe one of these days I'll try VIM or EMACS, or maybe I'll just stick with the IDE. But at least I know I have the option.
Re:Standardize the RIGHT tools (Score:5, Interesting)
Two (Score:5, Interesting)
A similar question came up roughly a year ago on slashdot. My recommendation is to chose two: one "scriptish" language (PHP, Python, etc.) and one strong-typed language (Java, Eiffel). C# is sort of a compromise between the two, but marries you to MS (so far), which may bite you in the future like VB6 did.
A Business Case for Less Management (Score:2, Interesting)
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?"
GCC + Make + Emacs (Score:5, Interesting)
Makefiles are text files, and completely tool agnostic. By standardizing on Make, you don't paint yourself into a corner with a single toolchain.
Emacs has editing modes for many languages and file formats. By standardizing on that, you don't paint yourself into a corner, unlike a single language IDE. (Also, those who prefer vi can still use Emacs in viper mode, so Emacs is a more flexible choice than vi for the company).
GCC is a compiler collection, with support for many languages. By standardizing on that, you don't paint yourself into a corner with a single language.
Best of all, these tools don't take up a lot of RAM, so the development machines will be responsive without beefy hardware.
Re:It's dumb. (Score:3, Interesting)
I'm going to disagree with you to a point. Having a standardized application framework makes a ton of sense when used for a for a specific class of product, and once chosen, should NEVER be deviated from. Having a "default" set of tools for an organization also makes sense, so long as the process for allowing deviations is reasonable. (EG: peer review by other techies, etc)
There is a *lot* of value in having a standardized framework for application development - working with one, it's a breeze to reassign programming resources as needed when circumstances change. Our application framework is somewhat "heavy", and we stress consistent code quality and layout, which means there's a longer learning curve up front, but once "up to speed", it's very easy to read each other's work. So easy, that it's usually damn near impossible to tell who wrote what without looking at the update history.
There is a *tremendous* value in this.
Re:GCC + Make + Emacs (Score:2, Interesting)
In a sufficiently large company you'll have a good chunk of programmers (though I wouldn't call them that) that ave ever compiled anything without selecting "build" from the menu in Visual Studio. Try getting those guys up to speed on make and emacs.
You'll actually have to teach them something about code.
Re:I might be wrong (Score:3, Interesting)
If it were my company I would be interested in finding out the real problem that the PHBs are trying to solve. Are there too many different toolsets in use or do they think that by standardizing they will make everyone into neat little interchangeable cogs?
I worked for a company owned by a bank. The bank had its own developers and their PHBs wanted to standardize on languages (C# in this case) so that our teams would be completely interchangeable. They had this pipe dream that if one of our team members was out for a couple of weeks that they could send up one of theirs to as a drop-in replacement, and vice versa. The problem with that is that our company was doing something completely different and a replacement wouldn't be able to learn the business processes quickly enough in such a short time to do anything useful. The PHBs acknowledged that this was an issue but refused to abandon the idea that someday, somehow, our teams would be completely interchangeable.
Choose an ide platform (Score:3, Interesting)
Management is stupid indeed and like another post said they do not know the difference between a language and an app. Management loves one big app such as peoplesoft or something that integrates and assume languages or like software programs to lower costs.
If you pick Netbeans or Eclipse you can then use other languages for it and management wont realize it. You do not have to be stuck with java even if the ide is written in it. Management assumes everyone is using the same thing.
Or if your an ms shop vs.net can use perl.net and python.net for small scripting and text searching while all using the same .NET framework for small admin jobs while still retaining your web (C#) and desktop C++/VB languages. This ensures your on the same platform but can still choose the right language for the job.
I read here on /. that Catupiller uses C for everything including shell scripting and its obvious its a very bad idea as one language such as java has vast api's for serving dynamic pages while C is good for getting close to hardware and using assembly calls.
Maybe recommending 2 or 3 languages using the same framework (.net) can be a selling point as they can integrate and retraining is low. But yes web programming is not desktop nor low level hacking as different tools are needed for different things.
Standardize on 3 and chose a common framework for all. You do not have to use .NET if you do not want too but its commonly used. Java is getting better for non server use. But try to sell the ide as a language to get around any dumb requirements. ALso remind management that every language has a sub language within it like AJAX, SQL, etc so its its impossible to standardize anyway.
Re:No way. (Score:4, Interesting)
You hit on an important point - "developers are notoriously intolerant of following orders simply for orders sake". If all your developers loved CoolToolABC, but then you ordered them to all use CoolToolABC, they would rebel and feel stifled. There's a lot of creativity in software development, and to ignore the psychology of it is a big mistake that I've seen many corporations make.
It depends a lot on company size&diversity (Score:3, Interesting)
We have the same issue come up in my company(~500 developers).
Obviously with such a large number of programmers working on so many different pieces of software complete standardization is very problematic.
We are finally deciding to create a set of 2 or 3 software architectures to choose from.
And have them prioritized, and a process of getting an architecture approved. The idea is when starting a new project you should use the preferred architecture with minor changes unless you have a good reason to pick architecture #2 or #3. however You will have to have very compelling arguments to run your project on a totally new architecture and explain yourself to top executives.
An architecture will include both development and production environment for example we may have the M$ option: win2003+IIS+mssqlsever+C#+Link+Visual studio+TFS
or our java option:
Red hat+jboss+hibernate+java swing+java web start+eclipse+SVN
The problem is setting a process to update the architectures with time, we want to move forward with time but we don't want to be dragged in to new adventures every week.
We can put a person/team in charge of a specific architecture but we still don't have a good process for phasing out an architecture and introducing a new one.
How do we decide we are ditching C# and moving to Ruby on rails? This remains an open problem for us.
Me.
Re:Choose them all under one. (Score:4, Interesting)
You really work for lines in your CV?
I should add "hitting my boss because he had complaints about my smoking habits and some nasty phrases about my mom" then.
But seriously, if I do some work, I make sure I do it for the best of my abilities, and noone can say anything about that. Personal differences are another matter, and they usually arise when my would-be boss doesn't like what I do when I'm done with my work at that time.
For some reason, my bosses seem to think that if I don't appear as working at a particular point in time, I'm not working at all.
Back to your comment, I really do care about productivity, it's just that I don't define it as "appears as though he has something to do, always".
Re:Standardize the RIGHT tools (Score:3, Interesting)
Management invariably tries to standardize the wrong tools because they have no idea how software development works.
Hmmm, in my experience at several small and large companies, management tends to leave Tech management to Tech managers, who tend to know very well how software development works. Their reasons for making choices you don't agree with may well be sound and rational, or forced by circumstances. They usually don't just have your to consider, but all the other projects, as well as future projects and still supported projects from the past. Hiring and training is very expensive.
You may save development time for individual projects by using the best tool for each job, but waste a lot of time and expertise constantly having to train project members. A set of standards may not be ideal for any individual project, but the best choice for the organization as a whole.
Firing the entire COBOL team, scrapping the mainframes, and hiring a few dozen Linux gurus for a complete re-write from scratch in ruby-on-rails is probably not the sound and rational choice either.
Re:It's dumb. (Score:3, Interesting)
Programmers are not generic as much as executive management would like them to be.
If your application is sufficiently complex, being in the same language buys you very little.
And there are huge costs to using an inappropriate language to solve a problem.
If it were just me, I'd go with Java all the way because at least it is fairly reusable on unknown future hardware.
And that being said, it would completely suck to try to work on certain classes of problems and platforms only in Java.
At my current company we have .Net. (And various XML/Markup stuff). And several packages.. which are basically programming languages when it comes to interfacing them. Plus some old powerbuilder stuff and maybe some foxpro plus spreadsheets and three kinds of workflow. Oh and several flavors of MQ...
C, Oracle, MS-SQL, DB2, Java, JBoss, Eclipse, WSAD, RPG-ILE, Crytal Reports, SAP pieces, Various DTS packages, Cobol, Javascript, VB6.0, Various "MS Application" languages, and
I get the value of fewer languages and a standard platform.
I would hate to do workflow in C. I would hate to do reports in .Net without Crystal Reports and .Net can't handle the things that RPG-ILE and Cobol eat for breakfast.
Even just the 30 or so programmers that work in RPG-ILE can't be swapped because each package (~750k lines per package) contains specific business rules. Changing a programmer with the same language and platform results in lower quality work, doubled or quadrupled time lines, and more errors in production.
Executives Hate this and want everyone to be generic even if it takes 10 times as long (and before I entered management and stopped being a programmer, my productivity was down to about 1/10th of what it was in 2000).
it's not terrible if done in moderation (Score:5, Interesting)
I'm in academia, where just about the opposite prevails: you can use whatever you damn well please, and generally PhD students don't even get that much in the way of hard-and-fast rules from their advisors, so they use what they please too, as do half the research scientists and post-docs. The results of that are why companies consider standardization.
The main problem is that, while experimenting with lots of languages and using languages perfectly suited to a particular task is nice, doing it too freely makes for a nightmare if you ever want to combine things, have a programmer of one system help out on another project, etc.---just the sorts of issues that prompted this question.
My current research project's codebase, partly inherited, partly pasted together from components that were lying around the lab, and partly of my own doing, using nine languages, as a result of everyone using whatever seems like the right tool for each job. There's a C backend for one part and a C++ backend for another part; an AI component in Lisp; some GUI and glue-y stuff in Python; other GUI stuff and some other AI stuff in Java; some text-munging scripts in Perl; some number-crunching in Ocaml; some parsing and god knows what else in Haskell; and some other AI in an in-house language that compiles to Java.
Now some of those tools were indeed exactly the right tool for the job. But this is not ideal to maintain, and it's nearly impossible to ship to anyone who isn't me in a way that a mere mortal could get the code built and running.
Oh, and there's some other projects in the group that use C#, and one that uses Scheme, if I want to go for double-digits...
A Management Perspective (Score:2, Interesting)
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.
Re:A gross misunderstanding of the process (Score:5, Interesting)
Sounds like Stanford taught things the right way.
Just last week, I was thinking about this. The University of Texas (where I went) had a similar philosophy when I was there as well; the goal was to teach the concepts and how to learn new languages. We groused about it incessantly at the time, but looking back over how my career has progressed and how I've been able to adapt to new technology, it was absolutely the right education.
Consider this: At the time I started my Freshman year in college, the Fall of 1991...
The most basic elements of what we develop with today didn't even exist, and those that did exist were in nascent forms that they today barely resemble. Even ANSI C got a major update 8 years afterwards with the C99 standard -- which is nine years ago.
But wait, there's more!!!
When I was in grad school at UCSD, I took a class on Software Evolution. The instructor would give us a project, and every couple of weeks ask us to make changes to the project as our next assignment, to expand the project's capabilities. We were given the freedom to choose whatever means we wanted to pursue this goal. The initial assignment was to generate a simple web page.
A friend of mine chose to use Perl. I asked him if he knew Perl, and he said, "No, but I can learn how in the time it takes to implement this in any other language, and with each new assignment I can just write a whole new script."
He was the only one in the class to finish every assignment.
The moral of the story is not that Perl is something wonderful, but rather that Perl was the appropriate tool for the job and that learning how to use the appropriate tool takes less time than using a tool you're familiar with that doesn't work so well. Consider chopping down an overgrown pine tree. If you know how to use a hand saw but not a chainsaw, the guy who uses a chainsaw is going to hack the tree down in less time regardless of whether he has to read the manual to learn how to use it. (And then after that, he'll know how to use a chainsaw on other trees, too.)
So... yeah.
Re:It's dumb. (Score:3, Interesting)
I'm an executive. I'm also a programmer. I will do just about *anything* to avoid the 10x decrease in productivity you mention.
I've seen it - so far, we compete aggressively with companies many times our size, and trounce them handily by trusting our developers and maintaining a highly consistent code base with lots of comments and purposefully simple SQL queries. The results (so far) have been eye-popping.
BTW: our bread-and-butter app is written in LAMP (postgres) with a fair amount of php-gtk for the client-side stuff. It's been pretty impressive so far - company has grown from 40% to 70% per annum, every year, for 5 years, in a marketplace where our penetration is still less than 1-2%, while being intensely profitable.
I guess I'd say: don't confuse the "understanding the problem" with "understanding the solution". You have to understand the problem, and that will never change. But I want to reduce the amount of friction starting at the point you understand the problem to as close to ZERO as possible! Any time spent finding solution-oriented stuff is time wasted. The solution should be presented using a standardized interface so that only a few calls are required to figure out exactly what's going on, and then begin writing.
Documentation helps, but standardized coding conventions help even more - more than reading documentation, knowing how to consistently look for "WTF is this X widget doing?" is probably far more productive than spending 3 days reading arcane (boring) and poorly-written documentation.
It is a management analogy failure (Score:2, Interesting)
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.
Re:A gross misunderstanding of the process (Score:3, Interesting)
The theory sounds about correct.
That said, I've had the experience of working in a corporation for some time where everything was too standardized.
That means that (for example) we needed to all use the company developed CRM (because we ate our own dog food) that had two speeds: very slow and not working (very slow here means that is was web-based, with the server in another country - over VPN and with a single webpage loading in 40 seconds at times). Performing a code change required loading about ten reloads.
We also had to use the same Perforce server (hosted in another country, accessed over VPN) with in-house developed addons on top of it (slow and buggy) which meant that a checkout operation would take anywhere between twenty seconds and five minutes, if it didn't crash.
If it crashed, you had to call the infrastructure guys to unlock your files manually (if it was really urgent, that meant half an hour on the official channel, or five minutes if you were friends with the Infra guy and promised you'll open a help-desk ticked afterward).
On top, we had a corporation "enterprisey"-level workflow that required us to put the same descriptions of the problem in the CRM, in Perforce, and attached in a text file in both CRM (in two places) and Perforce, for each checkout.
In the end, checking out a file to add a line of code could take around two hours (one and a half if you streamlined the process as much as you could).
If you had to propagate one change across three versions of the application, there went your whole day.
All this was because, at the top level, somebody started standardizing too much.
I am not arguing here about total freedom, but standardizing can definitely be taken too far.
Re:Choose them all under one. (Score:4, Interesting)
You should take a job-related book with you to your smoke breaks. Crack it open whether you read it or not. Or some kind of PDA.
Re:Choose them all under one. (Score:4, Interesting)
My first guess is that he may work for an accounting and or payroll function and he might not be suited for a training department or operations programming. (or vice versa)
Were I work there are several different departments all with different programming needs. It helps to know some intimate details about accounting in order to give them the right tools to do their jobs. It would also be a pretty steep learning curve for that same developer to put their accounting knowledge on the bench while being tasked to write a program for the operation of the company. Without knowledge of the processes that go on in the operation, they will likely create software that's useful, but not very elegant or meaningful for the front line supervisor that needs to update numbers.
Where I work, they have a dedicated development staff, and the projects they roll out are very well planned, organized, and managed. Unfortunately though, there are some things the operation needs and wants in short order that would help them perform better and they can't wait for a full 2 year project plan and all that. That's where the fun happens. It used to be tasked to some poor supervisor or someone that might be a hobbyist programmer in an area to create something in Access to get them their numbers or perform the task of training someone... yes, they would train people with Access because that's all they had to work with.
Recently though, there has been an upstart of a group that handles "mid-level" operational reporting tools and rapid development tasks in order to take on these one man projects and try to standardize them across the company instead of having 80 odd programs in different states and countries doing the same things (frankly wasting time solving the same problems all areas face.)
Is it the best solution? Probably not. But it's been working. The "start up sub group" has been able to quickly roll out applications (web apps in this case) to the field so they can perform their job easier and more efficient. If they run across something that requires more development, it's pushed up the chain to the dedicated development/systems teams to do a corporate assessment. There's something to be said for project planning and all that, but sometimes it's ungainly slow and cumbersome. In this small group, the developer is usually tasked with talking to the requester, laying out the design and functionality of the application with the user and coding it up on the framework in place. Granted, it's a lot of work on the developer, but they gain a knowledge of what the field needs and can better layout what that niche of the company needs to do it's job in a rather short period of time where the common standard project time line for the dedicated team of developers would take way too long to gather that knowledge, lay out a plan, and code the application.
Re:Choose them all under one. (Score:3, Interesting)
If someone is good at something, ferchrissake KEEP THEM THERE!
I see that finishing a project appears to be a foreign concept to you.
-jcr
Project != Product
Obviously one will finish work on a particular software release, and move on to the next one. But there are usually multiple product lines within a company, and the infrastructure for each can be dramatically different (even using the same tools/languages). It can take weeks to get up to speed, not to mention working your way into a new team dynamic.
IMHO the grand-parent is talking about switching product lines, which is clearly what the original questioner's company is contemplating when they talk about standardizing tool-sets. As someone who gets switched around a lot, I can tell you that it *does* impact productivity significantly --and I'm better at adapting than most (which is why they keep switching me...).
Office violence (Score:3, Interesting)
If someone is good at something, ferchrissake KEEP THEM THERE!
I see that finishing a project appears to be a foreign concept to you.
And I see some members of the upper management haven't been beaten enough with the "Mythical Man-Month" book [wikipedia.org].
Developers aren't a commodity resource you can happily swap around.
Re:Start sending out resume... (Score:3, Interesting)
I couldn't agree more. Saw this happen at the Associated Press. Senior management is devoid of anyone with a clue. If you have one, get out now. Outsourcing is next. Process reorganization is imminent. Town hall meetings with lots of Powerpoints are coming. Team building exercises, interpersonal skills development, and IT management consultants are on your doorstep. The gas-heads minding your store will be an easy sell for them.
Fast forward 4 years...
The 'good' programmers are mostly gone.
The gas-heads have replaced mid-management twice.
Your company has a few projects outsourced to India.
IT management consultants have come and gone by the droves
The huge plumb project to merge all your databases into a warehouse was handed off to consultants, who used a platform different from the 'official' one.
They screwed it up and now there's a million dollars of hardware gathering dust. (that was your raise/bonus money, eh?)
You haven't had a raise or bonus in three years
Moral is.... what moral?
You wished you had left four years ago
Run don't walk. Good luck.
Programmers shouldn't be reallocated too often (Score:2, Interesting)
Inflexibility is career death. (Score:2, Interesting)
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.
I wish (Score:3, Interesting)
In our dreams.
In this reality, the alpha developers get fed up after a few years and find more interesting and/or lucrative work elsewhere. Or they just feel it's time to move on since they aren't learning new stuff (read: remaining competitive) because somebody higher in the food chain thinks you should leave developers in place once they've become the experts.
The deltas, on the other hand, know they have it pretty sweet since they won't get canned unless they really screw up or there's a layoff... and 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.
Completely Off Topic... (Score:3, Interesting)
crush our enemies, see them driven before us, and we will hear the lamentations of their women.
I know this is completely off topic, but you would be amazed at how many people don't know what the word lamentation means. My son's name is Conan, so as you can well imagine people are regularly quoting the movie at him. 9 out of 10 people will either mumble out the word 'lamentation', or outright apologize for saying it in front of a small child. Not for the quote, but for the word 'lamentation'.
Re:Completely Off Topic... (Score:3, Interesting)
How bizarre, I've never even heard of this. What do they think it means?
Re:Choose them all under one. (Score:3, Interesting)
Re:Use Java (Score:3, Interesting)
What I'm discounting is the one-size-fits-all mentality that seems to pervade management circles. There's a fine line between preventing things that are unsupportable (MIPS Assembly Language) vs. preventing people from using better tools for the job (Python / Django for a CMS-like application vs. Java and Struts for the same application). It's the myopic pipe-dream of management that by standardizing on "the one true platform", they can hire the same type of programmer, interchange them efficiently between projects, and replace them when they eventually leave that drives me nuts.