• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Process, efficiency

 
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am seeking comment from others regarding an efficient way to manage component responsibility. The scenario is quite simple.

There exists some component, written in C/C++, that provides domain independent functionality i.e. many applications that have an unrelated domain, may use this functionality. It is an API that is used by many with totally unrelated agendas. For example, a database vendor may use it, or an application server vendor. In practice, there are indeed such clients all within, and working for the same large company who use this library, to provide their own specific application domains.

There also exists a Java component, also within the same company, that depends on this C/C++ API through a layer of JNI. The Java component includes many functions, many of which are exposed through a swing GUI. It has been agreed upon by management, tech. leads, etc., that there is a separation of roles - that some person(s) will be responsible for the C/C++ component, including the JNI layer and that some other person(s) will be responsible for the Java component (and of course, all the other components as well, such as application servers).

A problem now arises, for example the JVM causes a segmentation fault. This is considered a defect and must be remedied (regardless of unexpected inputs). What is known for sure, is that the person responsible for the Java component is not responsible for this defect. However, suppose the segmentation fault was exposed through the Java component - for example, by pressing a button on the swing GUI, the segmentation fault was exposed. In theory, the cause is either a defective VM, or defective after the point of calling a native method (into the JNI and then into the C/C++ API). In practice, it is almost always not the result of the VM, but the result of some native call. Therefore, it is reasonable to suggest that the person(s) responsible for the C/C++ API are responsible for the defect.

The management problem now arises such that the person(s) responsible for the C/C++ API have minimal to no understanding of Java, the platform, etc. They are not convinced by the notion that the Java platform cannot cause a segmentation fault. They do not understand the distinction between the Java platform, language (which cannot cause such a problem) and the VM - the platform implementation, which can cause such a problem. In any case, the person(s) who are responsible for the C/C++ API claim that responsibility lies entirely with the person(s) responsible for the Java component, since the defect was exposed through the Java component (by pressing the swing button or whatever). These person(s) claim that full responsibility to determine the cause of the issue lies solely with the person(s) who are responsible for the Java component, until those person(s) can prove that the problem left the VM and entered into the JNI layer - in such a case, input values are expected to be provided. The reason provided is that the customer exposed the issue through the Java component, which immediately excludes responsibility on the part of anyone else, until the person(s) who are responsible for the Java component prove themselves as having no responsibility. That there is a potential short-cut in determining reponsibility for the component is ignored - that it is almost certainly the JNI causing the segmentation fault, and in the event that it isn't, it is the VM that is the cause, it completely irrelevant to the process of resolving this issue.

I think this is an absurd approach, and incredibly inefficient. I think this approach causes the customer unnecessary pain as a result of the incompetence of the company, that it paid money to for a product. Not just that a problem was caused, but the general incompetence of the company's staff results in an inefficient method of resolving the issue - which is the key point at hand. The person(s) who are responsible for the Java component have proposed to the person(s) who are responsible for the C/C++ component that they are willing to attach a debugger to their VM under the same scenario, in order to observe the state of the VM when application execution left it and provide them with this information to assist in resolving the issue. This is considered by the person(s) who are responsible for the C/C++ component as a demonstration of lack of initiative, and that since full responsibility is not accepted, then those person(s) are not fulfilling their role in their job. The person(s) who are responsible for the C/C++ API have a higher level of authority within the company than the person(s) who are responsible for the Java component. Therefore, even though the person(s) responsible for the Java component are acting with the best interests of the company, they are often condemned by the authority, for the issues mentioned earlier (lacking initiative, etc.). I claim that these person(s) are acting in quite the opposite manner - by showing initiative in helping those who are truly responsible for the defect - for example, by attaching a debugger to their VM.

Although I have provided my point of view, I welcome conflicting points of view that perhaps point out what I may be missing. The most plausible explanation that I have is the one provided by literature by Karl Marx and even Dilbert - the illegitimate authority, that exists only because of its incompetence. Can anyone share any constructive thoughts? I hope to have provided an objective point of view on the scenario - except of course, for the previous paragraph.
 
Ranch Hand
Posts: 163
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Tony,

