0

I'm currently working on a project where I inherited a product somebody else made halfway-through. My job is to finish that specific project. I was told I had a free hand over what to do, so I looked at the source code and decided it's rubbish and I started all-over again.

Within two weeks, I had a working prototype when my boss saw what I did and was very disappointed because I changed the overall-design of the page without asking (as I said, I had free hands there). But well, from this embarrasement, I stepped back to the original source code.

The thing is that it's really bad and unstable. It's copied together from many different websites without sources etc. and whenever I try to fix one bug, twenty others emerge that were dependent on that one bug I fixed.

There's practically no documentation (a txt-file with a list of packages to be installed) and now it already took about half a year (it should have been finished after maximally three months).

I believe in this case it's not my fault not to be able to work with that source code since every time I questioned the person working on it previously, she didn't have any exact answers and just told me to keep googling and playing around until I get what I want. But I'm feeling very ashamed in front of my boss (who's a really nice person, but also wants that project to be finished).

What can I do now? Restart all over? (If not, is it the concorde-fallacy?) Explain why such a badly written product is not usable or able to be developed further?

I don't want to look incompetent and I don't want the previous employee to stand in a bad light as he was a really nice and fun person to be around with. But her code was just terrible.

How to handle this, preferably in a way that doesn't get me fired?

|improve this question
  • Just say the source code as it stands is unstable and you believe the best approach is to start fresh and use the example of breaking 20 other items by changing one. – Dan Jan 30 '18 at 17:49
  • 3
    "was very disappointed because I changed the overall-design of the page" — So your boss was only looking at the output of the source code? Why would you need to go back to the original bad code to get the same output? – jwodder Jan 30 '18 at 18:01
  • 1
    This is something that will happen for any developer at sometime in their career. In your case couldn't you keep the same front-end (HTML, etc.) and re-engineer the back-end to something more supportable? – JazzmanJim Jan 30 '18 at 18:12
  • 5
    I think your boss made their expectation pretty clear: don't mess with the code without asking. The code belongs to the company and not to you. Also, this might come as a surprise to you, but software developers all over the world routinely inherit "bad" code, but they don't just throw away everything and build it from scratch. If you want to "improve" the code, work out a plan with the boss and do it in steps. – Masked Man Jan 30 '18 at 18:27
  • If you are using your real name here, you may want to consider using an alias instead. This stack is easily searchable. – Mister Positive♦ Jan 30 '18 at 18:48
5

I looked at the source code and decided it's rubbish and I started all-over again.

This was where you went wrong, as shown by what happened next:

Within two weeks, I had a working prototype when my boss saw what I did and was very disappointed because I changed the overall-design of the page without asking.

You can't just throw bad code away and start over whenever you find it - working with bad code is a necessary skill to develop.

I'm pretty sure that most people working in this industry for any length of time will have inherited "bad" code - it's just a fact of life! It's natural to just want to start on your own terms, but throwing it out and starting all over, especially without authorisation, is not the way to go.

Different people will have different ways of dealing with bad code - but mine is to take the time to thoroughly examine the existing codebase, making sure I at least understand how it works on a fundamental level (or how it doesn't!) From that point, I'll document everything that I've found that I think needs to be changed or fixed, and work out approximate estimates of how long it'll take. (And this is all before changing anything.)

If you document things as above, you can then take a much more concrete document to management, and have a much more constructive conversation over what needs changing and why.

|improve this answer
4

Don't restart, refactor. Pick a bit that looks wrong and fix it, without actually altering what it's supposed to do.

Then pick another bit, and fix that. Fix the documentation a bit at a time as well.

Eventually you will end up with something that's not perfect, but is good enough. It will do what the original was supposed to do. And after all the refactoring, you should have a good understanding of how it all works.

|improve this answer
2

Within two weeks

You worked for two weeks without letting your boss know that you were rewriting the whole project. I'm sure if you let your boss know what your plans were, and why you were doing it from the start, it would have gone more smoothly.

You used the word design, but was it the output of the program that changed and the boss got upset? If so, would this be solved by matching the output with the new program? Was it the design of the code itself? If so, either you need to speak with your boss and convince them why the new design is better, or you need to go back to the old code and fix it to where it is usable.

|improve this answer

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