3

I am working on a project with a team of 4-5 people. Is it necessary to discuss the database changes with the team before implementing? I am working on the database api's.

Is it better to discuss this or not? In my team are senior people. So can't I make changes myself and implement the change and explain the changes.

Improve this question
4
  • 3
    Who owns the database schemas? Commented Dec 22, 2010 at 10:46
  • If you are implemented the database API and the rest of the team is merely implemented code which will rely on your API than frankly I do not think it is needed. However, for the better sake of the team I think it is worth at least touching on for some other insight. You may think your changes are great but someone might have a different thought and teammates like to be included in design decisions. Commented Dec 22, 2010 at 12:59
  • @Thorbjorn Ravn I owns the schemeas Commented Dec 22, 2010 at 16:27
  • @walter thanks for editing , want to improve my grammer Commented Dec 22, 2010 at 16:28

8 Answers 8

Reset to default
10

Table structure reflects relations between your object. Such changes are quite important and should be discussed.

Improve this answer
0
3

I dont think this is only related to database changes.

If you are not the Senior Architect or Database Programmer in your team, any changes you make to design & implementation of code or SQL or DB tables or any other artifacts, should be reviewed and approved by other team members - either peers or seniors.

Are you hesitant to do this? Is there no formal review process already in place?

Update:

In your case, it depends on what impact the changes have. Are you making a small change like the length of a single VARCHAR2 column or adding new columns to the table which need buy-in from the front-end developers too? In any case, I'd say discussion is better than not doing so - and regretting later

Improve this answer
2
  • I am not hesitant , but i don't want to discuss unnecessarily if not required , as per your answer you are suggesting changes should be reviewed and approved Commented Dec 22, 2010 at 10:33
  • @Rahul: It depends on what impact the changes have. Are you changing the length of a single VARCHAR2 column or adding new columns to the table? In any case, I'd say discussion is better than not doing so - and regretting later. Commented Dec 22, 2010 at 10:36
2

I don't think there will be a good general answer. It really depends on whether the work of other team members will be affected by what you do or not (although I tend to think changes of the database structure will affect other code). If the database design and API is solely your responsibility, then the least you should do is INFORM people of changes that may affect them. If you are not sure about the effects, ASK the team members so you will be able to judge the trade-offs and make the best (re)design decision - the team as a whole will benefit from it.

If there are other people being allowed to make changes to the database or share your responsibility there will be a need to COORDINATE everything. You can call this DISCUSSION, but I don't see anything bad in it, unless your team's way to discuss things is perceived as an unjust judgement/criticism of your work. If this is the case I'd understand why you feel uncomfortable with it. But the way to solve this is not to think about what to discuss and what not, but to change the "how" to discuss and to change the team spirit.

Improve this answer
3
  • you understand my questions very much as you write in your second paragraph Commented Dec 22, 2010 at 11:08
  • "But the way to solve this is not to think about what to discuss and what not, but to change the "how" to discuss and to change the team spirit. " Please explain this line Commented Dec 22, 2010 at 11:09
  • My suggestion then is to discuss with the team that the discussion in itself is a problem, because it seems to focus on creating bad feelings instead of better team results. You can call this a "meta-discussion". Even if some team members don't produce the best code every time, the way it is discussed is not very productive for the team result. A discussion should not focus on past blame, but on future fame :) Commented Dec 22, 2010 at 11:45
1

Depends what you mean by "discuss".

If by "discuss" you mean "debate" or "design by committee", I say no. The developer who is the owner of a section of an application gets to say what the schema looks like.

If, instead of "discussing" database changes, you change the database and not let anybody know until their code fails, I say yes, "discussion" is critical.

Improve this answer
2
  • +1 for explaining both negative and positive of discuss >> from now want to design by my self not by commitee Commented Dec 22, 2010 at 16:10
  • and want to discuss every design with the team memeber before their code fails Commented Dec 22, 2010 at 16:13
0

As pointed out by others before, its definitely better to discuss. This is especially true in case of database changes. Database, being pretty much the lowest layer, means that any changes to it ( both additions but especially modifications) can potentially have the GREATEST impact to the developers on the team.

A formal review process is a MUST (and preferable this has to be done by the data architect / dba / someone who owns the schema ) but even if that is in place, i would still recommend a discussion with team members about data especially schema changes before hand.

People with a broader technical / domain / application understanding than you might be easily able to point out pitfalls / need / changes to your approach at an earlier stage than a review saving you time and effort (if they are right)

Improve this answer
0

This seems as a design change. This must be done in the design phase. This should get reviewed in the design review.
So my short answer is Yes. Get it reviewed as early as possible. Because if it is not reviewed and someone else has created yet, that person is surely going to get pissed.

Improve this answer
2
  • ...and then there's reality. Not that I disagree with you: it should. But then there's reality. Commented Dec 22, 2010 at 13:02
  • Edited the response. Commented Dec 22, 2010 at 13:14
0

Don't you have team meetings? Daily scrums or weekly status get-togethers or anything? This is the kind of thing I'd expect to be raised in these meetings. It doesn't sound like the changes are so significant that they require fair warning, but they're presumably important enough to warrant changes to the API, so people should definitely be informed. Does your team use a wiki? If so, then maybe create a page that lists database changes and the date they were made. Alternately, if you're using a bug reporting system, you could create a "change" or "improvement"-class issue and describe the change there.

Improve this answer
0

iff you own the API and your changes dó not affect others, Then I would consider you to have free hands in doing what is neccesary to dó your job.

A's soon as your changes influence others it becomes a team issue.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.