Tough problem, to be sure.

I'm surprised that the many clients of the C++ object haven't exposed the source of the segmentation fault. If that is indeed the source of the problem, I'd expect that a large client base would have a good chance of using the right combination of parameters that trigger the problem.

Just curious - which JVM are you using?

The only rational comment I can suggest is running a tool like OptimizeIt on both sides, the Java and C++. (I never used such a thing when I wrote C++, but I'd be surprised if it wasn't available.) That way you can get some data instead of being dragged into a religious finger-pointing war.

You said you ran a debugger on the Java side. What did you learn? Just that it went into the JNI call and never came out?

Politics are difficult, no matter what language you prefer. I'm sorry, but I don't have much advice there.
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Michael Duffy:
Hi Tony,

Tough problem, to be sure.

I'm surprised that the many clients of the C++ object haven't exposed the source of the segmentation fault. If that is indeed the source of the problem, I'd expect that a large client base would have a good chance of using the right combination of parameters that trigger the problem.

Just curious - which JVM are you using?

The only rational comment I can suggest is running a tool like OptimizeIt on both sides, the Java and C++. (I never used such a thing when I wrote C++, but I'd be surprised if it wasn't available.) That way you can get some data instead of being dragged into a religious finger-pointing war.

You said you ran a debugger on the Java side. What did you learn? Just that it went into the JNI call and never came out?

Politics are difficult, no matter what language you prefer. I'm sorry, but I don't have much advice there.



Hi Michael,
The problem is that sometimes running a debugger is difficult. For example, we have on client who is a major bank - they certainly won't permit me to connect to their machine, especially when the application is for digital certificate management.

The C++ code is very rarely execute in its entirety - for example, there are certain features that are used quite often, and many that are not - the Java application uses part of those functions, which are not often used, hence, it is usually the first to expose such an issue.

When I do run a debugger, I am usually able to watch control step outside of the VM via a native method call, and observe a segmentation fault. My question is, is this an optimal process for problem resolution? It seems absurd to me, that the only reason that I must go to the effort of exposing the problem, is simply because the problem was exposed through the Java layer by the client - we all agree that the Java application cannot itself produce a segmentation fault - only the VM and JNI.I say this loosely because the less-informed party have some vague understanding of Java, and are not willing to concede (or learn) that this assertion is correct - they'd rather keep the issue vague by avoiding it - so be it. After I do this, I simply pass control to the owner(s) of the JNI - why didn't I just do this in the first place?

It is exactly this reason that I don't intend to get into figner pointing wars. I truly don't care if I have to fix a problem of any kind, but I do care if a paying customer suffers as a result of the inability to discern between the correct method of resolution of that customer's problems. I believe that the current process does indeed contribute to pain on behalf of the customer.

As an analogy, consider I work for Microsoft, and I write Visual .NET Studio. I add a button to the screen for the IDE. A customer, somewhere down the track, presses the button, and Windows causes a memory protection fault and BSODs. The customer rings support, who have little technical competence in a specific area such as this one, so they simply forward the problem to me - understandable. I view the problem, and since I do indeed have the technical ability, I determine immediately that the problem lies within Windows memory protection, so I forward the problem to the relevant team for resolution. I receive a response about why the problem is mine until I can prove otherwise e.g. by setting up this same environment, and reproducing it, then demonstrating why it is not the fault of the button, but of Windows. This response to me, appears absurd. Furthermore, the Windows people take advantage of their authority by condemning me for even attempting to avoid the problem (I claim I was merely acting in Microsoft's interests and the customer's interests), and lacking initiative. I don't understand why it's not obvious that this is an extremely inefficient method of resolving customer problems - the ultimate common objective between all parties.
[ January 04, 2006: Message edited by: Tony Morris ]
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Tony Morris:

It is exactly this reason that I don't intend to get into figner pointing wars. I truly don't care if I have to fix a problem of any kind, but I do care if a paying customer suffers as a result of the inability to discern between the correct method of resolution of that customer's problems. I believe that the current process does indeed contribute to pain on behalf of the customer.



