My team leader has this terrible habit of mucking with the database schema, and making changes that would cause severe breakage on the code base (without really consulting me on how the changes would affect the code base).

Normally, I would just live with it, but we have a deadline in 2 weeks and this has been happening ever since I started 1 and a half months ago. I was brought on, to speed up the development of the project.

Due to the deadline I am already putting in 60+ hours a week, and dont really have energy left to deal with this (I have tried in some ways already). We are only a 2 man team, and besides changing the database on a daily basis, he has not contributed much in the sense of actual development (coding).

Currently, I am feeling like I am doing all the work, plus having to 'fix' what he breaks with his changes.

How does one deal with this? I have already spoken to our manager about his lack of effort in the development department. He has been there 6 months longer than I have, but I have written 95% of the code when you exclude the 5th normal form database monstrosity he 'contributed'.

Any suggestions?


On Friday we had a discussion with manager, and I made my worries known. This led to a bit of confrontation, but overall I felt the manager was siding with me. So at least we have our data freeze in place now, let's see how it goes from here.

  • 3
    +1 for the tag 'too-agile'! :-) Agile is a great methodology, but some people mistakenly claim they are agile, when they are simply undisciplined. Commented Feb 14, 2009 at 21:14
  • 2
    A prime example of automated testing being worth its salt. He alters a table and 15 minutes later bells and whistles start telling you all that code has broken.
    – user1249
    Commented Jun 7, 2011 at 5:54

8 Answers 8


"Deadline is in two weeks; we need to freeze the schema if we're going to hit it."

  • 3
    Ok, step 1, freeze database, step 3 profit! :) Let's see how it goes...
    – leppie
    Commented Feb 14, 2009 at 18:35
  • 1
    I have kinda taken charge without taking responsibility, we have another team member now. Your advice was the ultimate answer for the time. We still stare the sh*t fan head on... :(
    – leppie
    Commented May 29, 2009 at 15:51

Speaking to the manager AND the developer at the same meeting:

"Database and code changes need to appear simultaneously. If you change the database, you must also change and test the code base. Otherwise you are submitting broken commits, which is unacceptable if we are to meet the deadline. I will no longer fix code broken by your commits, I will simply back out the changes and leave you an email note because I cannot investigate and fix issues outside the work I'm assigned and still expect to meet deadline."

Much harder if you don't have a test plan...

  • Test plan? We dont even have a friggen plan! Just the usual client requirement spec, written in the client's language... And yes, it's very sad when you have to make a checkin note saying: BUILD IS BROKEN.
    – leppie
    Commented Feb 12, 2009 at 16:05

You are going to have to be more forceful and make sure that soon (as in yesterday, the day before yesterday, or last month) you settle on a schema and move forward. There's no sensible way that you can continue to develop an app with a database that is a moving target.


You need to confront him and explain to him how his changes are effecting the code base and hence the project time lines. Convience him that he needs to consider the impact of his changes before effecting them. Also make him to agree in the presence of your manager to the fact that he will be responsible for any delays that he induces by this behaviour


If the team lead is not reasonable person (and he/she doesn't sound reasonable from your description of his behavior), talk to your manager and explain to him that you won't meet the deadline with the way things are going. Ask him to take a stand and make sure your team leader is aware of this by holding a meeting where the manager sets expectations.

You should also push your case regarding your team leader's lack of contribution to development. Both issues must be resolved to make the project a success.

  • We have been through something like this, but it seems he did not understand... well he said he would contribute, but I have seen nothing so far, except schema changes. I wonder if he can even write code, and not just 'design'.
    – leppie
    Commented Feb 12, 2009 at 16:07
  • Why is the manager letting the team leader get away with this? Who made the team leader the team leader? Doesn't your manager have a say in this?
    – Akbar ibrahim
    Commented Feb 12, 2009 at 16:19
  • I guess the manager is trying to save face. At least i warned him early, and hopefully they will not put the blame on me for delays.
    – leppie
    Commented Feb 12, 2009 at 17:07

You are going to have to enforce some restraint on your team, but that can be tricky to play in your position in it.

A useful way of tackling this might be adopt more rigorous documented change control. You can play this by insisting that at the moment ad-hoc changes are putting at risk your ability to manage the system updates in a way that doesn't have unforeseen, and deadline threatening, consequences (which is true). So insist that all changes must come with documentation showing the proposed change and the effects thereof on all other code and structures. You'll be amazed how much that will reduce the volume of changes that come through :-)

  • One of the other IT support guys recommended that :)
    – leppie
    Commented Feb 12, 2009 at 18:50
  • Hehe, that's because it's true - I've been there. Most of the other answers here are techie solutions to a perceived logical systems failure. Actually what you have behavioural problem, so you need to implement a punishment/reward system to modify that behaviour
    – Cruachan
    Commented Feb 12, 2009 at 22:11

Have you held a retrospective with the team? If not, hold one. When you do, identify the unplanned changes (mucking with) to the database as an issue. Specify the cost to you and others regarding risk and quality of work life. Continually working 60 hour weeks is not sustainable. If you are not able to sustain your pace of development, you are not doing agile.

Also, are you doing TDD (test driven development) or automated functional/ regression test? If so, changes to the database should result in broken tests. This should help address the impact and identify the code that needs to be updated.

In this case, your team lead is not "too agile", your team lead is an "agile cowboy". Hold a retrospective, identify what went wrong. Prioritize it high, then address it during the next iteration. That should rope in your agile cowboy!!!

  • I have tried and tried. I think he is purely a BS'ng cowboy. Anyways, I am living with it.
    – leppie
    Commented May 18, 2009 at 5:26

Weren't there a same issue with you about a year ago? 'My team leader says A.Property = A.Property; is fine'. Seems like the qustion was banned 'cause I don't see it in my comments history. Anyway, the point is:

If you feel all your team leaders are messing you up having barely a half of your experience, you'd probably find a job without one. I would suggest to take a try and become a lead as another option, still should you be capable of, you'd been already offered to do so.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.