If this is tl;dr, scroll down to "The Question"

Why this is not a duplicate:

The linked question talks about version control (which I have), a one step build script (which I have) and to "have an issue tracker at all" (which I have, but I'm having trouble optimizing), none of the answers to that question answer any of my questions.

This question is not about "minimum subset", it is about practical issues in a specific real world situation.


I am the sole developer at my company, which is only 5 people. Only one of my coworkers has any development experience, and he is not working on any of the production code. He is my boss, but he doesn't have any interest in the details in specific issues. My job is honestly more of a side project of one of the partners (my boss's boss), the company already makes money from things that have nothing to do with me. He is reluctant to give me more resources until I can prove that this project has viability; once I do, he plans to give me a lot more resources, but until then this is my situation.

The issue:

As a result, I am finding it challenging to use my project management platform (currently Redmine). I think that if there were more programmers or even testers, it would be a great communication tool. However, because I am doing 100% of the development work and 95% of the testing, it just seems like a massive time sink to keep the cases up to date, and sometimes even to create them!

Most of the time, when I find a bug, I just fix it immediately. The only time it ever makes it into the issue tracker is if it's not something I can fix and test in less than half an hour.

As the only programmer, there is no code review. No one who works here is interested in using my redmine server; I'm lucky if I get a bug report via email, usually they just walk over to my desk and tell me - and even that is rare. I have tried to get my boss to use the server by making him watcher of many of the cases, and having it email him when I make changes, but he hasn't even logged onto it in the last 3.5 months.

Before I was using redmine, I was using Wunderlist - and honestly that seemed to be a much better fit. It was definitely inferior from a features standpoint, but it did the job - I could make notes of things much more quickly.

Note: I am comfortable with my version control routines, most of the time; this is much more about issue tracking and communication with the non-developers.

The Question:

I would appreciate input on any of these questions:

  • As a lone programmer, do you prefer a full featured issue tracker like redmine or a simpler personal organization system like Wunderlist or Evernote? -- If you use redmine or similar, do you use most of the features?
  • Any tips for getting YOUR BOSS who has had zero interest in using an issue tracker in the past to start using it?
  • When testing existing code (assume code that was not written with TDD), if you find a bug, in what situations to you add the issue to the issue tracker?
  • Any other advice that seems relevant for me.
  • 1
    In a similar situation, I document everything in OneNote and use it as checkboxes. I have things categorized into "makes sense" categories. The trick her is you HAVE to be very diligent in documenting enough of "what is the problem, how to replicate it" information which is more part of formalized systems. My coworkers are similar in that they won't use any system and hardly even email me things. I've begun tracking everything I fix, even the "easy fixes" - this helps me get a feel for what I've worked on, etc.
    – enderland
    Mar 6, 2014 at 14:50
  • The tool is always subordinate to the discipline of using it. Mar 6, 2014 at 19:52
  • I'd say it's worth having so that in x months time when someone asks what you've been doing with your time you can say THIS and produce a list of all the changes you've put in / work you've done. Mar 6, 2014 at 21:01
  • Take a look at asitrack.com. I'm a solo programmer too and it's what I use. I prefer an issue tracker as opposed to something like Evernote because it keeps things serious and professional. If I used notes or lists of tasks it would be on paper notebook, not on an online service. It's not like anybody will read the notes in the future anyway.
    – user23272
    Mar 17, 2014 at 11:19

4 Answers 4


I say it depends. If you are working on a small project which is indented to stay small, you might be good with a task list. I use Wunderlist for some stuff. Typical projects are things like creating blog systems which follow a "do this from a to z" approach.

For projects of which I think (or hope) they become big I use an issue manager or Kanban styled board.

While I was using Atlassians Jira a lot in the past I found it was totally overblown even when I use it with my team of 5 people. I think such systems are good when you are working at an enterprise level as you have many options to customize, but not for small and agile teams.

Today I use Trello.com for task oriented things, even for issues. This works pretty well in my current super agile team. While Redmine allows you to assign release versions, we have decided to make multiple releases a day and that feature would just be "too much". Instead we move cards as we go and are very happy with it.

The tool needs to serve you and not vice versa. From what I read from your post you definitely should use something easy, also please look into Trello.com (very easy, free to use and bit better for overseeing tasks).

Your Boss: tell him you need to organize your work, otherwise this will cost him a lot of money/time if don't. In example, if you have list of tasks you can focus. If you don't have that you need to think every day for approx 30 minutes what needs to be done. Money is usually what convinces most bosses.

Creating issues: If you see a bug (say a typo) i fix it straightaway. If I see a bug I cannot fix right now, I am creating an issue. If the bug is not done with a simple fix or changes the systems behavior significantly I create an issue too. The reason is I want to have it documented. Personally I am doing it agile, and you should do so to save time as long as you don't need to document every step to do.

