Software_architecture

I was happy to note that Dion Almaer commented on my blog post on Merb. Dion is one of my favorite bloggers/podcasters and I value what he writes highly.

But I disagree with him on this one. The problem with using Java for web application development was never one of too much choice. In fact, it was because of that choice that Java became a player in the server side market at all. Sun alone never had the answer to what was needed for server side development, instead the open source world stepped in and made incremental corrections.

Some time ago, there was a lengthy debate on the Agile Sweden mailing list regarding the term “Architect”, and what it means. My position is that the term has become synonymous with the paper or PowerPoint architect, and I therefore try to stay clear of it. Other people haad other opinions.

Neal Ford has changed his title, and describes why in a brilliant way:

Neal Ford: From Architect to Wrangler: […] “The title of ‘Architect’ for software developers has gotten so diluted that its meaningless anymore. In fact, its almost pejorative because so many ‘paper’ architects give it a bad name. I’ve gotten ‘Oh, dude, I’m so sorry’ looks from people when I tell them I’m an architect, assuming that I’ve had a head injury or something and can’t do real development work anymore.

For a long time, I’ve wanted to make the switch and start using online apps, but there has always been reasons that have kept me back. It seems that Dion and I share the same opinion on this one, and he sums up the problem very well.

Almost all large companies I have come across have some standards regarding the technology stack that they are using.

The main reason behind this is economy, that developers should be able to rotate between projects and that operations should only have to worry about a limited number of software products. Something like that anyway

However nice this seems, it never delivers on its promise. It is much like the Gantt charts - looks nice, promises a lot, delivers zilch. Not counting the enormous upgrade cost when the whole stack is upgraded after 20 years - COBOL anyone?

I am reading Cal Henderson’s Building Scalable Web Sites. It covers a lot of topics, some of which I am closely familiar with such as version control.

Cal does however have suggestions for situations I have never been in, in particular I do love this quote from the part on how to handle hardware platform growth: “When you get to the point of having a few thousand servers […]”. Never been there.

Martin Fowler writes: “If you only try to provide the minimum, you end up with multiple clients duplicating code for common cases.”

Or one billion jakarta.commons packages

(Via Martin Fowler’s Bliki.)

At work, the task at hand is extending an existing J2EE based product. This means that half of the .war that is to be deployed is hands-off, and the other half is written by us.

The problem I am having is how to get a productive environment. Unfortunately the products file organization is a mess, so there is no way to have a version checked into the version control system as it never would survive an upgrade. Also the deployed app needs to be initialized with a lot of data that is - surprise - saved both in a database and on the filesystem, meaning no easy test db setup.