tags:

views:

258

answers:

8

My boss is a tight-wad when it comes to tech and he rarely approves projects that don't directly impact revenue. He (wrongly) ignores the cost side of the equation many times, especially for technology projects where it's tough to approximate costs. Does anyone here have any white papers, articles, etc. for a rational cost-benefit based argument for setting up a proper development environment (subversion, development, staging and production servers)?

Thanks!

+6  A: 

Wow, what are you using for source control right now? Anything at all? If not, then you should just do it, and set up a Subversion server. The great thing is you don't have to ask for approval because no money needs to change hands.

If you can't even do that without asking, then I'd suggest finding a more enlightened boss.

Greg Hewgill
We're using a basic SVN repo but all of the developers keep a local dev copy on their machines and then we push it into a branch on the SVN repo and then right into production. I feel like we really need to formalize the process and have a multi-step publishing process.
so its not how to justify using SVN, but how to get a full development process, build and release system. You should have said as much, it a whole different question.
gbjbaanb
+4  A: 

I'd say the cost of not using any kind of source control system would be reflected in the potential cost at losing a bunch of code or having to perform manual reconciliation of multiple concurrent versions of the same code, which equates to a direct, measurable cost in man hours.

Rob
A: 

I have to agree with Greg. Since Subversion, CC.net, TortoiseSVN, AnkhSVN are all for free you should be able to set up a nice CI system for change.

Kasper
A: 

I don't know of any good paper as you asked, but you can tell him that a lot of people here at SO (I speak for myself) thinks that your boss got it totally wrong and is short sighted. I second Greg's answer wholeheartedly.

Otávio Décio
+6  A: 

Martin Fowler had an article on the benefits of Continuous Integration. It will take some time to set up an automated build. On the last project I introduced CI into it took one developer a day to get things working then about a week to have everything fine-tuned. There are so many benefits that it is hard to list them all, but here are the ones that have helped us:

  • Encourages frequent integration - helps everyone stays on the same page
  • Automated tests - every time someone checks in makes sure that issues are dealt with early
  • Automatic deployment - one click and in minutes the latest version of our software is on all the servers

For me, the biggest change was the last. It turned an hour-long process that was prone to errors (Did you remember do update the remoting version number? Oh crap...) into a 5 minute process that we could rollback if something went wrong.

When I was learning to set up CI, this article by Carol Lotz was infinitely helpful. It walks through, step-by-step setting up a complicated project.

DavGarcia
+2  A: 

It's better to beg for forgiveness then to ask for permission.

Just setup the source control server, without asking first. If something bad happens as a result, just apologize and move on. When the source control setup proves to be useful, just say "oh yea, I setup a source control system" and everyone will be pleasantly surprised.

Scott Wisniewski
+1  A: 

In addition to Scott's comment of just doing it (paraphrased), if you start with a distributed system such as git or bazaar instead of Subversion, you can start with having it running locally without even impacting others, and then spread it amongst the other developers over-time.

Peter Boughton
A: 

Could you do a risk analysis? This is an accepted project management discipline and essentially involves enumerating the risks, making an attempt to quantify them in terms of likelihood and impact, and identifying possible mitigating measures. That approach should work for source control at least, unless your boss wilfully ignores the risks, which would be very... courageous of him. :-)

If a source code disaster does occur yuour boss bis going to look pretty stupid (and reckless) and you're going to look prescient. Peter's suggesiton is good as well - set it up for yourself and then, when someone loses some source code, or some changes, casually say "Oh, I did that recently but I just re-fetched the previous version from source control and only lost about 20 minutes' work. Do you want me to set you up with a login?")

gkrogers