44

I'm currently preparing to leave my company and writing extended documentation on the system for an eventual successor. An important note: I was the sole developer on the whole project for the last three years and did everything from planning, testing, distribution, etc. by myself. So nobody else has any idea what and how things work. I am/was also the only developer in the company. I also don't have to be careful about hinting I'm leaving, as I already technically left and am working on a dynamic contract until everything is resolved or a certain amount of time passed.

Currently the main thing my supervisor wants is a documentation on how to keep the installer up to date with projects from other parties, no problems. I have been using Git for my work there for the last three years. How can I properly encourage whoever is working on the project to continue to use Git to document their changes?

I'm not asking how to force them (I know I can't), but I want to illustrate the eventual consequences of not doing so, and hopefully that will at least give them a proper and realistic view of the advantages and disadvantages so that they may choose to use Git. Of course the documentation would include a chapter on how to use Git in conjunction with an easy-to-use client and leave out anything too advanced (branches, merging) and focus just on doing commits and pushes for the sake of the successor and as a fail-safe.

But I don't really know how to motivate a non-developer. My supervisor is additionally the CEO of the company, so arguments to avoid huge future investments should also be fine.

Update (1 year later): after my break from work I ended up at the same company. So the rules where definitely a big plus for me starting again. Especially since no one dared to change anything without a developer in the company.

  • Apart from forcing them to do so, what makes you concerned that the steps you have mentioned won't be enough? Also, if you're the sole developer writing up this process, why can't you make it part of the standard process? – user34587 Sep 10 '18 at 8:36
  • Currently the chapter on git isn't written yet, so I'm currently looking for what to write there to give a practical motivation. Making git part of the standard workflow was also my idea but as it does not contribute to a successful installer it might get skipped - thats what I want to motivate against. But maybe I'm overthinking this, that is also a possibility. – CShark Sep 10 '18 at 8:38
  • 3
    Related, possible duplicate: Convince the Company I Work for to Implement Version Control? – David K Sep 10 '18 at 13:21
  • 5
    Why git in particular, rather than one of the dozens of other version control systems? – jamesqf Sep 11 '18 at 5:21
  • 3
    @jamesqf Because it is what I chose to use the last three years. My successor is of course free to change everything, but until then it is easier to just continue using it. – CShark Sep 11 '18 at 8:37
146

In a situation like yours, a good starting point is to present the current use of Git as the rule.

Add simple instructions like

  • Where do I get the current code? Check out the Git repository XYZ.
  • How do I make modifications to the code? Use development environment ABC, modify code and commit changes to Git repository XYZ

Include Git into the written rules and guidelines and present it as a natural and ingrained tool in the development process. Adding a list of advantages of Git and worst case scenarios if it isn't used may help to create the illusion that you simply cannot work on this project without using Git.

That has the following effects:

  • An inexperienced developer or general IT person without knowledge about software development will take those rules as written and adhere to them (provided that they find and read the rules).
  • A new employee will probably take over the existing development process at first and introduce changes gradually if they see any problems with the process.
  • An experienced developer knows about the importance of version control and will either keep working with Git or replace it with another solution.
  • 77
    +1 Even better if there's a CI / build pipeline system in place. Then that becomes the path of least resistance, and you can trust human laziness to take over :) – rath Sep 10 '18 at 10:42
  • 7
    Uh, It never occured to me that I could just use a buildbot which directly works on the git repo to force the use of git... I think I will go with that and make it part of the workflow :) – CShark Sep 10 '18 at 10:59
  • 9
    @rath I can personally confirm that this doesn't always work. I was in the same situation a while ago, and when they took over the software they immediately ignored the clearly documented build process and just did production modifications (it was php, so they'd just edit files in the web root). Sadly, you can only do so much before you just need to wash your hands and walk on. If the person who replaces you is smart enough, they will use it. If they aren't, they won't. – Shadow Sep 11 '18 at 6:48
  • 3
    @Shadow You can lead a horse to water... – rath Sep 11 '18 at 8:53
  • 2
    @CShark never underestimate how much work people will go though to avoid learning a new technology! – corsiKa Sep 11 '18 at 15:08
72

Let me preface this by saying I understand your concern and where you're coming from. I would have a similar reaction. To answer your question, you don't. It's not your job any more.

