FollowSteph Follow Steph as he posts Blog Blazer Friday

How To Quickly Setup a Software Development Environment

Setup New Developer Computer Environment

At one time or another all software developers have joined a project or team where the development was already underway. The most common introduction for a new developer to these projects is to setup their development environment. If you’re extremely lucky, a lot of this work is already done within the corporate disk image, but more often than not it’s up to you. This is especially true if you’re a contractor.

For a typical Java project, the story goes something like this. Download and install a specific JDK (Java Development Kit). Download and install a particular IDE like Eclipse. Download and install a specific web server. By the way, depending on the company, some of these versions may no longer be available which means you have to track down someone who still has an available copy somewhere. But assuming they’re all the latest versions, that’s just the start.

Once that’s done, you have the core applications to setup. Then you get to start downloading and installing the support applications. If you’re using Eclipse, maybe it’s the SVN (Subversion) subclipse plugin or the TortoiseSVN client. A good text editor such as UltraEdit. FireFox. The list goes on for about a dozen or so applications.

After that you probably need to configure your system settings. Most likely you then have to set up some development environment variables or configurations (server.xml, eclipse.ini, etc.). Save some connection settings in Putty. Setup some network drive connections. And on it goes.

But the fun doesn’t stop there! At this point you’ve just got your environment setup, you haven’t downloaded the project’s source code. Now you need to checkout the project from the source. Once that’s done you need to run the automated build system to get the project up and ready on your box, perhaps using Ant or Maven. If you’re lucky, and the company was in the upper technological echelon it ends there. Unfortunately most companies don’t completely automated their builds so you often still need to do some extra manual tweaking to get your project running. And on it continues.

Which means that all new developers lose anywhere from a few hours to several days setting up and configuring their development environments. Very expensive! And the longer your project goes (there will be some developer turnover with time) and the bigger your team gets, the more expensive it gets. Plus, with time this knowledge will disappear. People will forget steps, or why things are done in a certain way. Which means that at some point setting up a new project will be, well, for lack of better word, insanely difficult. You’ll have to track down specific people within the project because they’re the only ones left who know anything about certain parts of the system. If you’re really unlucky, the only way to get up and running might be to you copy the complete environment from one computer to the other. Yes complete copies of directories! It can become a mess.

The good news is that there’s a much much better alternative. One that will make everyone’s life much easier, and keep the knowledge over time. Can it really be? Yes, we don’t all have to suffer through this. And what’s even better is that I’ve implemented what I’m about to suggest with great success several times, and not just at LandlordMax but also at companies I’ve consulted for in the past.

Create a developer’s installer!

Why should your final product be the only system with a deployment strategy? Why not create one for your developer environment as well. Especially if your company doesn’t have a fully pre-prepared disk image ready with everything (which is virtually guaranteed).

How hard is this to do? It’s actually extremely simple, simpler than you might think. If you’re company already owns an installer like Install4J (which I’ve recommend in the past), then it’s a matter of an hour of someone’s time. And it shouldn’t just be kept on someone’s machine, it should be it’s own full project within your version control system. This way if any developer does any environment change, it’s up to them to update the developer installer project. This includes if an application needs to get updated (for example to the latest version of Eclipse, the latest version of FireFox, etc.). This isn’t just limited to new software updated, but also configuration changes, etc. No longer do you need to keep a record of configuration change emails, it’s all done for you in the developer installer!

Therefore when a new developer starts, all you have to do is get the latest executable build, copy it on a USB key (network drive, whatever), and let them run it. Better yet, you can do it the day before they come if they’re going to use in-house hardware. During this time you can walk them around and introduce them to the rest of the people they’ll be working with, explain them the project in more detail, or any other higher value action items you may have.

And don’t worry if your company hasn’t bought a great installer building tool like Install4J, you can also use the open source installer creation system called NSIS. Up until LandlordMax, I generally relied on NSIS to create Developer Installers since I could never guarantee what was available in the different development environments, but with LandlordMax we use Install4J. Both are great, the main difference is that with NSIS it will take you a lot longer and you’ll need to acquire a lot of specific NSIS knowledge (it’s a scripting language). So instead of an hour or so for Install4J, expect it to take a few days to a week or more with NSIS to build a good installer. But even if it takes a week, it’s worth it!!! The good news is that it doesn’t have to be production quality, just beta quality. In other words, you don’t have to include all the checks like in a production installer, you can assume that your users are pretty smart and will mostly enter in valid values (for example you can assume there’s enough disk space on the hard disk, that it exists, that’s writable, and so on).

The good news is that an NSIS installer script shouldn’t be more than a few dozen lines to a couple hundred lines (assuming you’re using functions and macros available on their website). So that’s not too bad overall. With Install4J it’s all GUI based, and the resulting script is stored in an xml file which can be called from any Ant build script! The cost to benefit ratio for one person to translate all the developer environment knowledge into an automated installer for everyone that will be available forever is unbeatable!!

A few quick tips:

  • Don’t re-create your main build file (Ant or Maven in Java), leverage what’s already there. In other words, you developer installer can call the main build file in your project to complete the environment setuo.
  • Use silent installers. Most applications have silent install options, so use them. The less interaction your developer installer requires the better.
  • Give the developer the option of selecting the initial install location.
  • As part of the install, leave all the individual installers within the main install directory (for example leave the FireFox setup executable somewhere in the install path so that it can be run separately later).
  • Give the option to select which “modules” to install. For example give the option to install FireFox, to install Eclipse, to configure the server.xml configuration file, etc. I’ve done this in the past by presenting a list of options (checkboxes) the user could select. By default all are selected with a toggle to unselect all of them near the bottom.
  • Assume advanced users are using your installer. In other words, you don’t need to spend too much time on checking for user errors. Let it fail miserably if there’s an error. It’s not worth the time.

