For “suits”, Excel is the gaffer tape of the business world. For a long time Apache Ant was the gaffer tape of the Java development world. It was great and I actually looked forward to writing yet another build.xml file. I did switch to maven for a while, but my heart wasn’t in it. Since switching to Google App Engine and Amazon Web Services, I’ve found that I haven’t touched a build.xml file for years (CruiseControl not withstanding). When you don’t need the gaffer tape anymore, it means that someone has fixed the problem.
I’m not having a go at Ant, but we should be happy that it has less of a place to play in the world of GAE and AWS Elastic Beanstalk. The Eclipse plugins from both Google and Amazon are something to be admired. I don’t know what sort of tools our Python cousins get, but I can only assume they get equal treatment.
I’ve been using Eclipse for more years than I care to admit to. I’m a fan and grateful to the Eclipse team and contributors for all the time they’ve put in so that I can save vast quantities of my time. That was the point of the Ant reference, by the way. It is always useful to remember where you were, so that you can appreciate where you are.
The last large scale enterprise application I led was a real pain to deploy. We had scripts all over the place, but be assured this was out of necessity rather than bad design. We had a strict deployment process due to the sensitivity of the data we were handling. This meant a deployment took around an hour to complete.
Compare that with the brave new world of PAAS and you begin to appreciate the improvements we’ve seen over the past 4 years. I’m sure we all smirk when we hear someone refer to the “cloud”, but to the development community PAAS has a real and substantive benefit. In future I won’t lose a team day per release on the deployment. I know I said it was only an hour, but that was for the deployment itself. Add in the pre-checks, post-checks, and the obligatory team building lunch and you’ve lost a day. Those slick features in the plugin that, for the most part, we take for granted are of real use and deliver an economic return. From the automatic update of the platform libraries, to the one click deployment and rollback, these all contribute to our effectiveness as developers.
I understand that if you are a lone developer then the cost of these services may be prohibitive, but even for a small development team, the cost of time saved can more than make up for the additional “hosting” costs. I say hosting because that is the general comparison used. What we must remember, is that we are paying for utility. Any saving we make should be shared with the provider of that service. If I had run my last large scale project on GAE (for example) I would have saved around 1 team day a month which is a large chunk of change. Thinking about it now, we could have had a bigger, longer lunch.
i feel as though you are making a conservative estimate on productivity gain.. so many more tangibles+intangibles you can factor in, not which of least, all of the sysadmin overhead..
Gregory, I agree. For example on the project I refer to in the blog, the savings in security management and disaster recovery would swamp any additional cost of running on GAE. You’ve planted the seed of posting a more considered assessment. As someone who has run development teams and had an eye on the commercial side, my assessment would differ considerably from some of the commentary I’ve seen elsewhere on Google’s pricing model. I’m not saying that GAE is perfect or that Google could have done more to engage the open source and lone developer market but I’ve yet to see a fair and balanced report. Having said that, I haven’t read the whole of the internet, so it may be out there somewhere.
P.S Aren’t you blogging? If so where about.