Making hundred of cosmetic changes to the code at the last minute [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed last year.

Improve this question

A programmer keeps making cosmetic changes to the code while we have a strict deadline and the contract stipulate "no changes to the existing code". I am wondering where this "attitude" comes from: DevOps ? Agile ?

Changes performed:

1. Replacing explicit variables with "var"

2. Renaming short variable names with longer ones

3. Refactoring code injections into MVC controller classes

4. Adding design patterns (like command patttern) to existing code (with no functionality changes)

5. Adding constructors with parameters to ViewModel classes (forgetting to add a non parameter one, so the post breaks...)

Hundred and hundred of changes after tests were made, and making merging way more complicated.

Is this Agile ?

Answer 1

These things sound like general good practice being over zealously applied.

But there is a easy answer

the contract stipulate "no changes to the existing code"

There's no arguing with a contract, revert the changes and discipline the programmer.

Answer 2

Some of these changes are sensible and will reduce technical debt, but there is a time for refactoring, and if you're under pressure right now, then this is not that time.

In the light of that, it sounds like they are just procrastinating. They are trying to look busy without having to tackle any of the difficult work that needs doing.

Ask them about the value of what they're doing. If you don't get a satisfactory answer, take it to your manager.

Answer 3

I am wondering where this "attitude" comes from

Remember what Developers do.

They create software solutions essentially from nothing. Out of thin air. We don't go and chop down some trees for raw materials before we start; we just sit down and start typing (well; some do).

That's almost "God-like" and Developers just love to "think" that they are God. Heck, that's why many of us got into this Business in the first place! (And yes; there have been [numerous] times when I could count myself among their egotistical number). Even better, when an organisation starts to "do" Agile or DevOps, Management actually start telling their Developers to play God - to "self-organise" and do everything "for themselves".

Is it any wonder this attitude ensues.

However ...

the contract stipulate "no changes to the existing code".

Game over.
Take away the Developer's keyboard (or access to update the code repository).

Replacing explicit variables with "var"

Whilst Type Inference is a great tool, in a truly Polymorphic implementation, this could actually break code. You might have had a very Good Reason for using a variable of a Base Type when the method creating that object creates a subclass thereof. Blindly changing it to the base class could cause chaos.

Renaming short variable names with longer ones

The compiler doesn't care what the variables are called.

Other Developers might care what the variables are called, if there is a convention across the codebase, which these changes are breaking.

Refactoring code injections into MVC controller classes

If Dependency Injection is used across the codebase and these changes are bringing this code into line with that convention, then OK. Maybe.

If this is introducing Dependency Injection to make the Developer "look good", then No.

Adding design patterns (like command pattern) to existing code (with no functionality changes)

Patterns are there as tools to help us do our job. If the existing code is already doing that job, then these changes are pointless.

I've been writing code for decades that other people now tell me are using Patterns.
Who knew?

Adding constructors with parameters to ViewModel classes (forgetting to add a non parameter one, so the post breaks) ...

... making merging way more complicated.

And now we get to the real issue.

This Developer is changing stuff and breaking it.

Just Say No. 

If they're breaking the Build, give them the Job of fixing it. Every time.

If they're breaking the Test suite, give them the Job of fixing it. Every time.

Either the Developer doesn't don't think they have enough real, value-adding work to do or they're choosing not to do what they're supposed to be doing, but that's another story altogether.
Instead, they are occupying themselves with this "busy work" which, while keeping their timesheet nicely topped up, is causing trouble for everybody else and, ultimately, will damage the project and, potentially, your organisation.

Answer 4

There are multiple problems.

One problem is making changes at the wrong time. Usually the sequence is that you create a release candidate, it is tested, unacceptable problems are fixed very carefully and retested, and when QA finds no unacceptable problems it is released.

Making 100s of changes during testing completely messes this up. That's something that should be just obvious to any developer. These changes have less than zero value. So that's a serious problem with the developer.

The second problem is that apparently you don't do code reviews. If these changes have no value to the company, then they should be rejected at code review time. It's one thing if I do five days work and add another four hours to address comments from a code review, that's to be expected (that's what you do code reviews for). It's another thing if someone does five days work and it is all rejected. That's five days wasted. And that's something that you can rightfully blame this developer for: Wasting five days time. Without code review and rejection it's much harder to complain.

On the other hand, I wonder what this contract term "no changes in existing code" comes from. There may be a reason for this. Someone else may be developing the "existing code" and when they release a new version, all your changes would be lost. They may want for good reason all your changes to be outside their own code. In that situation, yes, you shouldn't modify any existing code. Not only because the contract says so.

If "no changes in existing code" means "we don't want to pay for unnecessary work", then there are plenty of situations where modifying existing code is less work all in all. Which would be obvious to any developer and maybe not obvious at all to a non-developer. (On the other hand, this guys changes do not seem to fall into that category at all).