The new developer will be the sole owner of the product just like you were, and will use whatever tools they deem necessary. What you can do is present your boss with a list of requirements for the role, or even offer to conduct the interviews yourself. This makes sense as you're the only one in a position to do so.

  • @Walfrat My answer is try to hire the guy or set out the role requirements. I believe this covers the requirement; regardless, it's not going to be OP's project any more, so I don't see how else to influence that policy. – rath Sep 10 '18 at 8:50
  • 33
    This. Choosing what tools the company uses after you've left is frankly none of your business. Documenting what you've used and why it was great is your role now. Perhaps that'll lead to continued adoption, perhaps it won't .. but that's the extent of your responsibility and remit. Don't distract/add noise to your documentation by adding personal religious beliefs ;) – Lightness Races in Orbit Sep 10 '18 at 13:40
  • 4
    Well, they want to update their installer with software that is not developed by them directly. So they need a way to update the installer easily and build/deploy it. And as the company is a very small and family-like one (quite literally) it is no option to just tell them "hire someone who will do it" or leave them completely hanging. At least for me, that is. So that's why I'm looking to give them an easy tooling that will keep the benefits of using git regularly. – CShark Sep 10 '18 at 19:16
  • 3
    @Wildcard You misunderstand me. I never said you shouldn't document - on the contrary, of course you should. The OP is asking how to ensure his process will be followed by his successor. My point is your duties stop there. If the successor wants to use SVN, or no source control at all, that's on his head. That's why I suggested the OP should conduct the interview. – rath Sep 10 '18 at 22:09
  • 2
    @rath actually slightly different: what my capable successor does is none of my business, so far I agree. The problem is, they don't have one yet. And I want to "encourage" the "uneducated" personal that is working on the projects on the meanwhile for minor adjustments to leave a good basis for the next person. – CShark Sep 11 '18 at 8:42
3

There are two sides to the Git coin. You should cover both.

The first is that it is a DVCS, which means that you (the dev) no longer need permissions to record anything into your repository - control has been distributed to the dev. It is easy and fast to essentially keep notes and to be able to return to any point in your/their rolling development (especially with the fast and easy branch capability). I presume you use some form of triangular flow to distinguish current dev work from approved production / secured work. Having the rolling record will save a lot of grief.

Git also separates out the authorisation and verification aspects to a distinctly separate management role for the acceptance of the work into (typically) the master branch (whether merge or fast forwarded). Historically, on centralised tools, the dev was not allowed to completely commit work until it had gone through many hoops making most devs avoid the configuration tool (which was wrong, but understandable). So now you get the best of both worlds.

The second, flip side, is that Git from the command line can be a real pain with lots of inconsistencies between options and special options to remember. This is ok for some, but others will be happier with the git-gui and gitk tools which provide an alternative graphical interface for those who prefer. Be positive about there being a range of Git tooling options to suit all pockets and mind sets. It (Git) is a great tool but beware of other bad CM habits and misunderstandings based on historic tools.

Remember that historic software configuration management (CM) was based on drawing office practice from before the building of the Titanic - the 'master' drawing had to be protected at all costs, without it there was no ship, no product. Now we have perfect replication, but need verification that the copy we have is absolutely the authorised traceable version (e.g. 1d4361b0f344188ab5eec6dcea01f61a3a3a1670 v2.19.0, just now)

-2

Why do you care? What benefit is there to them doing something you want them to do after you leave? Why are you forcing them to use your chosen tools when you are no longer associated with the company?

You say you were the only developer, what if your replacement is more experienced than you and thinks everything you implemented is crap? Why make it more work for him to have to tear up more of your chosen crap?

Although the real answer is: who doesn't use git in 2018? M$ even owns them.

  • 10
    Did I miss anything? I though MS bought GitHub - not necessarily Git? – Patrick Gregorio Sep 11 '18 at 14:18
  • 1
    this reads more like a rant, see How to Answer – gnat Sep 12 '18 at 10:13
  • I don't use Git and it's 2019. :P – Cypher Aug 13 at 20:08
-4

On some days you made changes, which look good first (they compile) but terrible later on. When you notice such mistakes, you can roll out the better-working old code in an instant, or invest work hours into finding and undoing your changes -> while others have to work with software which doesn't work as intended. Both cost money, while a commit is done within a second and costs nothing.

Another advantage of an repository is that you can check it out easily on different computers. This argument is probably small, since other people in your company probably won't have a git client, as non-developers (I am using it for LaTeX in a non-developing sense too.)

That's why I am using repositories even for my private stuff, not to mention that you need one when your successor isn't a single person.

I guess even a non-developing supervisor knows the importance of change logs and a repository is a powerful change log.

  • 6
    This is more commentary than a real answer. Please see How to Answer and take our tour to improve your answer. – Burgi Sep 10 '18 at 15:46

protected by Community Sep 10 '18 at 22:05

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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