Curt Sampson wrote:
> On Wed, 26 Sep 2007, M. Edward (Ed) Borasky wrote:
> 
>> I personally think that it is almost always a mistake to do "a vast
>> amount of programming ... not to make products which are sold to others
>> but for internal consumption".  Programmers should be paid to produce
>> software that fills profitable markets, not to do infrastructure
>> projects that could be done using off-the-shelf software.
> 
> This sounds like an opinion held firmly enough that it's unswayable, but
> just in case you care to contemplate it, I'll tell you why I disagree.
> 
> In my world, at least, programming is cheap. Solving problems can be
> expensive and difficult, but the coding aspect of that is generally
> fairly trivial. In fact, due to the flexability you have when writing
> custom software, it can be easier than trying to configure a commerical
> package.

Well ... that I think depends on the task to be accomplished. But in 
general, if at all possible you should buy (or acquire open source) 
infrastructure rather than build it. Here's what I recommend:

1. Collect your requirements.
2. See what you can buy (or acquire) that best meets them.
3. If there are fewer than three viable sources, go back to your 
stakeholders and start axing requirements. Remember, you're trying to 
minimize costs and free up programmers to produce software you can sell.

OK ... now assume you've got the requirements negotiated down to the 
point where there are three or more viable sources. If there are more 
than three, throw out all but the three most expensive. Why? Because 
they are either incompetent or competent and attempting to buy the 
business. In either case, you don't want to deal with them.

Now you're ready to go out for bids. Make *damn* sure all three can meet 
your requirements, and that they aren't written to favor one of the 
sources. If your requirements don't pass this test, again, go back to 
your stakeholders and negotiate until you get what you need -- a set of 
requirements that three competent sources can meet.

All I'm saying, when you really think about it, is that you need to 
apply the YAGNI principle to infrastructure ruthlessly. You Ain't Gonna 
Need It, and putting a real price tag on it by forcing yourself to buy 
it and justify buying it forces you to think about it, rather than just 
saying, "hey, for only ten lines of Ruby code I can ..."

> Another way of looking at it is that all that time you spend tweaking
> XML configuration files is just another form of programming anyway. Why
> not just do it in Ruby (or whatever) instead, if that's easier?

If you did your procurement right, *you* shouldn't have to do a lot of 
configuration or customization or any other kind of programming 
disguised as system administration. You bought infrastructure -- the 
vendor should teach you how to use it and fix it when it's broken. You 
shouldn't have to do things with it that it wasn't meant to do, write 
scripts or edit XML files to work around defects, interface it to 
someone else's pet database, etc.

If you *have* to build infrastructure, by all means, do it in a 
pragmatic, agile manner with Ruby or similar tools. But don't do it just 
because it's *fun* or because you think you're saving money, because you 
aren't saving money -- you're spending it.