After reading Ruby on Rails: Opportunity in a Financial Downturn, I’ve got some notes and observations.
The article and comments cover both ends of the spectrum of the argument. Does the fact that someone is developing with a particular platform matter? Is it irrelevant?
I read a lot of developer and Rails blogs and there’s a few things that always blow my mind about the short sighted-ness of the views of those blogging rails and contract work. Here’s a list of things to keep in mind when looking for propositions for work and thinking about projects in general, and especially in an economic downturn:
1.) Screw the CIO. IT departments are the last place to look for something interesting going on in a company. In most companies, IT/IS came out as a function of the accounting department. My wife is an accountant, and I tell ya, there is nothing more boring than accounting, and what could be more boring than the accidental child of an accounting department?
The real problem here is that yes, when budget cuts come around, IT/IS departments are going to have extra projects slashed. That’s why you don’t target them. You don’t have anything to sell them anyway. If budget cuts are on the way to departments, why not come up with a time cutting app to help out? It’s all about ROI and your mindset. Developers aren’t paid to write software, they’re paid to solve problems. Rails developers aren’t paid to solve problems, they’re paid to provide intelligent, well designed, well documented, business solutions that just happen to rely on a software framework that fits those mindsets.
2.) Rails and a SCM framework give you everything you need to be a rock star now, for support, and for future projects. How many times have you inherited some awful collection of perl scripts, horrible monolithic PHP app, or worse… god forbid… some sort of hydra of a monster meant for mod_cgi?
MVC + a good SCM is just the start though. Using them well is key. Moderately skilled staff should be able to read through your commit messages and understand exactly how the changes made in the base framework equal your app. No one really needs to learn Rails or Ruby via your commits, but be transparent about your processes, make sure they’re understood. It makes people feel more confident in the knowledge of the business processes, every aspect of your deployment and support is made easier, you learn something, they learn something, everyone wins.
3.) SaaS is a bogus model now. So many questions arise when someone puts their data in a cloud. You can give every assurance known to man, your platform could be 100x more secure than theirs, but it doesn’t work. It’s like being 10 and given a savings bond backed in Zimbabwe dollars for Christmas — there’s no real deliverable and there’s no guarantee that it’ll be worth jack down the road (especially without investing more). The only guarantee is that the recipient of the Zimbabwean savings bond will really hate you.
In addition SaaS scales poorly for their pocketbooks and as bad for you (if you weren’t forward thinking enough to charge exponentially for scaling). Yes, maintenance charges are included in budgets, so give someone something. Have a deliverable, even if it’s a burned DVD. Make sure you followed guideline #2 and it’s well documented. Giving someone something tangible for their money is a really good thing. If I gave you the option of paying $10 for a CD or $10 to stream the same files from a site, what would you decide?
Just some thoughts. Remember who your best customers are, and what they need, not what Web 2.0 promises.
