Fog Creek Software
Discussion Board

Standardizing a Development Team

How much value can be ontainined by standadizing a development team on common set of tools like IDEs?

Developers in a team that evolved organically may use different set of tools and methodologies. This can be inefficient if a developer has a problem and posts the questions - the others may not be able to help her as rapidly as they use a different IDE and the question is subjective on the IDE.

However making the developers standardize on tools and methodologies can be tough politically - and there will generally be a period which will have "growing pains".

Ram Dass
Monday, September 22, 2003

Well, if you want to do XP's collective code ownership and pair programming, you really have to standardize your development environment.

You can't pair effectively if everyone's got a different set up on their box. You can't pair if everyone's following a different coding standard.

You can't do collective code ownership if development of a particular chunk is customized to a particular environment.

Even if you don't like XP, you'd have to question why you'd want to let your developers run around and basically set up many different solo development environments. Are they working as a team or not? If they really want to work solo, let them go find a job where they can do that.

Monday, September 22, 2003

I am 100% with Anon.  Differing tools, methods and approaches is just asking for trouble later on.  Some decide C++ is the way to go, another likes JAVA and a third wants to try C#.  What happens when you have memory or interface issues?  Who gets to debug through multiple languages?

So you all agree that you should use the same language, but come on standards?  Naming conventions?  What is the point?  Well, nothing if you don't mind that reading:
A_allocate_main is meaningless until you find the definition or that addition_table and add_user and add_new are all the same table, but no one knew it so they created their own.  Oh, and someone was have a problem getting results so they read all three each time to avoid missing a record...

Commonality is good.  Evolution is good.  Sometimes even revolution is good.  However, a super majority of the team should agree on something new before it is introduced.  I have been called into too many teams where they "had a guy in for a couple of months" who used a tool they did not know and now it runs a critical sub system... or it did until Friday when it stopped doing anything but rebooting the server.

We now return to our regular program.  Sorry but this is one I have seen to many groups fail to see as an issue before it became a problem.

Monday, September 22, 2003

Standardizing on what the code looks like
(language, tests, naming conventions, etc) is very different
than standardizing how it is produced.

One reason i don't like pair programming is the
straight jacket it puts you in. I like vi. Others like
eclips, emacs, visual c++, etc. It's more than just
like though. I am more productive in certain environments
and you want to take that away from me.

Sorry, not for me.

compile error
Monday, September 22, 2003

compile error: Believe it or not, human beings have the capacity to learn new behaviors. Being productive in another environment is one of these behaviors. Yes, it's a learning curve, but being a worker in an industry that changes direction every six months or so you're used to learning new things, right?

Chris Winters
Monday, September 22, 2003

In a development team that has a few members that are individualistic in behavior, how would it be best to bring common standards.

It can be challenging to standardize on, say, would it be best to bring about the standardization of naming conventions?

Ram Dass
Monday, September 22, 2003

For very small teams it may be ok to work without a standard. But for larger companies one must buy and maintain licenses and support. Then you must standardize.

Monday, September 22, 2003

It would be a complete waste of time.

Concentrate on things that matter:  delivering bug free code, developer initiative and willingness to take on new assignments without being asked, to debug bugs that are not necessarily theirs.

Forcing one person's view of what "code should look like" on to a team, or pushin an IDE is a terrible idea.  Its the worst notion that XP puts forward - as well as the notion that each person is a "generic programmer".

nat ersoz
Monday, September 22, 2003