Other tipps? Simply try whats best for you and what keeps your focused on your tasks. There are a lot of issue trackers and they promise you heaven. But most of them have a problem: they often have so much features that they eat up a lot of time too. My vision is to have a took which supports me without ever thinking about it. As mentioned, my combination of Trello and Wunderlist works well.


I depend heavily on my issue tracker, to stop people coming in and taking 10 minutes to explain a problem to me, which, when I have time to do something about it, I will have forgotten completely.

By making them write it down, they can compose what they want to say, and the result tends to be more concise. It gives me all the outstanding problems in one place. It also means that I can easily annotate the issue with my thoughts/progress.

It sounds like your main problem is with getting it set up. You may be able to do this in stages:

   Stage 1. When your boss comes in, wait for them to explain the problem, taking notes (on computer, if you can). At the end, ask your boss to send you a reminder email so it doesn't get lost in the shuffle.

   Stage 2. Once your boss is used to sending you reminder emails, ask them to put a summary in the email.

   Stage 3. get them to put the entire problem in an email, after they have explained it to you

   Stage 4. get them to put the entire problem in an email, as soon as they start explaining the problem.

   Stage 5. Get them to put the entire problem in the bugtracker.

Make sure there is as little resistance for them as possible. If you can, get a bugtracker that doesn't have any required fields, and doesn't need a log in; just one edit box to put the problem. If they can email a specific address to add a bug, even better!

If you can get to stage 2, you can cut & paste the email into the bugtracker.

  • Of course I agree, but I can't make anyone do anything, I'm the "junior" guy who puts a red number on the accounting ledger (my salary)
    – durron597
    Mar 6, 2014 at 19:59
  • After your comment, I updated my answer; starting from paragraph 3. Mar 6, 2014 at 20:11

By the sounds of it the tool isn't working for you. Your boss isn't using it so all you're doing is spending valuable time feeding it data. So why not park it and use something else? Having used Trello myself like Christian, I too fully endorse it. It is all online and you can even use it on your smartphone. It doesn't require you to fill in massive amount of meaningless data either - you just enter what you need to and it is done.

Your task as I see it is to build interest in and be an evangelist for the project you're developing. OK, you're finding and fixing issues but why should your boss care about this?

Don't tell your local pedant, but TDD can be retrofitted to a completed/partially developed project. You just write a suite of tests and off you go. Sure it isn't as useful this way, but there is still definitely value to be had.

As for what to track - if it is a typo or something is not quite in the right place on screen, I'd be inclined just to attend to these. Similarly, if they're issues that only you yourself have found that can simply be fixed, then do so. Track anything that is more involved. As a rule of thumb - if your boss asked you for a demo now, what issues would you feel it was important to mention?

  • My boss does care about the project, he's the one designing it. He just has a very lackadaisical style, he takes notes in a notebook that I never get to see, and then doesn't give me information in a useful or timely way. Trying to get him to scrum has failed miserably. He cares about the parts that he's directly responsible for and wants me to be totally autonomous about my parts.
    – durron597
    Mar 6, 2014 at 15:29
  • That is somewhat unfortunate but not unusual. If your boss is sure his half is well polished then great, but ideally you'd want quality feedback on all of it.
    – Robbie Dee
    Mar 6, 2014 at 17:02
  • lol, sometimes he wants quality feedback from me but most of the time he really only cares about quality feedback from HIS boss. Programming is a lot easier when it doesn't matter how maintainable the code is, or how fast it runs, because you have someone else to clean it up later - which means the production version is always running behind design.
    – durron597
    Mar 6, 2014 at 17:13
  • Flying solo has certain advantages but if you cut too many corners you'll also be the one who has to pick up the pieces
    – Robbie Dee
    Mar 6, 2014 at 21:16

The issue seems to be that the issue tracker is not part of your workflow. If it was, then you would be required to use it to get any work done.

IMO a good goal would be to just isolate a small issues or feature, enter one in your tracker, then create a matching branch. I disagree with the previous answer in that I don't mind having issues for everything: typos, language changes, etc... If it takes a while to create that issue, then improve the workflow so that it takes less time to create issues.

The benefit isn't just having an issue tracker, it's in how you use the tracker to improve the project's direction and workflow.

Sometimes I would type out an issue and think "This sounds like too large of a task, am i really going to work on this? Maybe I should break this up into smaller tasks" or "My description barely makes any sense, maybe I should research this and see if this is worth coding". It also allows you to review and evaluate your own progress.

Many people won't care, but it's more for you and your future team than for your boss. Your boss just needs to know that it's a part of developing software, like the patient file folder you see at the doctor's office.

Some examples of issue tracker integration:

hubot and redmine

Sub and Jira

  • I think before I can begin branching that extensively, I need to migrate from svn to git ;)
    – durron597
    Mar 6, 2014 at 19:36

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