|
Is this the same Catman[^] that is a hero in Dimmsdale?
______________________________________________________________________________
Ah don't lean on me man, cause you can't afford the ticket
|
|
|
|
|
I pawndered the idea for a litter while and decided it was as of yet impurrfict.
Perhaps paws for fur-ther thought on this.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I can't say anything as the cat got my tongue.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Frogman is just the hero Paris needs -- the moment he spots trouble, he runs and jumps into the Seine.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
At which point I guess one could say that he is inSeine...
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
They need a man of authority - step forward Cartman!
veni bibi saltavi
|
|
|
|
|
|
Let's make this question for a good friend of mine  :
You are the only one capable to do something the right way as you have the knowledge of all the different technologies that are needed to make the project (robots, fieldbusses, artificial vision, special programing techniques, offline programming, Visual C++ and others).
The customer is surprised you can do it and understands you are the best option to make the project.
But then it happens:
The customer is scared about the future and how will you give technical support as you are a one man company.
What do you do in those situations in order to relieve the customer and to show them they can trust you?
Thank you in advance.
|
|
|
|
|
Can you provide any references from long term clients?
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
My friend can't provide this personally... he can provide it about the companies he has worked before, but not now.
|
|
|
|
|
That would seem to make things more difficult. They would have present themselves as having superior knowledge of the subject matter (that goes a long way in my book), the integrity to work as hard as necessary to get the job done, and a willingness to share (or teach) the general solution and tools to others. I say this because people don't necessarily need to know a product down to the floor level to implement/alter some features and/or fix some issues. It lessens the burden on the original developer somewhat, and keeps the client happy as they are not completely helpless if an issue arises.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
I can think of two things:
1. Give them specific details about the support you can provide. Make commitments on response time, working hours, etc.
2. If you have them and are allowed to do so, give them references from prior projects.
Software Zen: delete this;
|
|
|
|
|
Thank you Gary,
First is already done and second is not possible now.
Thank you for your post!
|
|
|
|
|
|
Thank you!
That looks very interesting, I'll pass this to my friend...
|
|
|
|
|
Well it all depends on how your "friend" writes a contract with the client.
There is a standard price/contract for the regular work/development etc and then you put a new addition in the contract for the transfer of the technical knowhow (except patent) to a group of people in the client side and they take care of technical support from pre-defined time.
cheers,
Super
------------------------------------------
Too much of good is bad,mix some evil in it
|
|
|
|
|
One way some people deal with this, from a legal point of view, is by having the source code held in escrow[^].
This means that if anything ever happens to you, your the source code can be released to the customer so that they can then hire another developer to refactor using the source code held in escrow.
In terms of how you convince the customer - if the customer believes you are the best option and at the same times is scared about everything depending on you - there is very little you can say as they have set their own dilemma up by understanding you to be the best. Code escrow may be the way to go.
Good luck with convincing them 
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
What I know as an option is to encrypt all the source code using a very big password giving the customer the custody of that source code (big set of files) and then, storing that password in a neutral place (which earns money by stored paper pages) that the customer can reach prior demonstrating the program maker has been late for x hours to provide them an answer...
That was more or less what my friend offered but it is still not enough for the company...
Thank you for the post and the wishes!
|
|
|
|
|
Carry a weapon. Fear and respect are the result. Trust is merely a happy accident.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
modified 30-Mar-16 10:46am.
|
|
|
|
|
Trust happens only while they are alive... 
|
|
|
|
|
Joan Murt wrote: What do you do in those situations in order to relieve the customer and to show them they can trust you?
My 2c:
- Give them access to the source code (or as someone else pointed out, use some sort of escrow mechanism)
- Ensure them that all documentation for building and supporting the system will be provided, this includes things like domain registration, server keys, etc.
- As you go through the process, document tech support questions and answers, so they have a growing library of "how to..."
- Possibly provide a couple other devs that you know and trust that can help to take over the project if something happens to you. Of course, in your case, your expertise will make this difficult.
- So, to the point, in your case, finding experts with the tech they are needing will always be difficult, and it should be pointed out that even a "company" will probably not have that particular mix of expertise.
- Which means that they need you both need to do a risk assessment, clearly identify the risks, and come up with how to mitigate it, especially since #5 means they are really going to have to look hard to replace you. They're stuck in that situation anyways, even if they get cold feet.
Marc
|
|
|
|
|
So... my friend is dead as he won't be able to work for anyone... 
Yes, the idea is to grow up a company that offer industrial software solutions, but at the beginning it is not possible to have plenty of people working there...
Let's see how it goes...
Thank you for your feedback!
|
|
|
|
|
1-3: Source code and well organized documentation was what I was going to suggest. A wiki is good for that.
4-6: In the documentation, you can indicate which skills are needed. In your list of devs, you can indicate which skills they have. It is not necessary for one person to have all the skills required.
|
|
|
|
|
I'm going to play a slight bit of devil's advocate here, but aren't they right to be concerned? He might have time to support them now, but what about after he has taken on 10 other clients and they all need support too? What I would do is tell them that you'll draw up a service-level agreement (SLA) that outlines the level of support they will get and (most important for the client) penalties for failure to deliver that level of service. This could range from the issue being non-chargeable or even financial penalties. This still might not be enough as if your friend can't afford to maintain the SLA and there is no real value in suing they're still lacking their service.
As for escrows and encrypting the code etc, it is normal that if you do a job for someone they own the code, not you, so no need for any of that to be considered. If your friend wants to keep the code too then they're going to have a hard time convincing anyone to do work with them.
|
|
|
|
|
Yes, they are right to be concerned, but working with a big company is neither a guarantee that nothing will go wrong (i.e. Windows updates ).
Working in the industrial sector is a little bit different than working in the IT industry, and usually the code is owned by who makes it, but you are right, this could be a future problem.
Thank you for posting.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
