How often do you reevaluate and upgrade your development environment and dev. tools?

Question

I was curious how often other software developers reevaluated their development environments and tools. I used to work at a large corporation with rigid toolsets that everyone hated, but could do nothing about. So nobody ever really updated their development environments because we couldn't in that environment.

Now that I'm in my own start-up I find I can spend endless time evaluating new tools and development environments, but that I really shouldn't and can't afford to. I've committed to spending 1 day a month looking at new development tools and trying them out to see if it is worth switching.

How often do you try out new IDE's, editors, bug tacking tools, debuggers? Or update to newer versions of your own?

Answer 1

It's an ongoing process, but I don't make major changes more often than every two years or so. A major change involves too much time, and the tradeoff isn't generally worth it. Major changes might be defined as changing the whole target or compiler architecture and toolchain for an existing project.

Note that major changes can occur between projects - a new project can settle on a completely different architecture and toolchain with no significant cost. But care should be taken not to go too bleeding edge here. An evaluation process is needed to prevent selection of a setup that will not support the project later as the project grows in complexity.

But for minor changes I simply upgrade my tools and environment as I find opportunity and reason to do so.

Answer 2

For me, upgrades are event-driven, not timer-driven. I keep my ear to the ground for new tools (libraries, IDEs, CASE tools, etc) and evaluate them as they show up on my radar.

Working with Microsoft technologies, I move to the newest version if there's no compelling reason holding me back. With OSS, I use what I know unless there's something compelling pushing me forward.

Answer 3

I only update unless I'm really missing out on a certain piece of functionality, or realize that NOT using one tool instead of another leads to more tasks taking longer/being less efficient.

Answer 4

At work, we upgrade a tool when our version reaches end of support lifetime. We upgrade to the next-older version.

At home, I upgrade as soon as I can find a copy of the new thing free (i.e. some deals where attending 3 webcasts will send you a copy of vs2008 std edition, user groups, etc.).

Answer 5

IDE's. I tend to stick with one I know will grow, and support my language. In my dev environment it's vim. It is actively developed, and has many many scripts(kinda like plugins) as well as documentation for DIY. Also leaning an IDE takes time, and becoming good at it, using it efficiently takes more time.

Revision Control. I try to stay just below the bleeding edge. The benefits of new features are important. For example Subversion 1.4, only supported rudimentary merging. Subversion 1.5 has overhauled their merging system, and added new features.

Task and project management. I tend to do that only every couple of years, and only if there is a good perceived benefit. Otherwise I will continue to upgrade my current system to the current stable release every couple of months.

Libraries. They are a toss up. Since most everything I do does not end up in a shipped out product. I feel more free to upgrade often, but we tend to shy away from upgrading when backwards comparability is broken.

Hope my $0.02 was useful.

Answer 6

IDEs - This can be tricky but I have gone through a few different progressions over the years. Sometimes being on a project or a specific feature can trigger an upgrade. For example, someone implemented a feature using LINQ so what was an ASP.Net 2.0 project became a 3.5 project overnight. Other times, it is just what is currently in use. A point here is that a change can impact a whole team so it isn't a change to be made lightly.

Bug tracking tools - This is also in that land of centralized stuff that has to be carefully managed. Since this is a QA tool, I'd hope they have their own policies of how often to look for updates and when to install them as sometimes new features can be cool to get. The dev team equivalent would be when to update the wiki.

Version control - These are individually managed since most of us use Tortoise SVN so we each have a local client copy. So, the updates are done when someone wants to do it. I like to stay up to date as much as possible, personally.

OS - While part of this can be controlled on a department basis, there are enough different pieces to update that sometimes I'll run an update on my own. I'm not sure when we'll move to Windows 7 as I know we aren't going to Vista and I'd think at some point we'd get off XP as I've been on XP now for about 5 years as before that I was on Windows 2000 Professional for a few years and NT 4.0 before that.

PC - There is a policy that every 3 years we get new machines I believe. When I started where I am now, I was on a P4 box, so the upgrade to a dual-core box was very nice as well as a good RAM boost from 2 GB to 4 GB.