How to handle this?

A

Ancalagon

Honorary Master
Joined
Feb 23, 2010
Messages
18,207
Reaction score
3,678
Picture this scenario:
You do some front end integration work - get everything working
Colleague has to do a user story that involves front end and back end changes. Impact on your changes - controls you added would need to be moved around. New controls added. Colleague would need to do backend changes too, but these backend changes have nothing to do with your work.
In the process of doing this work, colleague completely breaks the integration work you did. Comments out functions for instance. Leaves the controls you worked on non-functional.
Doesn't mention this and you find out a demo.

Now.... I'm irritated but I want to know what to do about it constructively and productively. Any ideas?
 
You have a process problem, talk to your manager.

Either the person were supposed to do things properly, or testing needed to catch the issue, or team management needed to happen so that you guys could successfully work together.
 
Theoretically when he was "finished" his work, everything including my integration would have been working. And he did say he had not finished yet. But, it also took me 5 minutes to correct what he did, so why break it in the first place?
 
Maybe he was still testing and needed to disable some of your code for a while.
 
Drifter said:
Maybe he was still testing and needed to disable some of your code for a while.
Click to expand...

Possible, but it took me 5 minutes to fix what he broke. And I did it without breaking his stuff. Why disable mine?

EDIT: He is a good deal more experienced than me, so I don't think it is because he does not know how to code.
 
One way to handle this is to ensure that you have decent coverage with unit tests as well as integration tests which can be easily run.

We have a process where before we push our feature, we have to rebase and run all unit tests without failures. We also have to verify that we can start all the app servers without failure. If there are failures, then the developer needs to go through each unit test and if necessary have a conversation with the developer who created the unit test because it may be necessary to alter the unit test depending on the nature of the changes. Our QA team also run automated regression tests against their environments as well as the CI server every evening and failures will result in the change not been progressed any further.

The key thing here is "communication". Enterprise development is a team effort, not grouping of individual efforts. And no experienced developed is too good to not get disciplined, and if required, fired :)

You will always have issues. Some bugs will slip through, but with proper processes you can ensure that any defect that gets through has a very low impact on the business. It requires discipline and some courage from IT managers to stand up and defend the process.
 
Last edited:
Unit and integration tests would not have helped since this was a front end issue. Also would not affect any app servers.
 
I would smack him in his head.

How do you break other peoples code and then NGAF?
 
Ancalagon said:
Unit and integration tests would not have helped since this was a front end issue. Also would not affect any app servers.
Click to expand...

You can't create automated tests for front end ? What technology is this using ?
 
(tl;dr skip to end)

Suggest a better workflow? We also implemented a sprint methodology (kanban)

Dev -> UAT (check, test etc.) -> Demo -> Live

We have one guy that coordinates the build from Dev to UAT to make sure initial build passes/doesn't break other code. Once that's done Unit Tests are run, our QA then runs regression testing including any new testing they need to be doing off of the test cases of all user stories done. Once they're happy and the sign-off happens, it gets through to the Demo environment.

Early Adopters/Beta testing clients have access to this environment where they can pull / update their servers from. So it's very important to have a Demo environment that doesn't break.

Once everything is running smoothly with no errors (usually a week or 2), we release to live.

end

I would talk to this "experienced" programmer and go through the way they approached their problem solving, ask why they commented out some of my code and their reasoning behind it, and why they didn't inform anyone that they made these changes that could possibly impact other people's work.

If for any reason this happens again, I would go to my manager and highlight the issues, that you attempted to talk to them to find out the reasons why their approach required them to break your code in the process, and that the talk you had didn't remedy the situation.

Any experienced developer will always keep other's code in mind when making changes to a system, because any experienced programmer would have been in a position where they would have to have worked in a team, not just solo.

If this guy has that type of experience, then I wouldn't be surprised if he was "one of those" (my way or the highway/refuses to take advice or work in a team environment etc.) and would seriously consider reporting him to management each and every time a mistake like this from his side goes through to demo/production
 
Ancalagon said:
We probably can, we just don't have any front end tests yet.
Click to expand...

So, in response to the question in the thread topic "How to handle this?", Do this :) Its hard work, not just writing them, but maintaining them, but its well worth it because it protects your live env.

We are in the process of finishing a rewrite of our insurance system that has taken about 10 sprints( about 9 months). We have about 4 workstreams. Writing the automated tests was done throughout with a lag of about 3 weeks after dev complete of each user story and QA testing of that user story. We are now in the first stabalisation phase and the automated tests are just about done. They have exposed many issues which is proof that they are valuable, because you want to catch these things as early as possible.

We have also had some cases similar to what you mention, but they get caught early on, and can be dealt with without too much drama. :)
 
what source control do you use ?

We use Git.

Basically rebase your code with develop, test, if ok, merge.

Arent allowed to merge with develop branch until all unit and process tests are passed successfully.

Demo is always done off the develop branch which is stable(in theory :) )
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X