About a month ago I started developing a program in Java for one of my coworkers. I am the only one working at this and this is my first serious project (meaning that it will be used by someone, not done just for fun or at school).

My coworker is taking information about the program from another person outside of the company (Let's call him Bob) and passing them to me (Bob will be the one who uses the product, so I am actually creating the program for him), which creates some misunderstandings sometimes, but nothing too big, everything is absolutely fixable.

The problem is that sometimes he tells me to implement some features for which I need to change a lot of lines of code. At the beginning, when I wrote about 100 lines, it was not a big deal, but now it's definitely time and effort consuming (seen as I am at about 500 lines and at this point I need to change about 60 and add about another 500). I know that if he was clear from the start (and maybe arranged a meeting with Bob) there would have been no problem.

My question is: should I tell him about this, and get a better and finite idea of what I have to do before I start working again?

Things to consider:

  • The deadline is in about 2 and a half months, therefore time is not an issue.
  • I am in a internship. Therefore, if I were to fail at implementing some features, my coworker would add them by himself with basically zero consequences.
  • Are you doing this on company time? Does the company know you are developing a tool for someone outside the company? There's a huge difference between developing a program for your co-worker vs someone outside the company. – cdkMoose Oct 12 '17 at 13:11
  • 3
    While an agile does help you to stay flexible, it is no magic bullet for bad planning/information! – Daniel Oct 12 '17 at 16:23
  • 1
    Wouldn't that question be more suitable for "software engineering" community ? – Laurent S. Oct 12 '17 at 20:30

Yes, you should absolute try to get the best information you can, as soon as you can, whenever you start developing something. Also, if you have any obstacles you feel are impairing your productiveness, you should seek to remedy that. It is a sign of professionalism to seek help, if you can´t help yourself!

There is a saying in the programming world:
Weeks of programming can save you hours of planning!

So this is quite common. It is also common that you are not able to get all the info and have to start with something. But trying the best you can and discussing this with your coworker is definitely in order!


There is no such thing as perfect requirements. They change in all projects as things progress. There will always be a need to rework things that were finished. This is part of the profession and you should get used to it.

Requirements will also often come through a filter of one or, more often, more people as developers are not generally allowed to talk directly to the people creating the requirements especially not junior developers.

However, you can minimize changes through good requirements and through pushing back rather than making assumptions when you don't fully understand a requirement.

This is one reason why it is critical to start building a good understanding of the business domain you are working in. It will help you identify when there is something missing from or wrong in the project requirements. The more you can identify as needing clarification before you start coding, the faster the coding will go and the fewer things will need rework (but never none because some users are not good at visualizing the results and won't know something doesn't work for them until they see it).

What you should do with every requirement you get is to look for holes in it. Are there places where there are decision points but they only told you what to do for one possible path? Are there places where you are not clear what is meant? What assumptions are you making? Clear any assumptions as being correct before you start coding.

Are there things that are missing such as a description of what reporting needs to happen after the data is placed in the database or a description of what data security needs to be in place if you are putting personal data into a database. Did they mention the performance levels needed.

Does the requirement use words you are not familiar with (look them up first)? If the definition doesn't make sense in context ask for clarification. Often there are business domain specific words and they may have unspoken meanings to everyone familiar with the domain. By asking what they meant, you may find out some things that they assumed everyone knew. Most of the worst disconnects in requirements that I have seen come down to the user making assumptions about things that "everyone" knows but the developer did not know.

  • Another kick butt post. Your first paragraph is on point big time. – Neo Oct 13 '17 at 16:06

You can propose to your coworker to include you in his interaction with Bob related to the software, either CC'ing you in the email exchanges or inviting you to the meetings. Keep in mind that there might be a reason why he is not doing this so let your coworker know that by doing this you could avoid misinterpretations regarding Bob's requirements.


You should definitely always ask for as much information as possible on the requirements. Even arrange a meeting with your co-worker and Bob for once a week or every two weeks to get direct information and demo the current product!

One thin I would suggest looking into is Clean Code by Robert C Martin. If you have extracted your functionality into different classes and methods then instead of changing 60 lines of code, you will only need to change a few at a time. As a developer I would suggest staying away from one class that has 500 lines, try to keep classes doing only one thing, that will limit your lines to under 200 for example.

Not the answer you're looking for? Browse other questions tagged .