I'm unsure how to handle this. Advice?

[blueridersf]

I seem to have found myself in a bit of a pickle and I'm unsure how to handle it.

I have been a software developer for quite a few years (>10) and in the past have always been an employee of the company I was working for. Last month, for the first time, I accepted a contract as an independent.

I now find myself in a situation where I am in fundamental conflict with the company's design philosophy and methodology.
TFPiC: I think they should have one... any one!

The development team that they currently have has progressed fairly far along the process of writing both the server and client portions of the application in the absence of any architecture or design documentation resulting in a huge ad-hoc mess.

The technical manager has all the developers coding full speed ahead in nearly random portions of the code on nearly random features, which prevents me from doing any of the fundamental refactoring that is required to actually make this thing work.

I've brought up the issue by voice with my manager who insists that he believes in an "iterative approach to development".

So here is my dilemma.
1) My contract calls for me to use best engineering practices to deliver high quality code.
2) If this company continues its cowboy development it will fail (I've seen it before.)

As a contractor I don't really feel I have a voice in changing how the company operates and I don't really want to be the guy that walks in the front door and starts pointing out what's wrong. But in the current environment I can't fulfill my contractual obligations. Especially, in the absence of a design and the lack of authority to create one.

How have other people handled this situation?

(TFPiC= Tongue Planted Firmly in Cheek)

 

[SQLSister]

The first thing you must do is protect yourself. Voice your concerns in writing. Since there seems to be a conflict between the requirements that you are given for your contract (Ie using the best engineering practices) and what you have to work with, ask them to resolve the issue - either by amending your contract to reflect the actual practices of the company or by amending their practices and giving you more time to perform since the current situation is a mess and will need more time to fix than originally estimated. Keep it all very fact driven and professional. Give very specific examples. Show exactly why the current approach is failing and will cost the company money in the long run. Give suggestions for how to fix the problem. Understand that if you choose to do this, your contract might be terminated (the old shoot the messenger syndrome), so have a plan for what you will do for income if this happens. Good luck.

Questions about posting. See faq183-874
Click here to help with Hurricane Relief

 

[chiph]

Possible outcomes:
1) They'll listen to you and take your advice.
2) Business as usual, you continue to work there on a doomed project.
3) Business as usual, project turns out to be a success.
4) Business as usual, and they shoot the messenger.

Assign some probabilities to these outcomes, and plan accordingly.

My bet would be somewhere between #2 and #4.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[Provogeek]

Not very familure with the coding world, but as a consultant in the network intergrations world I run into fairly similar situations dealing with IT departments.

I get the impression you got the contract not to just add your coding skills to the project, but to fix a problem in the development of the project it's self. Who ever initiate the contract with you knows there is a problem and feels you can help fix it ... that person is the one you want to ensure you communicate your thoughts with.

One thing I would make sure is in your contract, success of failure to complete your contracted goals, you still get paid. Make sure your not going to get screwed for lack of team work from the "employees" of the company your contracted with.

Make sure you write up documentation on what the problem is and what needs to be done to get it fix, and turn it into your soap box in every status meeting you have on the project. Problem so so is caused by such and such and can be corrected by doing whatever. You have the expereince and you are bringing that experience to the table, if they choose not to listen and use it ... that their own fault.

You can leed a horse to water, but even shoving it's head in the tank won't get it to drink .... you have to get a hose and cram it down it's throat.

Many times I have had to just do my contracted job, even when the IT department did not want or like what I was doing. I am not reporting to them, I am reporting to the CEO or CIO. It's never caused me a problem with the bottom line and repeat business doing it this way, as long as I have documented the issues and explained them to the C?O I am reporting to.

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Brent Schmidt Certified nut case
Senior Network Engineer
Keep IT Simple

http://www.kiscc.com

 

[h0h0h0]

Yeah this is more of a relationship building type thing. Changes like this typically take lots of time to implement successfuly. A lot of your time is going to be spent on getting buy-in from everyone on extremely small steps. Don't try and do everything at once.

 

[jsteph]

blueridersf,
You do know that one of the reasons for hiring a consultant is to be the fall-guy.

I'd make your recommendantions known in writing. That's your cya memo.

Get that done, then try to push your changes through but don't kill yourself doing it. If they want to ignore your recommendations, but you've got it in writing, I'd just do your best with what's there, make sure you're paid on time, and hope the next gig is better.
--Jim

 

[aarenot]

Do not bid anything, work on a time and materials basis.

point out what will drive up your time, and what will drive it down. In writing.

You do not always get what you pay for, but you never get what you do not pay for.