In March I wrote an article in CM Crossroads that argues that as long as a team and it's individuals are productive, there isn't a lot of sense in imposing a standard IDE on a team. Organizations go overboard with standards sometimes. As long as a developer is productive, and doesn't cause problems for others, why should anyone care what tools she uses? I end the article:
There is a difference between consistency in important things, which is valuable, and conformity, which is often mistaken for consistency. Focus on delivering consistent results, and respect that a team will know how to get there.
I've been thinking a fair amount about how to balance IDEs and the build configurations, since this seems to be a problems teams struggle with often, though it is getting better as IDEs can model their project settings off of the information in Maven POM files and the like.
Read Beware the IDEs.
Thoughts about agile software development, software configuration management, and the intersection between them.
Monday, May 25, 2009
Subscribe to: Post Comments (Atom)
Branching and Integration Time
Discussions about branching often focus on the wrong thing. Unintegrated code sitting around slows teams down, whether the code is in a bran...
My main development language is Java, but I also some work in Python for deployment and related tools. Being a big fan of unit testing I wr...
This is a bit off of the usual “Software Development/Agile/SCM” theme that I usually follow, but it does fit into the theme of accidental si...
Being a fan of Continuous Delivery , identifiable builds, and Continuous Integration: I like to deploy web apps with a visible build number...
Post a Comment