I've been offered a summer software development internship on a close-knit team of four people. It looks good, except for some very troubling development practices. These include:

  1. No version control!
  2. No documentation or comments!
  3. No bug tracker!

The team said that this "worked for them." And, in fairness, they did seem productive and their software did seem functional. I gently asked if they would be willing to adopt Git. The manager seemed amenable to the idea, but the developers' reactions were more neutral. (And talk is cheap, anyway.)

I'm willing to walk away from the offer if these practices turn out to be unshakeable. On the other hand, I might give it a shot and take it upon myself to introduce the team to better practices, if that looks feasible. But that all depends on my completely inexperienced assessment of their malleability. So:

Before I'm even hired, how do I best estimate how responsive a team will be to my attempts to change their habits? Is it appropriate to simply ask flat-out? If so, is there a way of phrasing the question to encourage more honest, realistic, thoughtful answers?

  • 4
    this might be an interesting read : joelonsoftware.com/2001/12/25/… – everyone May 4 '18 at 7:50
  • 1
    I wasn't trying to state that this was the absolute truth, just that it seemed related to your situation and a worthwhile use of your time. If I had a better idea of how to handle your situation, I would have written an answer... unfortunately I'm no expert in the topic... – everyone May 4 '18 at 8:05
  • 2
    This isn't the question you asked, so I'm offering it as a comment. I really recommend looking for a different internship. An internship should really emphasize your continuing education, not you teaching your sponsor. The lack of version control is a giant red flag. They may have cobbled together a system that works for them, but it's not likely to be a process you'll be able to leverage anywhere else. In future interviews when you talk about this internship they may ask "So what version control methodology did you use?" The are at least going to quirk an eyebrow if you say "None!". – Charles E. Grant May 4 '18 at 21:27
  • 1
    @Maxpm it's a risk-reward trade off. If you can tell an interviewer that you successfully introduced version control and other standard software development practices into an organization, that would be really impressive. On the other hand, if all you can say is "Well I tried to get them to use version control, but they were stubborn and wouldn't listen to me.", well that won't impress anyone, and they might even become skeptical of the value of the internship, since it was apparently was with an organization far out of step with current practice. – Charles E. Grant May 4 '18 at 23:37
  • 2
    If the company's setup is this poor, and you're applying for an internship I'd look for another company. If their practices are known, it will look bad on your resume. And lets face it, if they're that screwed up you're unlikely to learn a lot there. An internship isn't a time when you're trying to improve things, its a time where you're trying to improve your own knowledge. – Gabe Sechan May 6 '18 at 7:39

Before I'm even hired, how do I best estimate how responsive a team will be to my attempts to change their habits? Is it appropriate to simply ask flat-out? If so, is there a way of phrasing the question to encourage more honest, realistic, thoughtful answers?

The short answer is that there isn't really a way of doing this that is even half-way reliable. The best way of assessing this is through experience, which you don't have (and why you are asking this question in the first place) but that doesn't mean there isn't anything you can do:


Ask flat out - You risk placing them on the defensive (with the implied critiscm of their current working practices) and coming across as arrogant. Even if that's not how they take it and they say all thr right things as you say "talk is cheap", saying all the right things even if backed by all the best of intentions doesn't mean that actions will follow.


Ask them what they think are their current problems in their development process - if they list anything that can be solved by implementing git or any of the other practices you would like to put in place then you can use that as an in to suggest it. It is by no means a certainty that they will follow through on this but it's about as good an indicator as you are going to get.

As a general rule of thumb it is bad business practice to go around changing processes without a pretty good idea of what sort of improvements you are going to see from it. Changing processes almost always results in a short term drop in productivity, even if all the implementation work were done completely by yourself there is going to be a period of adjustment for incumbent team who are used to working the way are at the moment, this means they will be spending time getting used to the new process (time which they would otherwise have spent being "productive"), any new process will also likely result in an increase in the error rate in the short term because people who are unfamiliar with a process are more likely to get it wrong and then there is more time lost while the mistake is corrected. So this means that unless you can identify a specific problem that their current proceesses are causing them and that is impacting them regularly then you're unlikely to get anywhere, no matter what they say.

Another good rule of thumb in business (and believe me I'm not trying to sound harsh when I say this) is that you gon't generally make significant changes to your business processes purely on the advice of inexperienced interns so I would say that if you are going to have a hope in hell of getting any of these changes through you are going to need the support of one or more of the existing development team - and to be frank it doesn't sound like you have it. Had one or more of the existing team responded to your git question with something like

God yes.. implementing git would be great it would make my life so much easier!

then that would have been encouraging because if the manager is worth his wages before he implements any of your proposals he'll consult with his existing team to see if this intern they barely know has any idea of what they are talking about and any less than enthusiastic response is likely to kill that idea right there.


Work the way that you want to work, as long as that doesn't negatively impact on your team's productivity. Of course, do this with the team lead's permission.

Doing it this way means that you're not aggressively imposing working practices on the team and it's up to them to look at what you're doing and incorporating any good points that they see (or discard them as they see fit).

Note that well written code doesn't necessarily need comments all over the place (I don't know what this code is like, so this might be subjective). Create your own documentation and submit it with your work. For a bug-tracker, I'd just use a spreadsheet to start with and encourage people to look at it to track your progress on bugs. People may buy in and add bugs to the spreadsheet if you guide them (but don't force the issue).

No one likes a new guy being pushy, but it's good to see good practices demonstrated, and they're easier to adopt if they demonstrably help your own productivity.

  • This is good advice, but I don't want to end up as the only person following good practices. My question asks how to tell if that's going to be the case before I accept the offer. – Maxpm May 4 '18 at 8:46
  • I'm not sure that you'd be able to enforce better working practices as a condition of you joining the team. This sounds like what you're trying to do here. It might be better to join and then work from within. You might have to suck up some bad practices in the short term, but as an intern it'll be good to have actual experience of bad as well as good. – user44108 May 4 '18 at 8:49
  • @Maxpm Part of your role as an intern is to experience what the real world is like, which includes learning how to do a good job in the real world's less-than-ideal conditions. That doesn't mean you can't give the people you're working with food for thought, but it's not reasonable to expect that you're going to walk in there and move mountains unless they've specifically told you that's what they're expecting. If you don't think the position is right for you as it exists, don't take it. – Blrfl May 4 '18 at 13:19

It is 2018, and they are not using any source code control system. My memory may not go back quite far enough, but I used source code control (SCCS at the time) in 1996. They are 22 years behind. I'm sorry to say this, but you don't have the slightest chance to change what they are doing.

  • I was using SCCS for version control in i984 and it was written well before that. They're at least 34 year behind. – Charles E. Grant May 4 '18 at 21:32
  • In 1984 I created a floppy disk with the source code once a week and kept them all :-( Boxes full of floppy disks. You could call it source code control. – gnasher729 May 5 '18 at 13:49

You must log in to answer this question.

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