53

About 8 months ago I began working on a project for a colleague (part of my job is to do side projects like this). Essentially developing an excel application for a very large database we have.

At the beginning I was excited about the project with the programming and GUI creation but the project began growing and becoming more complicated. This happened due to my inexperience in managing projects (first job out of school).

I let the project get to the point where I became depressed at work. Just the thought of having to work on it caused serious dread and my productivity at work declined greatly. Finally, about 2 months ago, I just stopped working on it completely. I told the colleague I am in the debugging phase (which is essentially true but there is A LOT of debugging to do) and I would schedule a follow up meeting when I've made substantial progress.

My happiness and productivity at work have greatly improved since putting this project out of sight and out of mind but it has come time I actually finish it up.

The state of the project is a mess. My code is a mess and I have numerous functions and subs that I've scratched but kept for reference so knowing which ones are used and aren't is proving difficult. I do have plenty of comments throughout the code but I can't seem to even get myself in the head space to take the time to understand my code and comments.

I'm at a loss on how to re-approach the project. I don't have a mentor or really anyone in my department that works on any kind of software development for me to turn to.

How do I approach my coworker about this? I believe she was planning on presenting this at a company-wide meeting in a couple weeks but I just don't see that happening (I could get it into a beta phase to show but not disperse but it needs to be dispersed within a reasonable time after the meeting of course).

Update: Just met with my coworker and very matter-of-factly outlined what was working with little to no bugs, what was in a buggy phase, and what was just a mess. We discussed which features/functions of the application need to be done for a beta and out of those which are priorities. Most of the stuff that is a mess is more admin stuff that only she will use so we agreed on putting this off until the end-user functions are working.

Thank you for the answers and advice. I really appreciate this community and all it has to offer.

  • Not an answer to your question, but in future I would recommend building up automated tests as you go along. They don't have to exercise scrap of code you have, but the pass-fail ratio for tests of your main functionality is a good indicator of when you need to stop, refactor, locate errors, rethink, etc. so you can avoid needing to solve many problems at once, which it sounds like you're doing now. – SeldomNeedy Jul 25 '17 at 19:05
  • just a related piece of advice, i would recommend sketching out each module with a diagram (plenty of those online) and even creating supporting video tutorials for each module (and be okey with the fact that these videos will be out of date next time you code something) this way you can very easily get back into the large body of code while having a coffee and looking at the screen. Just do a screen capture and talk through the code. It's awkward in the beginning but a life saver when you have to review something you wrote a few weeks before. – Robert Sinclair Jul 25 '17 at 19:36
  • 14
    Just play it forward... the project isn't done because the scope blew up, because the scope blew up, the code needs refactoring, the code needs to be refactored to complete the project. My advice is never to admit wrongdoing, that's just not good in business culture for many reasons, obfuscate and make excuses, learn from your boss ;) Sounds terrible I know, but being able to handle negative situations with higher ups is a skill everybody above you has, so might as well start working on it now. – RandomUs1r Jul 25 '17 at 19:36
  • 2
    (a) Learn a version control system. I don't care which. (b) You as developer need to decide how to solve the problem you are faced with. Get data from your users, not proposed solutions that you then attempt to implement without your own consideration. – Wildcard Jul 26 '17 at 4:01
  • 1
    @Wildcard is right, take that advice! "I have numerous functions and subs that I've scratched but kept for reference so knowing which ones are used and aren't is proving difficult." --> version control allows you to delete currently unused stuff, but keeps it available if needed at some later time – Daniel Jour Jul 26 '17 at 17:29
33

How do I approach my coworker about this?

If you, with your knowledge and experience in the project, believe it is not possible to finish it on time you should have a follow-up meeting ASAP, to make sure you will not affect in a negative way your colleague's possible meeting, and with that your professional reputation. Be clear and honest with her; the Beta phase seems to be a good approach at this moment. Be sure to have a good outline of what steps to take to achieve that beta phase ready to show her when meeting up.

...any advice on steps to take to clean up my code and make the project not so intimidating to jump back into?

You can always be certain you will find help in StackExchange, mostly in your case on Stack Overflow and for improvements of code you could also try on Code Review.

When going over your project do so in an orderly fashion: Go one module at a time, debug it (also focus on one bug at a time), test it and carry on with the next module. Sometimes having a piece of paper helps greatly to note things down to debug faster. If you can, using an Integrated Development Environment (IDE) greatly helps when programming, as they come with several tools to aid you and most importantly a debugger tool.

