Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question already has an answer here:

My manager has tight deadlines to meet.

The current project I am working on is currently on schedule, but I've noticed a couple of quite significant areas in the code that are really badly written. (Bits of code get called two or three times, when they only need to be called once.)

The problem is, as far as my manager is concerned, the program works. As he sees it, there's no point making lengthy changes to code that will make us miss the release date, for no tangible improvement that he can see. He keeps saying "That's not a priority. It's working fine as it is."

Should I keep trying to persuade him, or should I just do what he suggests and leave it? Why or why not? Note that how to persuade management has already been covered.

share|improve this question

marked as duplicate by maple_shaft Feb 25 '13 at 16:11

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

18  
I tend to agree with your manager that you should not touch working code in the last few weeks (4 to 6 weeks) before the release, unless you have to fix some important bugs. On the other hand, I would schedule your refactoring at the beginning of the next development cycle (for the next release). –  Giorgio Feb 25 '13 at 10:08
5  
1  
I changed the close reason to Duplicate. IMO the question is essentially the same, as lack of code cleanup is just a type of technical debt, and any argument to convince of code cleanup would be framed around the argument of technical debt. If you disagree or would like to discuss further then please start a discussion in Meta. Thank you –  maple_shaft Feb 25 '13 at 16:15
2  
@Giorgio release vs maintenance / cleanup is a false dilemma, thoroughly covered in Advanced SCM Branching Strategies article by Stephen Vance, see considerations on the release (packaging) role. "Using a separate branch to insulate the release effort from the ongoing development and maintenance, and vice versa, is recommended..." –  gnat Feb 25 '13 at 16:36
1  
Urbycoz - if you are interested in the "how" then this has been answered in the duplicate. If you are interested in the "should" then this is a different question, but probably not constructive/not a real question in Stack Exchange terms. –  ChrisF Feb 25 '13 at 16:43

8 Answers 8

up vote 14 down vote accepted

