Summary
What matters in the end is working code, not the tool that made it. I propose that developers buy their own tools and be held responsible for installing, maintaining, and dealing with them just like auto mechanics do.
Advertisement
This weekend I helped a friend wire his new house I did many things before I was a developer. I showed up early in the morning with my tool belt and started in. Reread that last sentence. I said I showed up with my tool belt. My friend didnt go to the store and buy me a belt. Why should he. He doesnt know if I like a 16oz or 18oz hammer. He doesnt know if I like reversible screwdrivers, he doesnt know what kind of wire strippers I like. All my friend knows is that he owes me big and the inspector is coming on Tuesday.
So as I pig-tailed outlet after outlet I started thinking why do so many development shops enforce a tool standard? By tools I mean things like Eclipse, Forte, JBuilder, JDeveloper, etc. What does it matter if I use vi and you use Eclipse? In software development there is one very important thing that matters and thats working code. Did you read that working code? At the end of the day do you check in your IDE? At the end of the day does your IDE get backed up? Do you give status reports about your IDE?
Heres the simple truth. The success or failure of a project largely rests in the code that comprises it. That code is produced by a crazy group of people known as developers who are more like artists than engineers. Each of these new age artists has a favorite tool just as Michangelo had a favorite brush. I propose letting the developer choose his or her favorite tool and just worry about the code in source control. Dont worry about how it got there. Do you think Michangelo would have painted so well if the Pope told him what brush to use?
If youre a developer you probably like what Im saying. If youre a manager you must likely dont. A manager is concerned about many things, but most notably is time and money. To a manager this idea means licenses for a variety of tools and support for all of them. Thats a lot of time and money and theyre right. So my solution is this the developer is responsible for their tools. That means they are responsible for its purchase and maintenance. This is exactly what happens with electricians, plumbers, and mechanics. When they get that first job they have to buy their tools. When they switch jobs they take their tools with them. The same can happen for programmers.
To implement this idea you just need a few ground rules. The company outlines infrastructure pieces like versions of make, ant, Perl, Java and a source control program. Additionally they would define the application, LDAP, and database servers. The company is then responsible for these items, the same way a car dealer is responsible for the lifts their mechanics use. The developer is responsible for the tools they use to make the desired software. I say this includes the hardware they use. That means the purchasing, installation, maintenance, etc. The company just provides a network drop, accounts on needed servers, and other core infrastructure needs.
The end result I foresee is a happier development team with increased efficiency. No longer would managers who dont code dictate how to code. No longer would programmers be able to blame their tools. Just image it the focus would be on the code with no excuses.
It's a bit tricky if, for example, you live in a shop that practices pair programming if each individual developer can choose their own tool. Emacs and vi users don't mix well in a pair ;-)
Management shouldn't choose of course :-) But I think it's a much better idea for the development team as a whole to agree a common set of tools than it is for each developer to follow their own way.
In fact, more "ground rules" required. for example, every firm is likely to (or should) have its own coding standards, like tab-to-4-spaces, new line with opening braces, spaces between if and (, etc... Not all tools support these. Sometimes integration with app-server, case-tools, etc, that leaves no other choice to the manager, and the team.
Yes, indeed, if every developer can use her/his perferred tool is the best thing.
When I demo the IntelliJ from Idea (now Jetbrain) to the team, everybody fell in love, and everyone started using it, and all are happy developers :-)
I too work in an XP shop and the pair programming is a bit difficult. What I am finding out is it just takes longer to switch drivers and more back seat programming happens. I mean those typing type longer and when it's decided to switch it takes longer to start up the other persons tool. This initial cost is easily offset by the effeciency gains of using a familiar tool. The trick is to make the working copy of the code available to each tool.
At my company we use NFS servers and <a href="http://wwws.sun.com/hw/sunray/sunray150/index.html">Sun Ray Client</a>. Using this approach changing drivers is nothing more than switching smart cards, and pointing what ever tool to a new code base.
The coding standards one is something which is sometimes difficult to resolve, even in small teams. I've found that formatting of code is a hugely personal thing, so the only thing worth settling on a standard for is the naming systems (classes, methods, packages, member variables, and so on).
Why don't source control clients provide a way of formatting the code to the user's preferences when you check out? There are already plenty of tools with which to do this, so you should just be able to write a plugin or script which is fired on a checkout event.
You may need a standard formatting on the server to help with diffs, however, but that's just the same process backwards.
> Why don't source control clients provide a way of > formatting the code to the user's preferences when you > check out? There are already plenty of tools with which to > do this, so you should just be able to write a plugin or > script which is fired on a checkout event.
In fact this is already possible with CVS at checkin-time. There are some special 'control' files in the CVSROOT directory which can contain calls to other programs whenever files are checked in. At the company where I worked last year, we used this to format code (using UNIX' indent command) and to automatically call unit tests on each java file that was checked in. If the unit test failed, you couldn't check it in.
At the last 2 companies where I worked, I always brougt my own Notebook and worked woth my own Software (JEdit, vim, OpenOffice on Linux). Whenever I hit a technological lock-in, I was in the fortunate position to have some say about it - and changed it. This way I always changed the working environments bit by bit to be platform and tool independent, at least at the client side. I have always had good feedback about this. It seemed to me, that the management doesn't know what's good for developers but they were always happy if I told them my opinions. If the developers never speak up, nothing will change for them.
> In fact this is already possible with CVS at checkin-time. > There are some special 'control' files in the CVSROOT > directory which can contain calls to other programs > whenever files are checked in.
Yes, CVS has such "plugin" feature that can pre/post-process source code, and there is such formmatter for java. However, we didn't use it as 1, nobody is very familiar with both and 2, everybody uses the same IDE (IntelliJ), formatting can be done easily.
I hate being negative, but I have to speak out on this one. I would love to be able to bring my own set of "tools" to the job everyday. I would know my way around them, the would fit me, I know the quirks, the pluses, the minuses etc. Yet, on a large scale development project, such as the one I am on now, there it way too much we develop that is dependent upon the IDE. I don't mean the code so much, as the configuration of the IDE itself. Unfortunately, our project is made up of several small teams. These teams are somewhat removed from the others except for the interfaces that appears between each funational group. We are currently developing with WSAD, which is a nice enought tool, without getting into performance issues, yet has a "proprietary" configuration that can be shared amongst developers via the SCM. Now what happens when I add additional dependant jars to my WEB-INF/lib and someone else is using a totally different IDE? They are now required to maintain those classpath settings themselves. To me, with a team of 40+ developers this leaves way too many opening for errors etc. Being the "build master", I deal daily with build erros due to conflicting jars, classpaths, and the like. Also, what about our local test environment. We run WebSphere single server edition, cause it's built into the IDE. We also have a dataaccess framework the facades the datasource implementations etc. I would then be required to provide an implementation for each test environment that someone wanted to work with. Don't get me wrong, I really would love to develop with my own chosen set of tools. I just don't think it will work in every instance.
I'll be the first to admin this is not the right solution for all cases. I can't image a solution that is applicable to every development project. Why is this? Projects are made of people and people vary greatly and interact differently. The team I have right now is nothing short of amazing which is probably why this idea works so well. I think it can still work for larger development efforts as well. Within my team there are vi, eclipse, and intelliJ groups. Each group acts like more like a support group and we even have separate SCM projects for Tool dependent configuration files. These Tool SCM projects are requirements free meaning management (me) could care less what is in them. They are for the developer and thus the developers' responsibility. When someone adds a new jar that has to make sure it compiles (via ant) and passes all tests. Once this happens they check it in and our SCM sends and email of the change. Often times the originator of the change will check into SCM the changes they had to make to their Tool which sends an email to the group using that tool of the change. As far as a test environment each developer has their own instance on a separate server (they also have their own tablespace). We have ant scripts that deploy the ear and perform tests within the container. I like this approach more than using the built in tool version of the server because you're actually testing the way it will be in production. The key is youre not dependent on the tool, but rather the code. A less skilled developer will have problems working like this. Is this bad though? I give performance reviews based on the code developers produce (and a bit more). This means if a developer can't handle the addition of a new jar to the classpath - it will hurt them. If a developer can't handle working on multiple systems with multiple JVMs - they shouldn't be writing distributed code. I don't mean to come down on people, but if you own a business (as many of you do) it comes down to money. I have investors to answer to and the answer they are looking for is in the form of dollars. If a developer causes the timeline to continually slip because they can't get their tools to adapt, I have to tell my investors that the product will be delayed. They will quickly tell me to find other funding. At which point I have to tell all the developers to find new work. Okay, maybe it's not that bad, but you get the idea. I guess that might be the underlying point of my weblog - no excuses. I don't have the money to keep people on because theyre nice. You can read me saying, buy your own tools as here is a piece of rope thats long enough to hang yourself or get the job done - it's your choice.
I sympathize with Randy - the websphere/visualage lockin sucks big time - it's difficult to code EJBs for websphere using anything other than visualage. I've been fortunate enough to be able to work exclusively in Emacs for the past 3 years (I've changed jobs in that time) . The company where I work has an 'approved' IDE but there are enough Emacs users so that we don't feel ostracized. Emacs is free and well suited to almost everything.
We don't have nearly enough infrastructure to support this. And unfortunately, the development staff either. Your comments about the developer being able to adapt to this environment are true. Yet, we have to live with some that cannot.
Hmmm, maybe I should consider coming to work for you Matt, ;-)
> We don't have nearly enough infrastructure to support > this.
I think it's probably the other way round that there is too much infrastructure dependence in the teams that some developers can't work without an IDE (esp integrated with backend servers).
As Matt pointed out, "The key is youre not dependent on the tool, but rather the code.", The code here means not only the source code but also test cases code, build scripts, and any other configuration files (eg. ebj.xml, etc.) that are required.
Developers check out/update the CVS repository to his working sandbox, making changes, and run the ant build script (which is also checked out from the cvs), once build and test cases pass, commit the changes back to the CVS repository.
A baseline has to be set that the build is a standalone environment and process that is completely independent on any IDE.
I guess I did not clarify myself on that statement. We don't have the infrastructure to support seperate table spaces and individual app server instances.
> I too work in an XP shop and the pair programming is a bit > difficult. What I am finding out is it just takes longer > to switch drivers and more back seat programming happens. > I mean those typing type longer and when it's decided to > switch it takes longer to start up the other persons > tool. This initial cost is easily offset by the > effeciency gains of using a familiar tool. The trick is > to make the working copy of the code available to each > tool.
I've tried working this way (with a box switcher rather than a SunRay - dreadfully low tech I know :-) and for me the loss of immediacy in switching drivers really had a detrimental effect on coding speed/quality.
Having that immediacy - being able to grab the keyboard as soon as you see a way of fixing something - was too important to lose. This made it worth while for me to abandon my trusty BBEdit and (ew!) relearn vi.
Previous Topic
