Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 9 down vote favorite
2

I have a "pipeline" sort of process that is essentially just linking together a bunch of existing tools to automate a workflow. For one of the steps, there is an existing command-line tool that already does the meat of what that step needs to do.

The external CLI tool is java-based, and so is my pipeline, so it would be possible to integrate the tool directly into the pipeline step, but the tool is very complex and is currently closely tied to having command-line input (something like 37 config flag options).

The question is: Is it a better idea to simply call out and invoke the external process, or would it be better to integrate the external code within my application?

What are the pros / cons of integrating vs. calling the external process?

share|improve this question
Is the command-line tool something you control, or is that developed by another party? – whatsisname Feb 1 '12 at 15:41
It's the open source (Mozilla license) dcm4che DICOM toolkit, so it's been developed by another party, but I can do with it pretty much whatever I wish. – cdeszaq Feb 1 '12 at 15:47

4 Answers

up vote 11 down vote

Is it a better idea to simply call out and invoke the external process, or would it be better to integrate the external code within my application?

It is much better to integrate these things.

The command-line interface is just an interface, and a particularly awful one. It's essential but it's also filled with quirks and limitations that aren't sensible.

Each of the "existing tools to automate a workflow" should have a tidy class that does the real work after the command-line options have been parsed.

Ideally, the public static void main function does two things in each one of those "existing tools".

  1. It invokes some command-line option/argument parser.

  2. It invokes the tidy class that does the real work. Think of an Ant task or a Maven task that does the real work after Ant or Maven has handled all of the parsing and decision-making.

When you go to integrate these things, you want the tidy classes that do the real work.

If they don't exist, then you'll have to rewrite all of those tools to create the tidy class that does the real work, separate from all command-line parsing.

For guidance on how these tidy classes should work, read Ant (or Maven) to see how they define the various worker tasks. It's a good mental model for how multiple, disparate things are integrated without going back to the command line.

share|improve this answer
In my case, the class doing the work is the entire tool, and contains the main method, the CLI-parse methods, etc. It's rather nasty :( – cdeszaq Feb 1 '12 at 15:50
@cdeszaq: In that case, it needs to be fixed. It's not a terribly difficult rewrite, and it must be done. – S.Lott Feb 1 '12 at 15:56
2  
I'd add that depending on your deadlines, you could integrate with the existing CL interface and port over to a properly integrated solution over time. But if you do have time to fix this now, then do so :-) – Martijn Verburg Feb 1 '12 at 16:03
1  
@MartijnVerburg: Good Point. Often, there's a clear priority. Some of the workflow is more tightly integrated or could potentially have a separate use as a "sub-workflow". This may lead to a backlog of rework from most valuable to least valuable. – S.Lott Feb 1 '12 at 16:27
At my last employer we had a problem executing a utility exe (we but not my code at all). Helping the "senior" developer diagnose why this exe wouldn't execute I suggested writing a bat file to kick it off. It worked. He stopped looking for the problem and thats how it went out the door. Lesson I learned is 1. Never propose a bad idea to troubleshoot a problem to someone that makes decisions. 2. Use libraries or internalize your own logic as much as possible. That "fix" cost a host of tech support on some machines. He also didn't believe in testing or source control so no surprise... – Rig Feb 1 '12 at 18:09
up vote 6 down vote

I would say leave it alone if it works.

As a programmer you bring value to your organization by solving problems with software. Solving more problems in both quality and quantity within a given amount of time is directly related to your value in the organization. Spending this time to create code diminishes your value since it takes you away from solving a more important problem.

However, a couple of factors that might mitigate spending the time would be scalability and if there were any concerns for the external programs stability.

share|improve this answer
I agree. You can open yourself up to a lot of trouble trying to integrate 3rd party programs/code into your app. Sometimes it is necessary but, as the saying goes, "If it ain't broke, don't fix it" – jfrankcarr Feb 1 '12 at 16:21
5  
Solving problems is great. Solving some problems while opening the door to other problems is not so great. – yfeldblum Feb 2 '12 at 1:42
up vote 5 down vote

It isn't "better" or "worse". There are simply different costs and benefits.

It is often more expensive to write and maintain a piece of software the larger the number of integration points do to the added complexity.

  • A function you write has very little integration cost.
  • A third party library has slightly larger integration cost.
  • A separate program you have to exec will have and even larger integration cost.

Note these are integration costs which you have to weigh against total cost which includes among other things the cost for writing and maintaining software.

It may be the case that you are a very inexperienced programmer, but a long time power user.

  • If you were to "shell out" your total cost may be low despite the higher integration cost, because you can mitigate the integration cost with your experience and knowledge.
  • If you were to write the function yourself your total cost may be quite high despite the low integration cost because of your inexperience programming.

The best way to figure out:

Is it better idea to call an external command-line application or to internalize that application's logic?

Is to calculate the costs for yourself. The cost will be different for different environments, situations and people. Most of the time it will cost more to call out to the command line, but not always and the only way to be sure it to do the analysis.

share|improve this answer
In my case, it is essentially a external application that happens to be open-source and written in Java, just like my application. Unfortunately, there isn't simply a library the external application uses, since that library is bundled tightly into the CLI interface itself. Other than that, all good points. – cdeszaq Feb 2 '12 at 13:21
up vote 1 down vote

Ideally you'd want to integrate it. Especially if this is an app that gets distributed - reducing the number of dependencies and configurations will make that easier. But its of course a cost/benefit issue for your specific case.

That said, one thing to consider is stability. I encountered something similar a couple of years ago and kept the cli program in place. It was too unstable, and I didnt want its crashing to take down the parent application, which needed to run 24/7. Now this wasnt a java app, but none the less, if its an issue that may apply you may want to keep that in consideration.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.