he's the boss, it's his decision. And I agree with him. NEVER change code for the sake of changing it. If there is a valid reason for the change (say things perform below requirements as they are) things should change, but "I think it's not pretty enough" is not a valid reason.
Your religious zeal (and that's what it is at this stage, or appears to be) would cost money, introduce risk (every code change risks breaking the product, requiring more changes, more testing, more delays). That's never a good thing.
Instead make notes, and pick up those changes when and if the affected parts of the application need to change anyway.

share|improve this answer
1  
That's fair enough. I guess I'm worried since the problem may grow and cause bigger problems in the future. It's not causing any visible issues now, but who's to say what will happen later on. –  Urbycoz Feb 25 '13 at 10:01
8  
"It's not causing any visible issues now, but who's to say what will happen later on.": This is very true: closing your eyes too often on many small issue can end up in a big mountain that eventually cannot be ignored. So code clean up is very good, but it should be done after a release (preparation for the next release) not before. –  Giorgio Feb 25 '13 at 10:14
5  
I fail to see any religious zeal in the question. –  COME FROM Feb 25 '13 at 10:52
9  
@jwenting I still fail to any kind of religious behavior here. He's asking a question, not ranting. He has chosen not to bother the manager at this point, but to ask advice from other programmers. That's wise. There's nothing wrong with caring about code quality. –  COME FROM Feb 25 '13 at 11:12
1  
@Giorgio: If you wait to make changes until you are working on the code which needs changes but you do make changes at that point, it should prevent such issues from growing much...assuming your code is well-encapsulated. –  Brian Feb 25 '13 at 14:01

No, you shouldn't. Deadlines are more important than tidying code, because you probably have no idea why the deadline was set in the first place. Maybe you have to finish before your competitor, who would steal your customers. Or some laws are coming into force. Or it's just getting too expensive for your starving CIO. Or...

If you think releasing it would be a great risk, then explain it to your manager. Valid reasons are: customer data could be lost, the company's reputation will suffer or something else what would have a negative impact on the company. But your manager has to ponder risks and opportunities, and he has to decide if it's worth to move the deadline.

But ask your manager to schedule some extra ressources next time, so that the software won't become a big, unmaintainable monolith. Then your manager can keep his deadline and you will have enough time to create a fine piece of software.

Whatever you do, please don't give managers a reason to think of programmers as people in ivory-towers who don't know anything about business.


Update because I read that it is a newly-written application:

Your first priority should be to do a root cause analysis to find out why that bad code was written in the first place. Did requirements change? Is one of the programmers not skilled enough? Does the deadline provoke a send-and-forget attitude?

share|improve this answer

My manager has tight deadlines to meet.

Most do.

The current project I am working on is currently on schedule

Good. Keep it that way!

I've noticed a couple of quite significant areas in the code that are really badly written. (Bits of code get called two or three times, when they only need to be called once.)

If that's not a major correctness or performance problem then it doesn't sound that bad. Calling the same code twice unnecessarily is often better than calling it once and caching the result. I've seen lots of bugs due to faulty caching logic. But let's take your word for it that this is bad code.

The problem is, as far as my manager is concerned, the program works. As he sees it, there's no point making lengthy changes to code that will make us miss the release date, for no tangible improvement that he can see. He keeps saying "That's not a priority. It's working fine as it is."

Your manager is correct. You're in the business of delivering value to stakeholders, not in the code prettification business. If you can't make an argument that making the code prettier delivers more value to stakeholders than hitting the release date then don't make the argument.

Should I keep trying to persuade him?

No.

Should I just do what he suggests and leave it?

No.

You should rather attempt to convince your management to schedule a "code quality milestone" after the deadline has been met. When your deadlines have been met and you're planning the next version the first thing you should do is schedule a post-release analysis that goes over in detail what went well and what went poorly. That includes analyzing risks to future success, risks such as poor quality code that was checked in with known problems in order to meet a deadline. Use the time put aside for the "quality milestone" to mitigate those risks. It will help if you can arrive in that meeting with an accurate list of problems you'd like to address.

The argument to make there is that by doing so, you help ensure that your manager will continue to meet deadlines in the future.

share|improve this answer

Problems in code can create impractical timelines for maintenance in the future, especially if the problems aren't properly documented with comments in the code.

Most managers have enough of a technical understanding to allow them to perform their job, but they won't know how to code, nor with they understand how problems can impact timelines in the future.

I would approach your manager in writing and outline to them what can (and likely will) happen down the road by allowing the issues to remain untouched and unresolved. This can include timelines that will be affected when modifying it in the future for updates, poor performance of the application (resulting in poor user satisfaction), etc. When they understand the impact of the problems and make their decision, accept it and move on. At this point you will have done your job as a credible and reliable programmer (with written proof that you have), and now the ball is in their court for taking responsibility for any problems associated with the issue that you have outlined.

share|improve this answer

It's your job to point these things out, but still the manager's decision.

However, you should try to make changes to you development process to avoid these problems in the future.

  1. Identify the repeated problems and train the all developers on a prefered method. Everyone isn't going to get this right the first time, so be prepared to catch them in a code review. This way, you can take the time to make the change before a manager knows the code is working well enough/goes on to further testing.
  2. Start factoring #1 into your estimates. Your team will improve over time, but you better manage expectations upfront.

Hopefully your deadlines were established based on how long the develpers thought it would take to build and not some other arbitrary method. Some developers feel like they're the bearer of bad news if they make lengthy project estimates, so they avoid it by being overly optimistic.

share|improve this answer

This is subjective question, and here is my viewpoint.

YOU SHOULD try to persuade him. Fact that you wrote this question here answers that. How hard you should try is different question..

Think about different parts of system:

  • How far into development of that module you are?
  • How likely is that same module will be significantly changed in future (spec. changes).
  • Is public interface of module changing?

Just ask yourself those questions and make your own pros/cons.

For example if module is almost finished and likely to be changed after release, I just leave refactoring for later. But if it is in early stage, and specifications are not likely to change, refactor ASAP. Because specs WILL change, and after not looking at messy code in two years you will have hard time implementing new spec. changes. It might be so bad that you decide to write module from scratch,and just use some parts of code from earlier version of module.

There are some trick that can convince manager to let you refactor.

  • Find a bug in existing code. You can spend time refactoring while fixing bug.
share|improve this answer

Here's some points:

  1. Every change causes more errors. Modifying complex code causes more errors than it can ever fix. Ideally you would write it once and never modify it. Adding new code is ok, but changing existing logic causes more errors. If the end result is a mess the first time you wrote it, think how bad it'll be if you modify it without remembering all the rules that gave you the original mess.
  2. Complex code always looks bad. The code is complicated for a reason. It encodes the important business logic, and that is always complex. All complex code looks like a mess to people who do not know the rules the code follows. Once the rules are known, it's nice logical system that just works correctly. You'll forget the rules (or worst, someone else wrote the code and you never had the rules), and you'll start thinking the important business logic is a mess. Cleaning up such code is a big mistake.
  3. Over time, business rules gets outdated. Now you have a huge mess, and half the rules encoded to your software are outdated. Is it already time to rewrite? Definitely NOT. Only way to get rid of business rules that are already encoded to software source code is by dumping the whole system. Otherwise you'll end up with cascade failures where one missing piece of software activates failures in unrelated code that has worked fine for last 10 years.
  4. Maintainance is difficult activity. Maintaining the mess takes skill. You need to know to all the business rules collected in last 10 years to make any modifications. Forget one of them and your change is causing more damage than it is fixing. Good plan is to insert new logic, but never modify old logic. Refactoring or rewriting is wrong way to approach the problem. You need to start writing working code, and never never rely on chance to fix it later; the chance will never appear. Once it's encoded to code, it's like concrete; it's always there and breaking it is dangerous.
share|improve this answer
1  
I do not completely agree with 2: making the code look simple is the task of design. But, of course, often there is not enough time to produce a good design and if a piece of code is messy, I agree that trying to fix it can produce more bugs than it fixes. Regarding 3 and 4: a design approach consists in making business rules replaceable (if possible). So, instead of modifying existing code, you remove an old implementation and plug in a new one. Of course, this requires a good design and sometimes requirements change so fast that it is difficult to keep up and keep the design clean. –  Giorgio Feb 25 '13 at 12:12
    
giorgio: Creating good design does not really take too much time. You just follow existing architecture, and make your new code work well with the existing system. Design is not limited by the amount of time. Complexity of the result code cannot be simpler than the actual complexity of the requirements. –  tp1 Feb 25 '13 at 12:24
    
I agree with you that design cannot reduce the complexity of a system as a whole, but it can reduce the complexity of individual components or abstraction layers. That's why, e.g. it is easier to program in a high-level language than in assembly: the complexity is not reduced but hidden from the programmer of a higher abstraction layer. Programming languages are designed for that: hiding complexity. You can do the same when designing an application: build API's and abstraction layers that hide complexity. But yes, you are right that the complexity is still there. –  Giorgio Feb 25 '13 at 13:14
2  
I agree with Giorgio. It seems like with the people I work with/have worked with there are certain people who tend to always create complex monstrosities and blame it on the difficulty of their problem. Then there are others who take on the most complex tasks and always seem to make them simple and easy to understand. IOW, I believe that the quality of a developer can be determined by the complexity of their design/code. And I totally disagree with the statement that creating good design does not take much time. Good design is hard, but makes implementation very easy when done right. –  Dunk Feb 25 '13 at 21:59
    
If it feels like someone is creating simple solutions from complex requirements, you're just not counting all the necessary complexity. Calculate all of it, and problem is solved. Worst situation is that the solution will fail half the time because it's too simple and does not handle all necessary cases. –  tp1 Feb 28 '13 at 11:22

Many managers don't understand the concept of "technical debt" which is exactly what you are trying to stop from building up.

The manager is correct when taken in the context of just this section you would like to fix, but this really becomes an issue when many sections degrade over time, and other developers come in and build on top of it.

Then a bug is discovered in part of the code, but only gets fixed in one section, not in the copy and pasted sections.

While you have not went live yet, there are other things that you need to keep in mind that the manage is probably thinking about.

Maybe this code rework will mean that a large testing phase needs to be repeated. There is also the possibility that you will introduce bugs into a previously working feature.

share|improve this answer
1  
and many programmers don't understand the concepts of functionality complete, good enough, budgets, shipment deadlines, etc. –  jwenting Feb 25 '13 at 15:03
2  
most programmers are well aware of these issues, but they can also see the "technical debt" iceberg coming too :) –  jmo21 Feb 25 '13 at 15:16

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