How to resolve issues with offshore resources that control the product?

Question

I took a position as a Junior programmer on a programming project 6 months ago. However, I do have 10+ years of experience, but I needed a job fast. The project I joined has been ongoing for the past 4 years. However, the client tells me that since I joined, things have actually gotten done.

The senior programmer is an offshore resource and has control of the source code and implementation of the entire project offshore. In my personal opinion, I believe that this resource has been milking the organization and when I joined, I was given the a list of coding restrictions:

• No inheritance allowed
• No use of stored procedures
• No use of foreign keys
• No use of frameworks

Since he is the only one with access to push this to production, if I use any of those techniques, the code would not be pushed.

EDIT: For clarification on confronting the offshore resource on the above restrictions. His response was that he doesn't know how the system will react if we introduce these methodologies. For those interested, the system is using a standard Linux-TomCat-Java-MysQL setup.

Needless to say, the code base is huge and not very flexible. Any simple change the client requests are taking a long time. I've raised these issues with the Project Manager, but he has tasked me to "convince" this senior programmer to let me clean up the code base. I feel this is out of scope for me, but it appears that the Project Manager fears the offshore resource given that he holds all the keys to the product.

My contract is only 1 year, so I could just play along, but I would like to see this project succeed since it is for a non-profit organization and it would help them immensely.

What advice is there to resolve this issue without compromising the product that exists overseas?

EDIT: To clarify the specific issues: Data integrity is a problem as the application looses client data. System stability is a problem as the application looses configuration settings.

Essentially it boils down to how do you tell an offshore resource that change is required in order to meet the client's requirements without compromising the product itself? The sense I get is that the PM is worried that the offshore person will cut the connection and we loose the data and the source code. The project started offshore because it was cheaper, but it sounds like it's some guy in a house as we can hear children in the background during conference calls.

Answer 1

To me the most important observation here is that "he doesn't know what will happen if you introduce these methodologies".

My guess would be that he is largely self-taught and aware that he is responsible for this application and need to be able to maintain it. This would explain the "no inheritance" (if he does not understand object oriented programming, and just use Java as a plain procedural language) and "no frameworks" (because you need to understand the whole framework to use it correctly). The "no foreign keys" can be explained by bad experiences trying to load data into tables with foreign key constraint in place and having it fail because the data was not entered in exactly the right order. The "no use of stored procedures" makes good sense if you consider that you now have two locations where code must be maintained and kept in sync instead of just having a single "deploy a new war" approach.

Additionally, it is actually a Best Practice to reject any code that does not conform to the given rules.

So, you may want to consider asking why these rules are in place, since knowing that may make you change your opinion from them being silly to recognize them perhaps being the result of some very unpleasant experiences, or simply to understand that there are some ways of working that the team is not qualified to do.

I do not think that the correct approach here is to let you clean up the codebase. You will be gone in a year leaving him with code he may not understand fully, but still have to maintain.

The problem as I see it is not as much with the code base, but that changes take a long time. The code base may not be the cause of that, so I would suggest that your boss initiates an investigation to clarify where the time is spent, and whether it can be improved. It may be somewhere else than you think.

Also remember, regardless of how bad the code is, it is still battle tested production code, which is a very valuable thing. If you start changing it, it is not that anymore. You might be surprise how much time and money is needed to get your revised code back to the same status.

Answer 2

when I joined, I was given the a list of coding restrictions:
No inheritance allowed
No use of stored procedures
No use of foreign keys
No use of frameworks

No inheritance - composition/interfaces over inheritance
No sprocs - code should be in one place
No frameworks - partially introducing a framework can be confusing and hard, switching to a framework can be a major change
No FK's - he's crazy

In short, for the most part, the restrictions are reasonable -- not necessarily correct, but that isn't the point. Sometimes comfortable is the right way to go, and it's not you that is going to be supporting this. I would pick a battle and then fight it -- in this case, the first battle should be getting the code onsite. After that FK's as data integrity is usually critical.

As to how. For the code, just ask -- if he says no, take that to supervisor and see how they want to handle it. If it's supposed to be their code and he doesn't hand it over, that's a major problem and not something a junior dev can resolve.

For the FK's I suggest starting small, doing one at a time, after verifying that doing so doesn't break anything. This will probably be slow and take away from new features. But you can't just slam it in and say that if it breaks something it's already broken. Out of order creation/deletion of FK's can work without the constraints being in place which means badly designed but working code can be broken when introducing them. This is probably the most bang for the buck and the least likely to break something and the most amemiable to testing. Show that it can be done without breaking the app. Find where a table is being used, and show that all of those pieces still work after adding a FK.

While most of the above has been more technical than workplace, I'd like to address that as well. You have two conflicting problems -- you need a job, and your boss either wants you to play the heavy or doesn't want to get into the middle of an argument. Without the authority to resolve the issues, you need to tread carefully as pushing may get push back ending with your temporary position being shorter than desrired.

