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?