It sure can be overwhelming and stressful to go back on old code and comments, but make sure you take it with calm; it is usually more harmful to do things in a hurry than taking some more time to do them right.

Note: In future occasions, if you feel less motivated with a project you are working on do speak out earlier! It is no good for you to let work mess with your happiness and mood. Personally I have been there, with projects that sometimes turn really difficult and seem almost impossible, and it is not difficult to fall into a vortex of despair.

When I find myself in this situation I speak out immediately (in your case with your coworker or someone you trust) to prevent this from turning into a worse problem in the long run.

  • 8
    And prioritize the work, do the most critical features first. – HLGEM Jul 25 '17 at 17:24
  • 4
    +1 I scheduled a meeting with her this afternoon to discuss the status. Really appreciate your advice on going through the code. Just started one module and one function at a time and it's feeling less overwhelming. – cheshire Jul 25 '17 at 17:29
  • 2
    That is the way to go @cheshire , as a programmer I find taking things one module at a time makes them more manageable and less overwhelming. It also reduces the amount and severity of bugs, as you notice them earlier and have time to remove them before you begin to stack error over error. Wish you luck and also good vibes. – DarkCygnus Jul 25 '17 at 17:31
  • 1
    @cheshire Though this may not be the right place to say this, if I were developing in Excel again I would at least try out Rubberduck It's an open source project trying to add lots of features to VBA's VBE. – Daniel Jul 25 '17 at 18:59
  • 1
    "it is s̶o̶m̶e̶t̶i̶m̶e̶s usually more harmful to do things in a hurry than taking some more time to do them right" – jpmc26 Jul 26 '17 at 3:33
40

Struggling to finish project, how to tell coworker?

At this point you need to be open and honest about the status of the project. Honesty and transparency are usually your best ally when it comes to a project's status. ( Just tell the co-worker as soon as possible )

You have made a mistake in not disclosing the status of the project, but one that I think you can recover from by being honest about it. Show your co-worker where the project is at and ask for the best way to proceed.

In the future, as soon as you are struggling with a project, let whoever is in charge of the project know so they can plan accordingly and have whoever is in charge prioritize what they want to see finished first.

Free advice about development: Be sure you break a task or feature down such that you can complete each small part in a 2 or 3 week time frame. This will allow you to see much earlier on if your project is in trouble.

Best of luck to you.

  • 3
    +1 I agree, I was planning on going down the honesty road. I think when I was actively working on it, I didn't really realize what a mess it had become (it was organized chaos in my head at the time). And thanks for the development advice! Need to work on breaking it down for sure. – cheshire Jul 25 '17 at 17:12
5

You should approach your lead/manager with honesty and explain to her what you have accomplished in the last 8 months. Don't mention the lag that you had and you stopped working on it. Since it's a side project; most of these have a priority of "low" and should only be worked on during your free time.

When you are presenting your project, I would suggest that you approach it with the following goal(putting the critical functionality on top of your mind):

  1. Overall vision of this excel application - Explain your requirements and what you understood where this app should go.
  2. Challenges you faced up to today
  3. How you solved your challenges
  4. Challenges you haven't solved and need help / direction on
  5. Challenges you haven't solved but know what to do
  6. Bugs
  7. Future outlook of the project
  8. Any other underlying concerns

I think if you approach your project in a sensible way your manager would understand your point of view. She may set new expectations and or give you a new vision on the project. Open and honest communication goes a long way.

  • Thanks for the tag suggestion (was actually going to encourage users to add tags, wasn't sure what to put). You offer great advice on how to discuss the project +1 – cheshire Jul 25 '17 at 17:31
2

While I agree with the other answers that in general honesty is the best approach, I cannot recommend it blindly without knowing the circumstances. Do you trust your coworker or will he try to harm you with this information?

Nevertheless you should never lie about the state of your project but you do not have to present your work in a very negative way. You said nobody in your department can mentor you, therefore I guess you are the sole software developer. So nobody can actually tell if the software you have developed is good or bad.

I would go forward the following way: prepare a minimal prototype for demonstration. It should fulfill the basic requirements, not necessarily for every input. At the presentation, be open that you have run into architectural problems and need more time and training. But nevertheless present the work you have done and the effort you have given this project!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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