As a prospective intern, how do I evaluate how easy it would be for me to improve a team's practices?

Question

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?

Answer 1

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:

DON'T

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.

DO

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.

Answer 2

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.

Answer 3

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.