4

I work at a larger startup with a maturing codebase. I've only worked here a few months. I have few issues to work on currently because we are near a release. I don't have many assigned issues / bugs compared to other developers who are polishing new features, and adding regress tests. I am not really sure what to work on, but I know there is plenty to do. It is tough to find motivation as well since the work tends to be more tedious (QA).

I inherited part of the product that was poorly written- a C++ developers first foray into HTML / JS, and its my main focus here. I know all code has its issues but this code genuinely needs a rewrite (it's about 20,000 lines of javascript, lots of copy and pasted code, poor naming & magic numbers [var obj = ev.Items;, doGetStuff(), meths[method][6], etc], mostly static methods with no object reuse, no separation of UI and business logic) The UI is really bad as well, I could go on with more examples but I just want to stress the code is objectively bad, not just messy or needing slight refactoring. However, because we are near a release and the code is somewhat stable at this point, nothing should be changed that may impact the release. Ideally they just want the code to have more unit tests, testing, documentation, etc.

Since it's mostly javascript that's tightly coupled to ASP.NET code behind pages, it's is extremely difficult to unit test. In addition, there's no spec so it's hard to know if the code is even working right (there are very complex business rules.) So I'm not sure how valuable unit tests would be even if I got them up and running, which would be difficult itself.

What would look best for me to work on, so that I could seem more like a go-getter, self starter that actually does useful things in this situation? I worry that I will look lazy if I'm not actively producing anything- whether it be code, documentation, or tests. I could try to optimize, bug-fix it without breaking anything- which is risky and doesn't provide much benefit, or test the code more manually (which is probably the best thing to do, but doesn't really give me any recognition from my peers and is unfortunately very boring.) I would like to rework some of the UI and refactor but I can't do that close to a release. I'm really struggling to figure out what is the best thing to do to seem positive and hard working, and to find motivation. Any ideas on how I can be more productive?

closed as off-topic by gnat, maple_shaft Oct 31 '16 at 19:42

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions seeking career or education advice are off topic here. They are only meaningful to the asker and do not generate lasting value for the broader community. Furthermore, in most cases, any answer is going to be a subjective opinion that may not take into account all the nuances of a (your) particular circumstance." – gnat, maple_shaft
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 8
    never, ever rewrite - refactor! – user1249 May 24 '11 at 20:08
  • yea i should probably rephrase that. i generally will figure out what small bit i can rewrite / refactor, complete that, get it working again, and then repeat that over and over until it's all cleaned up – Shawn May 24 '11 at 20:14
  • what does your boss measure when deciding how "productive" you are? – user1249 May 24 '11 at 20:24
  • i havent worked here that long, and i dont have too much direct supervision. im guessing it will just be based off what my project leads / coworkers think of me, and how much stuff i've broken. they seem to generally like me though. – Shawn May 24 '11 at 21:03
  • 1
    Considered asking your boss? – user1249 May 26 '11 at 14:39
9

If you want to go big, (ask to) branch your part of the project and work on cleaning it up. Once the release date comes and goes, merge it back into the main branch. This keeps the release version static and lets you work on what's needed.

Otherwise, doc and test it like they want. As you're going through it, make note of what all you're going to want to fix in the next version. Yeah, it's not exactly glorious, but you're new, so it would do you good to go over the code some more.

  • 2
    +1: Branching is the standard way to let developers work on new or potentially-destabilizing code while allowing the release codeline to remain stable. – Bob Murphy May 24 '11 at 20:53
  • 6
    +1: The easiest way to make your coworkers hate you is to, as a new guy, come in and tell them that it's all wrong. Mostly people know this. The wrong has come about as the project has evolved into its current form, and most of them will have their eye on things that they KNOW need to be changed. Rubbing their noses in it will not be productive. – Satanicpuppy May 24 '11 at 21:40
3

Figure out a way to automatically test this stuff. That will be the most valuable in the long run (is there a long run?). Then start building tests. If the code is too tightly coupled to be testable, work on decoupling some of it so you can test it. The best thing you can do right now is come up with a process for dealing with the mess, and then start applying the process.

[added]

Go read Michael Feather's Working Effectively with Legacy Code

  • i think this is the best solution, hard to figure out how to make it testable though – Shawn May 25 '11 at 22:13
1

I think that the best thing to do would be to make your manager or coworkers aware of how the code is tightly coupled and tedious to work with. They might already be aware of this which might be why they gave it to the new guy...

If you can come up with a plan to refactor bits and make improvements here and there, run it past your manager briefly to see what they think. That way at least they know what you want to do and why you want to do it. Plus you won't look like you're wasting time all day if there is little visible progress.

Just make sure you're not coming off as whining or bashing on the previous developer since that might not go over so well.

-1

I find one thing people forget is the cost of having lots of features. Each line of code adds weight to the project, making it less agile and harder to maintain. Maybe you could go through it with a project manager feature by feature, ranking each feature by importance and then figuring what you can cut out. If you could cut the code size down by 50% I bet you would decrease the time till release by a lot more than 50%.

-1

Looks like I slightly late, but I'm sure, good answer for good question, will not late :)

So, you have large chunk of code, and you have to maintain this code (fix bugs) and you have to enhance this code (add new features), and this code is not well written.

First, I prefer to think, this is some sort of challenge, and this point change all things - troubles become tests, how much I strong and creative, in this war against complexity.

Second, I use best techniques and skills to solve my task:

  • Sure I'm strong in algorithms and data structures (Knuth).
  • Strategically, I use best techniques and technologies to manage complexity - by dividing project to loosely coupled parts (OOP patterns, lambda, good concurrency templates, administrative privileges - mean the best if all functions will be done by separate non-administrative login)
  • Tactically, I create documentation of project (maps, diagrams, even just serviette style). Then I use TDD/BDD, first to create/check my understanding of structure of project and second to tightly bind parts of code to my map of project, and than I constantly spend significant working time to refactor or even rewrite code, so code will become modular and structured.
  • And don't forget to take some rest - talk/walk with girls, view cinema, football, etc ;)
  • 2
    Please do not answer questions that are on hold. – Jan Doggen Nov 1 '16 at 7:51

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