If you get all of the code to the application (and regular updates), I would suggest that the rest of it basically boils down to a difference in how best to do things, and you weren't hired as the lead dev. You can offer to show that your changes are both good and manageable, that they can be done safely and offer benefits. But ultimately, it's not you in charge. If he is unwilling to let you introduce the changes, your options are to quit or do it his way.

Answer 3

I have never heard of such coding restrictions. So much so that I was close to marking this as an unreal question.

However, there is a possibility this is indeed the case. Have you made an attempt to understand fully why these restrictions were imposed ?

If you think these restrictions are whimsical if I were you, I'd first initiate the talk with my PM. In your case since you have the go from your PM, if the offshore resource is not a sociable person, then write a mail to the PM, this sr. resource and the project lead/designer/architect with a few bullet points explaining why you think the core design of the project is amiss. Identify potential causes for system failure and figure out the anti patterns. I would take a simple module and with the help of use cases show how/when the module will break. I would then compare it to my rewritten solution of the same module that would be built using some commonly followed design principles or in your case what you think is missing. Also highlight the time saved in coding, maintaining and scaling future requests.

The offshore resource may be the key person, but don't you have documentation around what is being done ? If the project manager wasn't prepared for his senior programmer to be hit by a bus, I think you will just have to assume he was and propose your solutions.

Answer 4

You are in a bad spot.

If your PM was ready to tackle this issue, you would

1. Document the production environment, reproduce it, and try to manage deployment to a "shadow" location yourself.

2. Ensure you have all source code. All of it!

3. Set up an automated build / deploy to your shadow environment, including ETL from the production DB to your "shadow" DB.

4. Get the scripted deployment "Rock Solid," and load test the shadow environment.

5. Ensure you have a "Kill switch" on the existing production environment, and that your offshore resource has no access to the shadow environment.

6. Kill the production environment, activate the shadow as production, and inform the senior developer that deployment of updates is no longer his responsibility.

7. Establish a new authority structure. The senior developer may not be malicious, but he is obviously running rogue. Inform him that he is no longer in charge of architecture, but can continue as a developer if he agrees to the new structure.

8. Bring modern development into the project in phases, allowing the offshore developer time to incorporate and learn it.

They are in a very bad spot, and there is no way out except through pain. They either need to face it, or give up. There is no middle ground, here.

Answer 5

First you say this:

In my personal opinion, I believe that this resource has been milking the organization and when I joined…

Then you say this:

His response was that he doesn't know how the system will react if we introduce these methodologies.

But you also started out saying this:

I took a position as a Junior programmer on a programming project 6 months ago. However, I do have 10+ years of experience, but I needed a job fast.

So what it basically sounds to me is you are 100% right. Nay, 1,000% right. But I will clarify things.

First, I don’t really think the original developer is consciously milking this project. But somehow at some point he got in the door, got in over his head & now thinks that the code is truly “magical” and that nobody else can help.

When he says he doesn’t know how the code would react, I believe that is true as well.

And now as for you, most places would not hire a programmer with 10+ years experience but you landed a gig here. Big red flag. Pretty sure without knowing any more that other coders walked into this situation & then left at some point.

That said, it seems like you are competent & see a better path to this. If this off-shore resource is hold the codebase hostage, how exactly are you doing work? I assume you have a development clone somewhere you work on right?

My advice is this: While it is indeed out of scope for you to clean up the codebase, what about working with your project manager to show work you have done that you know the other programmer would reject & explain the benefit.

And since code is code, perhaps you should approach your project manager & say, “Okay, if you want me to clean up the code, we should setup a secondary production—possibly staging—server that I control.” And on that server you do your work & prove the other programmer to be incapable.

But here is the key thing: You should only do that if you can get a renegotiated contract for the gig. Maybe extend it past a year, but basically reframe it as the work you would be doing will help the company, help coders & save time, money & energy in the future. And if you feel like this would overwhelm you, ask about bringing someone else on board.

But the reality is this other programmer is not going to play along with you. You can work with your project manager to make gestures towards cooperation, but that would be a miracle if you ask me.

Answer 6

The customer is not always right. The customer is always the one with the money.

Sometimes you can teach the customer. Sometimes you can't.

When you can't, you need to decide whether you'd rather be right or be paid. Make that decision and live with it. If you accepted the constraints when the project was presented to you, it would be bad form to back out partway through.

You can present concrete arguments for reintroducing these ideas. You can ask the person making the decision what it would take to convince them that these were worth using. But if they have anything resembling a good reason for their decision -- even if the reason is that they need to be able to port it to archaic languages, run it on minimal-subset databases, and so on -- you have to be able to work with that.

One solution may be to implement equivalents of some of these concepts yourself, if they'll pay you to do so. For example, OOP is mostly syntactic sugar over structs with dispatch tables and a type-tagging field. You don't need an object-oriented language to write OO code any more than you need a block-structured language to write block-structured code; it just makes doing so easier.