Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've been thinking a lot about the problem of standardization across large companies. For me, the answer is pretty clear: do not arbitrarily standardize on tools just because that's what everyone else does. It's counter-productive.

I'm thinking about source control, bug tracking and testing tools primarily. It seems so obvious to me that I can't really think of many good counter-arguments. Some I've thought of :

  1. Easier sharing between teams
  2. Easier for IT to manage

(1) is definitely true if different teams are working on the same codebase/product. But in cases where one team doesn't work directly with the code I don't think is a valid reason.

(2) is just kind of pisses me off if that's really an argument. The limitations placed on programmers, I believe, is more burdensome than any extra work piled on to IT. But I'm not an IT guy.

I'm hoping for some better arguments than those.

share|improve this question
    
do large companies (> 10,000 employees) do this? –  Conrad Frix Dec 2 '10 at 15:40
1  
The company I work for has over 80,000 employees but we aren't forced into any particular tool. Its up to the team to decide our source control and so on... However I have seen how our IT 'organises' this and it is not pretty. –  rmx Dec 2 '10 at 16:04
    
@Conrad Frix Yes, some of them do, esp financial inst. –  BlackICE Dec 2 '10 at 18:04
    
@David. I find that surprising, since large Financial isntitions have such a large variety of development platforms. I am to understand that RPG, COBAL, Oracle, SQL, Java, C++ and .NET devs share the same Source Control and Testing tools? –  Conrad Frix Dec 2 '10 at 18:09
    
No, but within an environment, i.e. all the same tools around .Net (one team can't use VS2010, another use #Develop), usually source control is the same (ClearCase). –  BlackICE Dec 2 '10 at 20:27
show 1 more comment

5 Answers

up vote 6 down vote accepted

Yes, but it needs to be done in a manner which is sensible and doesn't affect the productivity of developers for the sake of process.

There is definitely a case for standardisation of bug tracking/source control as a lot of enterprise IT is somewhat isolated and distributed. For instance, consultants might be hired to create something for one business unit, in-house staff might be maintaining a legacy system and over in the Republic of Elbonia HQ, another in-house team is working something else.

Common source control and bug tracking systems, place everyone on a level playing field and make it easier to deal with multiple systems. Imagine your support people having to learn 3 different bug tracking systems because each team preferred a different solution. Without standardisation you can also end up with the situation of the consultants using source control system X and in-house using source control system Y (or worse, no SC at all), which will lead to all sorts of fun when the software is completed and the consultancy either moves on or goes bust.

This doesn't always mean you'll end up standardising on the best software available though, often the software which is chosen is based upon compromise and practicalities rather than having all of the latest and greatest features.

Standardisation also requires common sense. There is a level where you just have to let the developer get on with the job without undue interference. Where that line lies depends on the culture of the organisation, the kind of products being worked upon and regulatory factors.

There is more to software than just code.

share|improve this answer
    
YOu said it better than I was going to. –  HLGEM Dec 2 '10 at 22:58
add comment

I would say in the situation described below.

My company has a relatively small IT department aimed at supporting the software used to run the company. The application is written in two languages, Java and RPG. We use Rational Application Developer(based on Eclipse) as our only IDE. There are some other minor programs we also use, but those are mostly the choice of the developer if he wants to use them.

The reasons I see that this is good are, in no particular order:

  1. Easily shared projects. We can save all the project settings in a zip and anyone else can see it without any issues between IDEs.
  2. Easier IT updates. Yes, I think this is a valid argument - within reason! If this "standardization" argument is limiting development efforts by limiting what software a developer can use when he absolutely needs it, it is bad. That's not an issue at my workplace because we only work with a couple of code bases, so everyones needs are basically the same.
  3. Teamwork is optimized. If everyone uses similiar tools, it is easier for anyone to come over and look at your code without having to orient himself to your IDE. With most IDEs now you can customize them to a workspace you like without losing the frame of reference. All console tabs look the same no matter where on the screen they are.
  4. Project switching is easier. Any developer can move to any project without having to learn new ways of doing the meta stuff like version control. The same procedures and software used everywhere reduce context change time.

Overall I'd say that having everyone use the same IDE, version control, and bug tracking software is a good thing, and helps teams work better. Below that though the developer should be free to use what tools he needs. If he prefers TextEdit to Notepad++, let him use that - it won't cost any more. Or don't force him to use a query tools if he prefers to connect straight to the database for simple queries.

share|improve this answer
1  
Your situation is a bit different as RAD has advantages over all other Java IDE's as it can debug both RPG and Java on the AS/400. –  user1249 Dec 2 '10 at 23:11
add comment

You should rather think that your development process should make it easy to use any available tool for your project.

The reasons for this are simple:

  • You need to be able to build and test your software automatically outside an IDE.
  • You may have a facility in IDE X you need but cannot use if you are tied to IDE Y. Examples: GUI editor in NetBeans. Swing debugger in JDeveloper.
  • Procedures captured in files (so they can be automated) can be checked in to a source repository, and checked out again elsewhere. This means more precise knowledge is captured.
  • Building and testing can happen on multiple platforms allowing for easy testing of platform compatability.

By thinking like this, you are best insured against vendors closing products, or other natural disasters.

share|improve this answer
add comment

There is a lot of effort wasted on tool wars. In a really large company, no one can ever "win" and I do not see any benefit in really trying.

"Make it easier to swap resources" - I have never seen this happen once in my company. People make this argument but the actual realized benefits are very, very small. Usually resources aren't "swapped" anyway, and if they are then it doesn't take long to learn most of these systems.

"Easier for IT" I can't see this argument anymore, since we have a relatively small SDLC tools team that supports pretty much every major vendor product there is for tens of thousands of users (across all tools).

Many individual teams are more productive than they were a few years ago when there were fewer tool chains and many of them were optimized for different platforms than what any given particular team was actually using; or the infrastructure had to be local (cough ClearCase cough) and most of the company couldn't even use them.

share|improve this answer
add comment

Within a department I can see this making sense. There should be a central store rather than a bunch of different systems to look up bugs or code. Does it help to have to look in a handful of different bug tracking systems to find issues? I don't think so, but I don't think all the departments uniformly should be forced onto the same system as that may not make sense.

At the same time, I'd argue that departments are a reasonable threshold for how far a set of tools should go. For example, I have worked where IT had one bug tracking system and Product Development had something else. Same for source control and languages.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.