4

Say you have a project that is a tangled mess. No code structure and breaking one area breaks the entire thing. Fixing one area breaks another area. The closest you can fix things is writing the code that's almost like redoing the entire thing. But then, the release is in the next week.

Here's some facts that actually worsen the situation:

  • There's very minimal testing. Makes breaking hard to find.
  • The code has no structure. Imagine one app has everything in one file.
  • No documentation. Very hard to replicate server requests when there's no documentation about the parameters to send, and what to expect.

What should one do to address this situation? The best thing to do is extend the project release, but I'm not the one who calls the shots. I did comment on the issue though.

Improve this question
4
  • Update your resume.
    – Telastyn
    May 12, 2014 at 1:32
  • 1
    Also, see http://programmers.stackexchange.com/questions/178352/how-do-you-balance-between-do-it-right-and-do-it-asap-in-your-daily-work.
    – Telastyn
    May 12, 2014 at 1:34
  • 2
    @Chris - Sure, but this isn't one big obvious problem. This is a series of systemic problems brought about by a bad organization and furthered by a development team without any pride in their work. I've spent many years of my life working to fix such organizations. And I did learn a lot. I learned that a lone software engineer cannot change a culture where dozens of people are against you (and wield the authority).
    – Telastyn
    May 28, 2014 at 20:07
  • @Chris - really? Sure, he doesn't know if the new company will do better, but he knows that this one is screwed. Not spending half your waking hours surrounded by suckiness seems like an advantage to me.
    – Telastyn
    May 29, 2014 at 3:09

1 Answer 1

Reset to default
9

Sometimes the best thing to do is do nothing.

Leave the refactoring until after the release. A week away from release, your number one priority should be finalising the current build. The only code changes should really be bugfixes.

Don't extend the release. Unreleased software doesn't sell.

Do schedule time specifically to address technical debt AFTER the release.

Do break down the technical debt into work items. This way you will get specific flaws in the code structure addressed.

Do set a time limit for addressing technical debt. Version 2 needs to be developed and good software probably won't hit its strides financially until around version 5.

The thing about software development is that imperfect software makes money. Infinitely more money than unreleased software. The purpose of software is to solve the customer's problems. The purpose is not to have a beautifully engineered masterpiece.

In summary, release the software on schedule and allocate time to fix the worst technical debt problems.

Improve this answer
1
  • 1
    +1 but do make sure you really are 1 week from release. Sometimes the schedule says you are 1 week from release but actually you have a long way to go yet, with many bugs to fix.
    – MarkJ
    May 12, 2014 at 7:22

Your Answer

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

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