From: Chad Perrin Date: 2007-10-15T02:25:15+09:00 Subject: Re: I love Ruby but what is the deal with... this ! On Sun, Oct 14, 2007 at 07:16:50PM +0900, M. Edward (Ed) Borasky wrote: > 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: I tend to agree that it's better to reuse than to recreate. Beyond that, however, I start running into some disagreements with you. > > 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. Axing requirements should happen earlier than that -- not because you should be trying to maximize the field of existing software that fills your needs, but because too many requirements are a sign of poor focus. Whether or not you can find more than three off-the-shelf software packages that suit your requirements list has basically nothing to do with that. You can have very specific, well-defined requirements and not find a single off-the-shelf solution that'll work, and you can similarly have scattered, unfocused, poorly considered requirements for which there are thousands of options. Most often, however, what you end up with in cases of scattered, unfocused, poorly considered requirements is a VP who insists that something like MS Exchange is the *only* solution that can possibly work for your "needs". > > 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. You've just thrown out open source software again -- and you've limited the choices to the industry dominating options, which may or may not be worth a damn. This sounds surprisingly like an "enterprise resource management software acquisition" process, which tends to end up with a company investing $120,000 in a piece of software that's going to cost another $40,000 to get installed and configured, and still may not work properly. Maybe I'm exaggerating a little, for the average case, but I think that's only because the average case gets a little more lucky than that. . . . and that's the problem: the success of this scheme seems to be significantly predicated upon an assumption of luck. > > 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. At this point, it's starting to sound more like "Plan your acquisition based on what looks good to middle-management, then play damage control to try to limit the amount of obscene costs such a middle-management conceived plan of acquisition tends to engender." I think there are better ways -- and they start with bringing more focus to your requirements in the first place, nailing it down to what you absolutely cannot give up with a short list of wanna-haves, then just checking to see what fits that (regardless of how many of them there are in the market or how much they cost). > > 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 ..." I agree somewhat, in that you should write the software yourself only if something premade either: 1. doesn't exist to suit your needs, or 2. costs far, far more than the resources involved in writing it yourself. Of course, that also assumes you have the discipline in your organization to avoid going nuts on feature-adding while writing it yourself. Then again, we're assuming your organization has the discipline to cut down requirements rather than going with the mediocre "feature rich" "industry standard solution" just because it "does everything" -- failing to think about whether or not it'll do it well or consistently (or for a reasonable price). > > >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. You've pretty much limited your field of vendors to IBM, at this point. Hopefully they have something that suits your needs. Yes, I'm overstating the case a bit -- but it's to make a point. Editing XML files in ERP and similar software markets isn't about working around defects, unless you consider that entire software market to be defective (which is certainly a valid viewpoint in many cases); it's just how the software is configured for your needs. If you consider the entire market to be defective, however, you've just come back to the "roll your own solution" answer to the problem. It's probably worth keeping in mind that in certain niches of off-the-shelf software markets, *nothing* that you can find to buy is likely to be worth the time spent evaluating it, let alone the incredible price tag it carries. > > 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. With that statement, it seems like we're in agreement again. Funny how that happens. I think a big part of the problem in our points of disagreement here is that you seem to view software as a product, and I see it as process. Software is basically just a process specification, and the computer is the part of the organization that executes that process. The point is to streamline operations and make certain tasks more efficient so that they consume fewer resources -- perhaps making completion of those tasks affordable at all, thus providing your organization with the ability to accomplish more. That's what all process is: a means of making operations "better". A product is something you slot into process because your process demands it, like providing chairs for your employees to use when they're working in their cubicles. Confusing products with process is, I think, one of the biggest problems the software industry has right now. -- CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ] They always say that when life gives you lemons you should make lemonade. I always wonder -- isn't the lemonade going to suck if life doesn't give you any sugar?