ContentI just wasted the second of two weekend days spending more time setting up development tools and programming environments than I did accomplishing what I set out to do in the first place.
Specifically, I once again wrestled Eclipse and WTP and Maven and Junit and Subclipse and Hibernate and Spring [and, and, and...] into partial submission.
But really, why do I do this to myself every time I want to write some simple little code?
I get this clear picture in my head of exactly what I want to write. Then I promptly go off on a 12 hour long tangent figuring out how to integrate an enterprise-quality build system and deployment system for my inconsequential one-person project.
The worst irony being that I just went through this exact process 3 months ago (just before my headfirst dive into Python). But, even in that brief period of time, everything I had set up before was already woefully out of date.
Which is precisely the problem. Hot new tools such as Maven, Eclipse, etc., etc., are perpetually focused on going from version n to version n+1. No one cares to stay behind to make sure version n is actually working well and inter-operating correctly with all of the other parts of the ecosystem. By the time you get one thing working you are already one upgrade cycle behind the other pieces you depend on.
So, is this problem endemic to all open source projects? Does the same thing that drives us to write open source code also drive us to go forward at all costs?
My gut says “no”; there are too many counter-examples. Older versions of the Linux kernel, Apache httpd, gcc, etc., are stable, rock-solid, and always getting more refined, not just adding more features. Stalwarts in the venerable old toolkit like emacs, make, autoconf, etc., are still being patched and updated. Sure, sometimes we move on to new tools, and sure, sometimes you’ll see new versions of those development classics appear, but the maintainers never abandon the old versions entirely.
What makes me frustrated is that so many projects today are pushing the “Latest and Greatest” version on their homepages, and abandoning everything else, seemingly the moment the unit tests turn green. No one seems to care that tools don’t work in isolation, that they are designed to interact with other tools. Heck, everyone seems to be able to add “plugin” support for their projects. But what good does it do if every four weeks you release a new version that is incompatible with your own plugins?
So forget it. I’m scrapping the cutting-edge development stack next time around and writing something in C89. At least I’ll know what I’m getting myself into.
(Written and posted using Google Docs & Spreadsheets. Boring name, great product.)
Twitter:
@sogrady Thanks for the introduction. Nice to meet you, @bcantrill. I'm a fan of your work, and subscribe to your blog.
Posted about 31 days ago
December 9th, 2006 by DeWitt Clinton
December 10th, 2006 at 7:52 am
DeWitt,
You decided to do it in Java. ’nuff said. By the time you got it up and running you could have gem install rails, and finished the little project ;)
The only problem would be that it would take you another weekend to DEPLOY the damn thing.
I hope you upgraded to m2 as part of this.
Cheers,
Dion
December 10th, 2006 at 7:59 am
Dion,
I hear that about Ruby on Rails.
That said, the Python/Django path was equally short. Django is where I focused my attention originally. No matter what I do with the Atom Store backend, the front-end for this project will still be Django based.
If by m2 you mean Maven 2, then yes, I made the switch a while back. I still believe in the project — perhaps more because of the formal recommendations on Java source directory layout than anything else. But Maven 2 doesn’t really play well with others yet and that is a big part of the frustration.
December 11th, 2006 at 4:16 pm
[...] DeWitt Clinton recently wrote about the predicament I go through every so often. As I am starting on a new work project (one that I havent encountered before), I think of setting up an “enterprise” quality environment to design develop build test and deploy. I spend roughly 1.2 times more than the actual design/build etc. of the project. The key justification I give to myself for spending that extra time is to make sure whatever I am doing is duplicatable the next time around. Given my role as an architect that next time comes seldom or frequently (when I least expect it)…So here is a conundrum. Since I dont know if I am going to write JSR168 portlets with JSF, next time around, do I need to spend a weekend setting up Eclipse (or lately Emacs), Ant, Maven, Tomcat, XDoclet etc. so after I am done with this project, I can reuse this another time- whenever that happens? The question I always asked was WHY. Why do I go thru’ this pain? Other than the masochistic kicks, I cant think of a reason, giveb my style of work [read “doesnt code for living”]…But I do know that by going through my primitive work environments, it was upto my standards and what I needed, unbloated, even if its only a half day programming project. [...]
December 12th, 2006 at 8:06 am
We gave up on Java for exactly these reasons: students had to spend so much time getting environments set up, and tools to talk to one another, that there was no time left for actual development. Unfortunately, Ruby on Rails and TurboGears have proved no easier, except when you want a completely vanilla (i.e., good-for-nothing-extraordinary) setup.
December 18th, 2006 at 10:03 am
I second that thumbs up for Ruby on Rails. You should seriously check it out. We did a thorough investigation of Java, and the attitudes of more experienced people to it, and despite really wanting to use it, it made no sense as the effort required to get it to work far outweighed any benefit over rival languages. We now use PHP, and have not regretted the decision.