The original poster asked "How much value can be ontainined by standadizing a development team on common set of tools like IDEs?". (He also confused the issue by throwing in a mention of "methodologies" which some posters jumped on, but I'll set that aside as appropriate for another thread)

I have certainly been frustrated at times trying to use a team member's IDE if it's not the same one I normally use, and it would be nice to avoid that.

On the other hand, if you have a "standardized" set of tools (read: imposed by management or technical lead), then it encourages group members to think that finding useful tools is someone else's job. [See the often quoted on why that might be bad]. This tends to lead to people not using new tools that *would* be helpful because "you can't defy the standard".

[I certainly see that pair programming could be harder with different IDEs in use. But, I bet that a lot of places that would mandate an IDE would do so out of a reactionary anti-programmer attitude that would also lead them to forbid pair programming.]

Exception guy
Monday, September 22, 2003

Why would I ever use someone else's IDE?

nat ersoz
Monday, September 22, 2003

You don't make it a habit of driving someone else's car do you?

nat ersoz
Monday, September 22, 2003

This is really only a problem in UNIX development as I see it. Say your team develops some application for Windows, and you would probably use a language like Delphi, Visual C++, C# or god forbid Java :-)

Thing is, the most commonly used languages for Windows development comes with its own IDE, The Microsoft line of languages has one, as well as the Borland line of languages. These IDEs are optimized to work for the language they are tailored for obviously. The IDE knows about language constructs and such.

Back in UNIX-land is where you'll find the Emacs die-hards or vi aficionados that will not have it any other way. This is no problem as I see it, since UNIX development is less integrated than the Windows tools.

Produce a textfile, run make, and debug using GDB.

I have yet to see a Windows developer use vi or emacs or other editor instead of their tailored IDE for their specific language.

Feel free to disagree.

Monday, September 22, 2003

Does your team wear the same uniform?  I am sure that
is a new behaviour you could learn and conform to that would increase productivity.

Absurd? Not any more than requiring everyone to use the same environment configured in the same way.

As a professional i know what environment is best for me
to work in. Adopting something for forms sake is
why i hate corporate environments.

compile error
Monday, September 22, 2003

>But for larger companies one must buy and maintain
> licenses and support. Then you must standardize.

If you expect the company to buy your environement
then i agree, this can't be done. But there are many
free environments out there that many people like,
which side steps the issue.

compile error
Monday, September 22, 2003

How about larger companies - that have a a multitude of clients? And the work produced by a developer today may have to be debugged by another developer two years down the road.

In these types of scenario - would it not be better to have standardized IDEs and naming conventions?

Ram Dass
Monday, September 22, 2003

Code style is very important. Why? Because other people need to read it. The exact style doesn't matter so much as everyone learning and using the same style.

OTOH, the tool used to write the code is mostly irrelevant. You can write your own code generation tools driven by a telegraph key. So long as the output is correct and a style understood by all.

As for pair programming, I've never done it. But presumably whoever is at the keyboard uses their editor of choice, and you can switch back and forth if the roles switch.

(Yes, I've seen windows developers use vi and emacs and various windows dev tools and visual studio. often multiple people with multiple editors on the same team.)

Monday, September 22, 2003

Ram Dass,

The IDEs and naming convention usually solves themselves if you hire competent developers.  Most developers with experience in a language solves the problems at hand in roughly the same manner.

What I mean by this is they often use the same algorithms, and have read the same books, and are at the same level of maturity coding wise.

These centrally administered development environments are for programmers that have no own drive or are unwilling to learn by themselves. If you have guys like that you may need to enforce things, to get something at all done.

Monday, September 22, 2003


You wrote: "This is really only a problem in UNIX development as I see it."

Nope. The Microsoft C++ IDE isn't so spectacular that you will never find a smart person who writes their code in Emacs (some people I work with use Emacs, but not me).

Exception guy
Monday, September 22, 2003

[As a professional i know what environment is best for me
to work in. Adopting something for forms sake is
why i hate corporate environments. ]

Uh, yeah, it's all about you.

Look, you wanna go develop solo, then go develop solo. More power to you. Knock yourself out.

Unfortunately for you, the vast majority of all software is developed by teams. There are distinct advantages to everyone working with the same tool set, if ONLY for the ability to help each other out when someone runs into trouble.

Is it really so much to ask to have people try to reach a consensus on a decent environment and then stick with it? Sure, you may not be able to use your favorite tool, but that kind of compromise is called being an adult.

Not adopting something to preserve a solo development mentality is why I hate cowboy programmers.

Monday, September 22, 2003

It is the solo mentality that is doing us in.  Yes, being the cowboy pays big, but companies are starting to recognize they are paying big dollars because they let the cowboys lose on the range.

Here is the issue with people who think standards do not matter, or that good people have good standards: it is not true.  Good people have good standards that work for them but conventions that are different, by developer, make reading the text near impossible.  This leads to this paragraph.  Someone followed their standards and  I understand it because I know it, but would you really think it is easy to debug? (yes this is a real sample)

Even if you knew what it did?  Sure it is a bit extreme, but who steps in to pull these people back from the edge?  Who eliminates the sloppy programming we always hear complaints about?  If you have no standard to measure against, who is to say my example is not pristene?

package der;
sub init
    my ($self, $source) = @_;
    $self->{der::_handle}    = new IO::File("<$source");
    $self->{der::__lastread}    = undef;
sub next
    my ($self) = @_;
    $self->{__lastread} = $self->{_handle}->readline();    # "der::_handle"

package main;
my $io = IO->new("from","to");
print $io->okay;

Monday, September 22, 2003

As for the MSFT IDE... one of the few possitive things I took away from my 2 years of endentured microserfdom was a love of Slickedit.  Most SDE's were using it...

nat ersoz
Monday, September 22, 2003

anon: at some point is about me because it is eventually
my creativity and work that creates the code. How
is that cowboy programming? I never said anything
against having coding standards, SCM standards,
methodology standards, testing standards, etc.

But i do say something about how i work because
i definitely work better working in a certain
fashion. If that makes me a cowboy programmer
then that name means nothing anymore. Or
rather it means anyone who doesn't do what
i think they should do.

compile error
Monday, September 22, 2003

MS Hack, the regimentation you seem to be espousing is something that characterises the bottom rungs of the workforce, and it's for the benefit of management, not for those doing the work.

Only the hopelessly naive would embrace it as being in their own interests. Sadly, a lot of programmers seem fit this gullible mode. Pair programming is another manifestation of this gullibility.

Other professional groups such as lawyers in a firm, accountants in a firm, academics in a university and so on give their people as much latitude as is consistent with the overall aims of the firm. Those people would certainly not tolerate the attempts at uniformity that we seem to be talking about here.

Secondly, your comments about companies apparently realising there was some problem with their software development and logically adjusting their pay rate displays extraordinary naivity. It is the cowboys who are doing the shafting, MS Hack. Other cowboys occupying management positions in outsourcers are also still going strong, raking in the money by replacing local programmers with cheap overseas ones.

Monday, September 22, 2003

I would not work for a company that forced me to use a specific code editor or IDE.  The amount of time you save by using the IDE (or text editor) you are comfortable with is well worth the risk of confusing a co-worker if they need some help.  You're helping them with CODE, not the editor. 

If your editor mangles the code and you check it into CVS, sure, that is a problem.  But fix the PROBLEM, don't force everyone to use the same IDE, that's nonsense.  Some people develop better with visual environments with a lot of fancy buttons.  Some people, like myself, are much better and faster with editors like vim which allow an endless number of shortcut keys to be defined.  All editing behavior is handled at the keyboard.

Frankly, not all programmers are created equal.  I type something like 120WPM.  I sit for a while, think about my code, then type it... FAST.  People watching over my shoulder are constantly amazed, and I've even had people come to my cubicle and tell me that I'm typing "too loud."

Drop me in an unfamiliar editor and my productivity drops drastically.  I can learn it, sure, but who's to say it has all the features that make me such a fast and efficient coder?  Is a permanent 10% decrease in productivity worth a standardized IDE?  I don't think so.

Where I work, here is the breakdown:

me: debian/vim
other programmer: windows/some gui IDE
lead developer: mandrake/jedit (java editor)

Let's discuss how else this comes into play.

Were I to switch to jedit (the java one mentioned just above), not only would I be forced to switch editors, I'd also be forced to fundamentally change how I interact with my computer.

Right now, I use aterm as my file manager.  I don't use any graphical file managing tools whatsoever.  I often have a half-dozen editors open at once, and I use IceWM's taskbar to keep track of my windows.

Jedit is written in java and takes forever to load.  I can't cd into any directory and type 'jedit filename.c' and have an instant editor window open for my use.  I'd be forced to start leaving an editor window open and using their internal tabbed interface to do my work.  I'd have to use their graphical file manager, forcing me to grab the horrid mouse on a regular basis.

Forcing someone to change to a specific IDE can have far-reaching consequences.  As I mentioned at the top of this post, I would quit my job if they forced me to switch.  Yes, I am confident enough that I can find another job that allows me the editor I want.  Companies should care about quality of code, not what editors people use.

Monday, September 22, 2003

[Forcing someone to change to a specific IDE can have far-reaching consequences.  As I mentioned at the top of this post, I would quit my job if they forced me to switch.  Yes, I am confident enough that I can find another job that allows me the editor I want.  Companies should care about quality of code, not what editors people use. ]

Yeah, riiiiight.

I'm going to hire someone who is completely unable to work if they can't use their personal IDE. I'm going to hire someone who would quit a job rather than compromise. Yah, that's going to happen.

Hey, I've got an idea. Let's put your money where your mouth is. You quit and go to an interview. You make sure you tell them, UP FRONT, that you'll quit if they force you to use the standard development environment. Just like you told your current company, right?

You guys kill me. You say you're the "uber" coder who's carrying the rest of the team and that you can't change the way you work because that would interefere with your "efficiency". You're this god and yet you can't adjust to a new development environment. You haven't actually tried this new environment, mind you, but you know it couldn't possibly be as good as the one you've cobbled together.

Btw, you know someone is totally bullshiting you when they start talking about their efficiency. You don't give a rats ass about efficiency, you just don't want to be bothered working with anyone else.

I'd actually respect someone if they just came right out and said "I don't like other people. I don't want to be bothered working with them. My view of the team/company is limited to a 4' radius around ME". Damn that would be refreshing instead of all this bull.

Monday, September 22, 2003

You can't make me use emacs.

That is all.

Monday, September 22, 2003

anon, how do you equate "choosing a development environment" with "working with other people?"  They're two totally separate things.  I work with the other developers on a regular basis.  We all use different environments, and it's not a problem.

Why would I quit my job?  I didn't EVER say I was not willing to compromise on anything, just this.  There are thresholds for everyone.  If they put you in a cold, noisy room, and you chose to quit because you couldn't code in conditions like that, does that mean you're not a team player?

We pick technologies BECAUSE of how diverse they can get.  We use jabber because there's a zillion clients out there and everyone likes a different one.

I never said I could not code under a different IDE, I said I would not.  There's a huge difference.  I find it a waste of my time and an ethical problem if I'm only producing 70-80% of what I could be producing.

I never said I was an uber coder that carries the rest of the team.  I'm working on a project that was created over a year ago.  I wasn't in on the initial design.  I'm a maintenance/feature coder.  I do bug fixes and add features.  I do rewrites of problem areas.  I do performance enhancements.  We have a small group and we all work well together.  NONE OF THIS HAS ANYTHING TO DO WITH WHAT IDE I CHOOSE TO USE.

I also work for a relatively large corporation (>500 employees), and not once have they told me what OPERATING SYSTEM to use, much less what text editor.

Monday, September 22, 2003

I pretty much with the "use whatever tool works best for ya" crowd, except in a few cases.  For instance, there's no way I want everyone using different code generators for things like drag/drop GUI construction. 

Another thing that I think exacerbate perceived problems is when everyone's moving into something new.  For instance, I remember when my team started using Java.  Some were using SlickEdit some were using VisualCafe and some were using other stuff.  Trying to help each other figure out problems with classpaths, how to set up the compiler correctly, and all that was a real pain in the arse. 

So I guess I don't have a problem with people using their own tools when they know how to use them.  It is problematic, though, when they don't...

Monday, September 22, 2003

Getting everybody on the same IDE sounds like a search for the holy grail.  I just wish my organization could agree on a language/platform and some basic coding style standards.  C, C++, ASP, JavaScript, VBScript, Java, Visual Basic, ASP.NET, C#, etc. all in an organization with about 10 developers and 100 employees total.  We've got Windows-only apps running in Citrix on xterms and UNIX apps running in Exceed on PCs.  Cowboys loose on the range indeed.

Monday, September 22, 2003

anon (from a few posts back) I think your quest to force others to your own personal preferences is really a form of intolerance.

It's also a way that arrogant newbies can attempt to assert superiority. Software development is a field without clear, commonly accepted markers of expertise and standing.

The result is a status vacuum where arrogant new programmers can assert that they know more than everyone else, and bolster this using sociological devices like the way someone formats their code, what editor they use, and so on.

Pair programming, for example, is nothing more than a test of whether someone agrees to accept a certain social regime.

Your rolled out a few hiring scenarios. I've seen places such as the one you probably work at. They're characterised by shoddy work camouflaged under mountains of dependencies and the latest buzz words. But you don't get paid much. There's the rub.

Monday, September 22, 2003


There's more than one "anon" person posting in this thread.  It's kind of like the Anonymous Coward on Slashdot.  The anon who wrote the post you just responded to was not the same anon that wrote the post earlier in the thread.

Monday, September 22, 2003

Next we'll be telling carpenters that they have to standardize on the model of hammer they use.

We'll tell accountants they have to use the same model of calculator.

We'll tell doctors they all have to have the same model of stethescope.

We'll tell the journalists they all have to start using the same model of typewriter, the same brand of ribbon, and the same type of paper.

All photographers will be required to use the same model of camera and the same set of lenses.

Any professionals found using different tools will be eliminated.

Or so speak the anons.
After all, they know everything.
Why it could be Bill Gates or Larry Ellison hiding behind the anon-de-plume.
At least they've standardized on a name to call themselves.

All must follow.

Dennis Atkins
Monday, September 22, 2003

There are actually two different scenarios here. First is the company that forces *solo* programmers -- that is, those who never collaborate directly with others -- to use the same IDE/editor. IME this is unnecessary since code is just text and programmers churn out code (among other things). (If your build process is tied to a particular IDE/editor you have bigger problems.)

OTOH, if you're in an environment where you're working directly with other people, particularly pair programming, then there are a number of benefits to standardizing on a good tool. (Nobody's arguing that you standardize on a POS.)

First, switching between editors when you pass the keyboard is a PITA and interrupts flow. Second, knowledge about how to best use the IDE/editor (shortcuts, macros, plugins, etc.) gets spread throughout the team. Everyone wins and becomes more productive.

And now broad generalizations: Unix folks would do well to get over their notion that everyone who uses an IDE is a wizard-clicking dingdong. In fact I might even go far as to say that exposure to certain IDEs (like IDEA or Eclipse) would broaden your horizons, if only to spur ideas for new macros/plugins for your beloved editor.

Similarly, people who have never ventured beyond the IDE should give emacs, vim or some other 'bare' editor a try. Once you think of your code as just text and not a product only reachable via the IDE then you venture  into various automation strategies and mass update modifications that some IDEs simply don't give you.

Chris Winters
Tuesday, September 23, 2003

[Any professionals found using different tools will be eliminated.]

You need to get over yourself. Quickly.

Hey, we're the freedom loving corp of programmers! Defenders of freedom! They can take my text editor from my cold dead fingers!


Give it a rest.

If a company actually said: "Hey, we think having lots of different tools is a great idea. Knock yourselves out.", then there's no argument. But we all know what really happens. Developers bring their little toys on their own. Freedom to choose, hetergenous environments, it's all bullshit. In the end (and the beginning) it's just all about me.

It's the same mindset that ends up with code trolls. You know, the developers who "own" a piece of code and defend the walls of their domain like, well, programmers defending a twinkie. You know it's true. In fact, the more arcane and indecipherable the development environment, the better. Keeps all those other nosy parkers away from my code.

It's my code, dammit! Mine! It's, it's.... me precious.

not anon
Tuesday, September 23, 2003

This is really amusing. I mean, how hard can it be to get together with the rest of the coders in your group and get some consensus on a set of tools?

As on of the last posters said, no one's suggesting you use some POS. But is it really the end of the world if you give in and switch editors so theirs some common knowledge base?

Phew. Glad I don't work where you guys do.

Junior programmer
Tuesday, September 23, 2003

anon (number 2) - thanks. Yes, I picked that up about more than one anon. I was actually replying to the anon from a few posts before that.

Tuesday, September 23, 2003

What it's about is getting on with your work and not wasting people's time with irrelevant crap.

Let's all have a meeting and decide how many pencils are allowed on people's desks.

And junior, don't worry, you won't be working where I work.

Tuesday, September 23, 2003

Why get all religious about it ... why not just do whatever works?

In some situations standardisation is going to make sense. If you're developing a GUI app and using a GUI builder, you'd be foolish not to standardise on it. Likewise you'd want all your dev team using the same source control system.

But little things like a text editor? Probably not going to be any benefit in standardising on that. A text editor produces text like any other, so the output is not dependant on the tool used. Standardising it will just breed resentment and lower productivity for no gain. Pair programming could be an exception to this rule, although one could argue anyone pair programming doesn't care about productivity anyway. ;)

Standardisation or not, just be pragmatic about it. The goal is to produce the best product you can in the least amount of time possible, not win some stupid holy war on an idealogical basis.  Evaluate individual standardisation decisions on their own merits.

I think you'll find if you do that, then you'll nearly always find it pays to standardise on major things that are shared between team members, and it's not worth the bother to standardise the minute details or stuff that's only ever going to affect the individual.

Sum Dum Gai
Tuesday, September 23, 2003

Anon (well, one of the multiple anons),

>> Btw, you know someone is totally bullshiting you when they start talking about their efficiency. <<

On the other hand, I know someone is talking bullshit when he starts talking about how forcing developers to use a single dev environment/IDE promotes a "team efficiency" :)

I hire developers regularly, mainly for my clients, but also occasionally for my own company. In 20+ years as a developer, team lead and project manager, I've never forced a team to standardize on a dev environment (as opposed to a dev process).

So now I'm confused. Where have I been going wrong all of those years? Why haven't my projects fallen apart because one developer uses vi, one uses SlickEdit, and I use Visual Studio? Perhaps 20+ years of mainly succesful projects is just a lucky fluke, and the lack of a common dev environment is just lying in wait to strike me a deadly blow in the future?

Author of "Comprehensive VB .NET Debugging"

Mark Pearce
Tuesday, September 23, 2003

There is a big difference between standardizing on what tools you use to develop with, and what tools/process the project is built with. The latter defines everything from what language is used to acceptable code style to how the project is built to ....

Who really cares what IDE/editor/tool I use as long as I can check in the source, build it, test it, deploy it etc. per the projects standards? That doesn't mean its a bad idea to have a default recommended environment. However, most good developers I know regularly change tools/IDEs as needed during a project, even though they typically spend most of thier time with one.

Eric Moore
Tuesday, September 23, 2003

"I have yet to see a Windows developer use vi or emacs or other editor instead of their tailored IDE for their specific language"

I have used vim instead of an IDE (although I admit
that Microsoft's isn't that bad) and have never
regrettet it.

char* full_name()
Tuesday, September 23, 2003

While I do think it'd be nice for programmers to be interested in new IDEs, a lot of people have invested time in sculpting emacs into an incredible tool.

However, there are very few scenarios I see where you can't work with both emacs and the standard IDE.

Tayssir John Gabbour
Tuesday, September 23, 2003

*  Recent Topics

*  Fog Creek Home