I feel that it's more than a process issue - healthy teams work around processes that don't help them.

So something is making both developers value the fact that they are not responsible more than making the customer happy. What is this? Corporate culture would be my guess. (In this context I wonder why it was decided to strongly separate these two roles at all.)

I would want these two guys to cooperate on the problem. Problem is, you can't just tell them to - they will need to *feel* that cooperation actually is valued, that fixing the bug actually is more important to the company than finding out who's fault it was, or whatever else is currently holding them back. (Do they report to the same manager?)
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:


I feel that it's more than a process issue - healthy teams work around processes that don't help them.

So something is making both developers value the fact that they are not responsible more than making the customer happy. What is this? Corporate culture would be my guess. (In this context I wonder why it was decided to strongly separate these two roles at all.)

I would want these two guys to cooperate on the problem. Problem is, you can't just tell them to - they will need to *feel* that cooperation actually is valued, that fixing the bug actually is more important to the company than finding out who's fault it was, or whatever else is currently holding them back. (Do they report to the same manager?)



I agree with your first point, but there is one unfortunate circumstance - the process itself is defined by those who are responsible for the C/C++ component. The issue is simple in my mind. Sure, you can ask the Java guy to run off and reproduce it, but in doing so, you achieve absolutely nothing - confirmation that the defect belongs in the C/C++ code - this could have been achieved within 3 seconds. The only additional value is that you might have some information to provide to the C/C++ code owners so that they can determine the cause of their problem. Sure, this is might be perceived as a benefit, in which case, you do achieve something after all, but is it efficient?

After all, the C/C++ code owners are merely going to have to set up their environment and do this and that in order to reproduce the problem yet again - it has now been reproduced three times. The work effort is in reproducing the issue and observing it - the rest is usually a piece of cake. Once you cna observe the issue, and have clarity on the issue (a segmentation fault is pretty clear anyway), the rest comes together in a matter of seconds.

This unnecessary delay is what bothers me - the customer is delayed for no other reason than the incompetence of those who set the processes. If it meant that the customer benefited by the Java code owner reproducing the problem 43 times, then so be it. I just don't see the benefit in the Java code owner producing the problem, not even once. Of course, there is the explanation that you mention - failure to put the customer's needs first, that is, the Java code owners and the C/C++ code owners have different premises from which to extrapolate their decisions, in which case, incompetence is not the issue (nor my ignorance should I be missing something). This is, after all, a corporate environment, and I agree entirely with your somewhat simplistic, but still accurate enough, point of view. Assuming that indeed there is a common primary objective of all parties, I have no more plausible explanation than incompetence on behalf of the process makers/C/C++ code owners.

In short, there are three possibilities:
- The C/C++ code owners have some other agenda besides keeping the customer's and the company's interest as primary.
- The C/C++ code owners and process makers are incompetent and enforce a suboptimal process.
- I am completely ignorant to some fundamental point that results in a bias of my reasoning, and that perhaps the current process is efficient, only that I cannot see it.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, there is another possible reason: it's how they know to do it.

It has been often observed that people prefer to fail using known, conservative ways over possibly succeeding using ways new to them.

Or with other words: the process they use *is* efficient - in keeping them inside their comfort zone.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Sure, you can ask the Java guy to run off and reproduce it, but in doing so, you achieve absolutely nothing - confirmation that the defect belongs in the C/C++ code - this could have been achieved within 3 seconds.



You have accomplished a bit more than nothing. You have found a way to give yourself some confidence that it has been fixed, if and when you ever get the C/C++ guys to work on it.
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:
Well, there is another possible reason: it's how they know to do it.

It has been often observed that people prefer to fail using known, conservative ways over possibly succeeding using ways new to them.

Or with other words: the process they use *is* efficient - in keeping them inside their comfort zone.



I think this is probably the most plausible explanation. Assuming it is the case, it falls under the category of "having some agenda other than the customer's and company's interests" (one's own personal comfort, etc.). Not knowing that this is the case such that it can be remedied falls under "general incompetence" (inability to reflect unto oneself in order to observe the existence of a problem with oneself in their field of work). Agree?
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic