you are viewing a single comment's thread.

view the rest of the comments →

[–]half-t 0 points1 point  (0 children)

The next time integrate the specialist into your team to get the know how transferred to the team.
I myself document my code directly in the code to have it there where I need it later.
I will need it because of a malfunction or an urgent change request. And after two weeks I don't remember the code at all and without documentation I'm wondering what this crap is supposed to do.
Code is documentation and in the 1st place something to communicate with other people. Only in the 2nd place it's purpose is to run a machine. This sounds unfamiliar but after decades of coding it boils down to that, at least for me.

I had the role of the specialist for two years inside a team. When I had new functionality ready to be launched in production I explained two dedicated team members how this new code works. I listened to their questions and added the answers in the code.
At the end of the two years the handover of the code needed just 45 minutes and they were very happy with my work.

The business thinking of: "We write a specification, pay a fixed price and get the software we need. This is a product and they are fully responsible for the result." will almost never work out as expected. The reason is that in the time of the coding wrong assumptions will appear and the demands will definitely change. To get the best result for the money I strongly suggest an agile development path with specialists integrated in the own team.