Software development best practices....

JerryMungo

JerryMungo

Honorary Master
Joined
Jul 18, 2008
Messages
37,548
Reaction score
6,281
Oh crikey... we have a situation with a client. One staff member at the client thinks they can do 'stuff' and they effectively want admin access to the DB while we are still developing... in their mind, they want to be able to add fields or tables while we are still following the existing development schedule since we can't do everything he wants within the timeframe.

The whole idea is dumb obviously - having someone not part of our dev team fiddling with the database, but I've been asked to please send something... a blurb / paragraph detailing why it's not best practice lol.

Now my Q is... is this piece of incredibly obvious information written down somewhere in some form, or is it just so obvious that it doesn't need stating?

I'm not trying to convince them on my own steam, I'd prefer to simply link to a software dev / project management best practices guide somewhere. Any help would be appreciated. Tx!
 
Sometimes you must just let them do it. Give him enough rope to hang himself.

In my opinion and on all the successful projects I worked, only a DBA works with the database, end of story.
Whereever this was not the case, it always ended in a major disaster and huge costs.
 
No problem in creating a "dummy" dbo and allowing him to use it.

EDIT:

On second thought I would not allow this, some of my table designs are hard to work out and I wouldn't want to give away my intellectual property.

There is also no reason for him to have admin access to those tables.

It is also a security problem even if its a dev dbo

Clients don't usually have a lot of common sense and might leak critical systems information out.
 
Last edited:
He doesn't want to play, he want's to dev :) But yeah, we're definitely going to let him take a backup for himself to fiddle with. I think he is just being deliberately obtuse about the fact that we refuse to give them more than we originally agreed on in the same time frame. He wants to work in parallel with us on the system. We should be done with the DB by the time he wants to tackle it, but we won't be done with the UI and other integration aspects. The trouble is that I'm not prepared to give him any rope as long as we are still contracted to get the job done, otherwise we are going to end up playing a blame game when the system fails. I think I'm going to throw contract jargon at him. I cant see how the client can hold us responsible for our deliverables while they have staff able to fiddle with the system.
 
Nether said:
No problem in creating a "dummy" dbo and allowing him to use it.

EDIT:

On second thought I would not allow this, some of my table designs are hard to work out and I wound't want to give away my intellectual property.

There is also no reason for him to have admin access to those tables.

It is also a security problem even if its a dev dbo

Clients don't usaully have alot of common sense and might leak cricatical systems information out.
Click to expand...

The client owns your work, so no "my intellectual property" is involved.
 
We do system integration for big control systems in factories, mines, etc. and this is the most common issue we have to deal with since commissioning sometimes last months and you cannot be on site every single hour of the day to fix something that goes astray. What we usually have them do is sign a document saying we do not take responsibility for anything that goes wrong majorly from that point since their own personnel are/could edit an unfinished product. Regarding the IP concerns they are paying for it anyway and once you are gone they are going to be able to pull it apart all they want, so you cant really rely on that argument, less be called on it by the client.
 
TheRidDlerX said:
We do system integration for big control systems in factories, mines, etc. and this is the most common issue we have to deal with since commissioning sometimes last months and you cannot be on site every single hour of the day to fix something that goes astray. What we usually have them do is sign a document saying we do not take responsibility for anything that goes wrong majorly from that point since their own personnel are/could edit an unfinished product. Regarding the IP concerns they are paying for it anyway and once you are gone they are going to be able to pull it apart all they want, so you cant really rely on that argument, less be called on it by the client.
Click to expand...

Yeah, I think this is the crux of it. Either they sign something to that effect or they wait for us to finish and hand over. Agree.
 
WoDotNant? said:
He doesn't want to play, he want's to dev :) But yeah, we're definitely going to let him take a backup for himself to fiddle with. I think he is just being deliberately obtuse about the fact that we refuse to give them more than we originally agreed on in the same time frame. He wants to work in parallel with us on the system. We should be done with the DB by the time he wants to tackle it, but we won't be done with the UI and other integration aspects. The trouble is that I'm not prepared to give him any rope as long as we are still contracted to get the job done, otherwise we are going to end up playing a blame game when the system fails. I think I'm going to throw contract jargon at him. I cant see how the client can hold us responsible for our deliverables while they have staff able to fiddle with the system.
Click to expand...

By all means give him a sandboxed version of the database.

  1. Limit the DB changes to the creation / modification of 'his' tables: if he is allowed to modify your tables you'll never know where you stand;
  2. Allow him to submit the SQL for the DB changes; however, you should run the actual scripts;
  3. Use your source control system to keep a history of 'his' DB changes; and
  4. Insist that 'his' development work be added to your source control system. It might be an idea to limit his access to his personal code.
Ths SCM will provide a history of the changes if there is a fight with the client. It will also allow you to perform a code review of 'his' work :)
 
Good ideas there, though even with that, it means extra time for us and we are working on a schedule that would require a contract mod to bill them more hours, so it makes it difficult.
 
WoDotNant? said:
Good ideas there, though even with that, it means extra time for us and we are working on a schedule that would require a contract mod to bill them more hours, so it makes it difficult.
Click to expand...

True, but the request for additional hours could be justified by the fact that you are meeting their out-of-spec request (which normally means a contract variance) whilst protecting the current development.
 
Agree, we'll consider that I think. I just hate high risk situations like this, especially since we have to be very careful that he doesn't spin the client (his employer) stories about us when he does break the system.
 
WoDotNant? said:
Agree, we'll consider that I think. I just hate high risk situations like this, especially since we have to be very careful that he doesn't spin the client (his employer) stories about us when he does break the system.
Click to expand...

The main objective is to appear that you are doing your best to accommodate the client's requests. And if that costs, so be it :)
 
I see posts like "let him hang himself". Which is silly.

Why not just sit down the guy, explain the situation to him. It can be worked around. With proper teamwork and communication he never has to touch the db.

A Google search will probably yield many resources on the topic. I cannot even offhand think of a specific book example.
 
kripstoe said:
I see posts like "let him hang himself". Which is silly.

Why not just sit down the guy, explain the situation to him. It can be worked around. With proper teamwork and communication he never has to touch the db.

A Google search will probably yield many resources on the topic. I cannot even offhand think of a specific book example.
Click to expand...

We're relying on the BA to do that but they're unfortunately in the US. The trouble is that it seems his nose is out of joint because we are doing the work that he wanted a contact of his to do :)
We're not his friend it seems.
 
This is a new system and database correct?

Simple software best practice: database is developed around application, not the other way round. What I mean is, you don't decide we need to make people in our system, so lets make a table with first name, last name, etc, and then write classes to use those tables. You design your software, and then make database work with it. It's a subtle difference that 90% of people is software dev don't follow
 
Tell him he can have his access if he has written approval from a director.

Office wars are not fought with references to best practice guides.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X