A couple of years ago, I began focusing on construction and deployment complexities. I had just joined a new team and began looking for the commonalities between their architectures and environments. Needless to say, they were all different. The most disturbing issue was the amount of effort required for a new developer to start working with an application. If there was any project documentation, it was probably out of date; resulting in hours or even days of trial and error to actually build and deploy the system. In this post, I’m talking about is building and deploying J2EE applications. The following list represents the top developer unfriendly practices I have observed.
| Developer Unfriendly Practices |
|
Without first running a setup task in After experiencing these challenges, I began a quest of environmental simplification. I understand there are numerous reasons why projects end up with these unfriendly characteristics, but leaving them unaddressed was just not in my character! I made it my personal mission to ensure that each project that I worked on, I would try to leave it in a little better shape than when I arrived. This is a never ending activity; I hope that those that come after me will have a similar philosophy and continue my quest. It is amazing how easy and fast an application can atrophy, eliminating all of the positive changes that had been previously applied. To keep things simple, I came up with following three project requirements. I try to weave some aspect of them into the development process and architecture of each project that I work on.
| Project Principles |
|
I hope that most of these principles seem like common sense and are nothing new. Much like many of the XP principals, they are not new or revolutionary, just good reminders of often overlooked practices. I will try to elaborate on each principal in a future post, hopefully, in the near future!
July 19th, 2010 11:36 am
Isn’t it a good practise to setup a project build without ANY dependecy to an IDE? Why do you leverage on Eclipse as “must have”?
July 19th, 2010 12:09 pm
I agree with Joachim, I actively discourage checking in any Eclipse files so that developers can configure their workspaces as they wish. I know lots of people hate Maven but one of the plus sides, you can just import Maven projects into eclipse using m2eclipse and it sets every up for you in your workspace. The trouble with checking in Eclipse files people get lazy and change dependencies in the IDE but do not update the external build scripts which then break.
July 19th, 2010 2:57 pm
[…] This post was mentioned on Twitter by Simon Brown, Michael Hüttermann. Michael Hüttermann said: I only partly agree with items 2. and 3. @simonbrown: A nice post on overlooked development practices by @philbeiler.. http://bit.ly/auR7wz […]
July 20th, 2010 8:11 am
[…] write about. However, because I received a couple of interesting comments on a recent blog entry, Unfriendly Developer Practices, I thought I should clarify my […]
July 21st, 2010 1:31 pm
I agree with Joachim and Paul. Eclipse project files should not be shared via source control, but rather generated ; if you use Maven as build tool, you can use the Maven Eclipse plugin which can generate Eclipse project files based on your POM files. This avoids the need for constant synchronization between your project files and the POM files and also makes sure that no local paths or dependencies creep into your project configuration.
My 2 cents.