As an added benefits, everyone has the same development environment initially by default. With time some developers will deviate from the standard development environment to what they like, but it’s good to start the same way. At least this way you have a default method to setup a developer environment which is a million times better than having a bunch of different developers setting up your environment in slightly different and unique ways. Plus if there’s an issue, it’s REPRODUCIBLE!

Like this article?


  •     Nancy
    · July 30th, 2008  · 7:04 am  · Permalink

    Ya your article gives us great knowledge about software development.Great post.

  •     jb
    · July 30th, 2008  · 7:59 am  · Permalink

    I can definitely relate.

    I’m starting to think that it should be taken a step further: Perhaps development is an operation that should take place within a VMWare image. So, on your first day, simply:

    * Retrieve the VMWare image.
    * Do an “update” on the code repository.
    * Build.

  •     Steph
    · July 30th, 2008  · 11:10 am  · Permalink

    Hi Jb,

    The only issue with VMWare images is that you lose a lot of performance. And performance is critical while developing. If you slow down a developer by 50%, you lose 50% of your value.

    And if by some odd chance it takes more than a few seconds to do something, you’ve lost their focus. Which means they now need to get back into the same mindset. So instead of a few seconds, or even a minute or two, the cost can quickly escalate to 10-15 minutes to get back into the same mindset!

    Which is why I always always recommend pushing developer hardware. Even if they don’t need it all the time, it’s so inexpensive compared to the developer’s time that you can’t go wrong. Plus it gives you the added benefit of showing you care about your developers.

  •     Scott Kane
    · July 31st, 2008  · 9:00 am  · Permalink

    OK, this has got to be one of those “why the heck aren’t I doing it this way?” articles. Good one Steph. When one uses a lot of components, dll’s etc as well it gets to be a pain after reinstallng an IDE and stepping through the source working out which ones you’ve forgotten to re-install (probably more of an issue for Windows dev’s). Which also suggest the possibility of backing up registry settings and plonking some of those in the installer too.

    Thanks Steph!

  •     Stephane Grenier
    · July 31st, 2008  · 3:56 pm  · Permalink

    Hi Scott,

    Thanks! And that’s exactly it. The bigger the team (and the longer lived the code base) the more expensive the cost.

    And you’re absolutely right about system configurations such as registry settings, etc. I thought I had included it, but after going over it again 2-3 times I can’t find any reference to this. Great catch!

    To add, as well as system settings (registries, environment variables, etc.), you can also add a bunch of utility scripts (batch files for Windows and shell scripts for Linux/Unix). Basically anything that’s the developers will need.

  •     Chris Wash
    · August 4th, 2008  · 6:33 pm  · Permalink

    I prefer the virutalized approach as well. We’ve found this invaluable for getting people up and running with any given large enterprise portal stack quickly. It’s an added benefit if you need to be able to develop on multiple projects simultaneously as well. That’ll pose an almost intractible issue with your approach where you have different stacks fighting over the same configuration settings. You’d probably have to uninstall and reinstall everything to switch between projects. If you have multiple clients, it’s the way to go.

    It definitely takes a little getting used to, but you’ll find it works out pretty well if you invest in an integration server to test things end-to-end and focus testing on your machine using unit testing techniques and automated methods. The virtualized development environments tend to be responsive enough, but you may notice booting an app server with a giant portal stack to test end to end can be a little sluggish. In that case, just do it in a real integration environment. Setting one up (that’s specific to you or a few people) isn’t a huge deal once you have an image, either and we’ve found it’s quite easy to throw hardware at that performance problem.

    Plus they’re way easy to back up and recover. Can’t say enough good stuff about them – you should really take a closer look IMO.

Write a reply:



LandlordMax Property Management Software

LandlordMax is the EASIEST
Property Management
Software available!
Try it for free!

Real Estate Pigeon

Real Estate Pigeon
The place to ask and answer
all your real estate questions

Blog Blazers: 40 Top Bloggers Share Their Secrets to Creating a High-Profile, High-Traffic, and High-Profit Blog!

Blog Blazers is a book that
features secrets from the
Top 40 Bloggers on the web

How to Generate Traffic to Your Website ebook

How to Generate Traffic to
Your Website
is an ebook for
to you achieve success


More resources from Stephane Grenier:
For people who work on the web
Blog Blazers
How to Generate Traffic to Your Website
The EASIEST Property Management Software available!

Copyright @2003-2024
LandlordMax Property Management Software

Disclaimer: This is a personal blog about my thoughts, experiences and ideas. The contents of this blog are for informational purposes only. No content should be construed as financial, business, personal, or any other type of advice. Commenters, advertisers and linked sites are entirely responsible for their own content and do not represent the views of myself. All decisions involve risks and results are not guaranteed. Always do your own research, due diligence, and consult your own professional advisors before making any decision. This blog (including myself) assumes no liability with regard to results based on use of information from this blog. If this blog contains any errors, misrepresentations, or omissions, please contact me or leave a comment to have the content corrected.