Thinking about a developer setup template

Development on one of my projects has gone in fits and starts. It’s been particularly challenging because the information about server configuration has been incomplete and scattered, trickling in as the IT architects sort out what’s going on and find people who can answer questions. The other developer and I are both new to this software stack (Websphere Portal, Websphere Application Server, FileNet, Enterprise Content Manager, DB2, Rational Software Architect). This means that we run into all the things that experienced developers take for granted: where to find documentation at the right level of detail, which ports and URLs to use (or even how to go about finding them), how to deploy our code, and how to diagnose and troubleshoot problems.

Stoic philosophy to the rescue. It’s no use whinging about not having all the bits and pieces up front. =) Besides, the people who set up the virtual images are people too, doing the best job they can while probably being pulled in a million directions or afflicted with the curse of expertise, forgetting the kind of knowledge they take for granted. It’s okay. It is what it is.

We’ve managed to figure most of the pieces out with a lot of poking around and experimentation. I’ve successfully deployed a web service, found sample code that can post a file to our Filenet object store, and written a web service client. We’ve previously been able to connect to DB2, so we should have all the major pieces now. The next step is to wire it all up with application-specific code.

I’m thinking of organizing all the bits and pieces of information we needed into a template that I can share with server administrators and developers next time we’re on a project like this. It would make work a lot faster and easier.

So, what do developers need? We typically need to:

Set up our development environment
software, licensing, config, source code control information, bugtracking, etc.
Orient ourselves on different environments
login/access/VPN details for integration, testing, and production environments; deployment procedure
Confirm that the service is running correctly
the full URL to the web-based administration console and to other web interfaces we can use, any hosts entries needed (for name-based virtual hosts, for example)
Log on the server and look around
VPN details, boundary firewalls, IP addresses, usernames, passwords, connection software (Remote Desktop? VNC?), file paths, location of log files
Write code
API documentation, software versions, ports, paths, usernames, passwords
Deploy and run code
file paths or upload interface, instructions on starting or restarting services
Test that things are working
web interfaces, ports, URLs, etc.

This could be a lot of information, and it might not be worth doing if you’ve got a couple of developers who can pick things up quickly. On the other hand, if you’re preparing a demo image that could be used dozens or hundreds of times for development, or if you gradually build this document over time, that could be pretty handy.

What’s in your developer setup template?

Photo (c) 2009 Mecookie – Creative Commons Attribution License

2011-03-15 Tue 20:03

One Pingback/Trackback

  • Here’s what I did on my project.

    #1 set up a version control system ASAP
    #2 version control the IDE, tools, etc so developers can pull from it
    #3 Assuming you’re Eclipse based
    – set up project configurations. ESPECIALLY formatting standards, sorting of members, code clean up etc. This will prevent DIFF headaches later.
    – set up checkclipse and set your team coding standards, no sense in giving yourself a headache because of missing documentation and stupid errors
    – set up FindBugs and PMD for more code checking and finding stupid errors. (And I mean it finds stupid errors, I thought they were useless until I tried it on other people’s code).
    – set up EclEmma to provide coverage analysis on the JUnits.
    #4 set up a batch file to set up the command line environment
    #5 set up a batch file to run the IDE

    You can use my developer guide in the internal wikis, ping me in case I forget.

    Anyway the advantage of doing all that is
    a) developer setup time from zero to working is less than a day (depending on the network)
    b) no excuses on different configuration since it is in version control

    And if you have the IDE set up as I have specified, this will help manage expectations from your development team.
    * your development team cannot hide the fact that they didn’t the work because the tool alerts them AND you.
    * a developer can do 3 things
    — be good to avoid the problems before getting to you
    — do the minimum to get the warnings to go bye bye (which is still good for you because you don’t have to deal with stupid errors). They may even ask you for advice on how to get rid of it themselves so they are learning as well.
    — leave them alone and provide you with the necessary evidence whether to keep or let him or her go.

    Anyway at present I haven’t done the enforcement (which I regret not doing, but then I don’t know about some of the tools I have told you about and Eclipse didn’t have project level configuration at the time).

    However, the above would’ve been my 3rd time setting up a development environment.

    First iteration was step by step on how to install the environment with all the IDEs

    Second iteration was to do step by step on how to install and connect to version control and do the initial checkout.

    Third development guide would still be the same only with more notices to the developer not to make any stupid mistakes that a tool can catch AND tell you or feel the team lead’s wrath :) in a nicer more professional way.

  • Thanks!!! I have been poking around the API for a large software product for 2.5 months and finally know the product well enough to be able to customize it for my purposes. Also discovered that version control, rapid prototyping and daily logging of different approaches to fix a problem very useful.

    I have worked in a large company where I got bug-tracking, version-control and product-management (determining the direction of the product) for free, but now that I’m working on my own (school) project, I’m trying to find the right balance between scaling down the infrastructure for the purposes of a 1-person project that is not build for mass-production and making sure high productivity software development. I’ll definitely be referring to this post for any future 1-person or team projects.

  • Although I work in a large company sometimes the tools they provide tend to be very heavy especially for a small group of developers (sometimes just myself).

    If you are technically inclined, I suggest you use git (if your not so, then BZR). Distributed VCS are by nature very fast for simple operations such as branch, merge, commits, adds at the expense of more drive utilization (since you keep the entire history).

    For bug tracking, a simple todo list like todo.txt does just job and easily shared with other people in your team. You can put it in dropbox so you can collaborate with your friends more easily. Or even org-mode for more complex stuff (though I haven’t used that myself)

    If you’re using git, you can use gollum as a wiki engine which reads your git repository to create a wiki site. You could also use TiddlyWiki as well for a simple wiki engine to share your thoughts and ideas.

  • @Archimedes, thanks! I am using Github right now. Gollum and TiddlyWiki sounds great, will definitely look into those.

  • Yup, I use github myself especially for my opensource stuff.

  • Pingback: Decision review: calendars, development, standing desks, toe shoes, Kindle, bike, CSA, Autodesk Sketchbook, blogging | sacha chua :: living an awesome life()