Building Recommended Software Practices

  • Comments posted to this topic are about the item Building Recommended Software Practices

  • Steve, good question and thank you for those 7 points that organizations should consider when building out good software engineering practices.

    I would like to address the first of those 7 points. I realize that isn't answering your question, so please forgive me for diverting from your question. I think of myself as being pretty good at DevOps, at least at a theoretical level, as we don't practice DevOps where I work. But the concept of keeping documentation on a project within its code repo is very foreign to me, even at this stage. I've spent several years writing documentation using MS Word or Vizio and so have all of my colleagues everywhere I've worked. Where I currently work there's always an associated SharePoint site for every project. (Well, I admit that associated SharePoint site isn't being created at the same time a new project gets created, but nevertheless there are at least 80 projects with a SharePoint site associated with them.) I can see the thinking behind putting documentation, probably written in Markdown, into the code repo. I especially see this on GitHub, not so much on Azure DevOps, although it is there, too. My boss loves to get into TOAD to generate database diagrams, tables, views and stored procedures, then save all of those files in the SharePoint site. I can guarantee that is not going to change, ever.

    I'm not saying you're wrong, Steve. I'm saying that its highly unlikely that the people I work with are ever going to change their practices.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • Rod at work wrote:

    Steve, good question and thank you for those 7 points that organizations should consider when building out good software engineering practices.

    I would like to address the first of those 7 points. I realize that isn't answering your question, so please forgive me for diverting from your question. I think of myself as being pretty good at DevOps, at least at a theoretical level, as we don't practice DevOps where I work. But the concept of keeping documentation on a project within its code repo is very foreign to me, even at this stage. I've spent several years writing documentation using MS Word or Vizio and so have all of my colleagues everywhere I've worked. Where I currently work there's always an associated SharePoint site for every project. (Well, I admit that associated SharePoint site isn't being created at the same time a new project gets created, but nevertheless there are at least 80 projects with a SharePoint site associated with them.) I can see the thinking behind putting documentation, probably written in Markdown, into the code repo. I especially see this on GitHub, not so much on Azure DevOps, although it is there, too. My boss loves to get into TOAD to generate database diagrams, tables, views and stored procedures, then save all of those files in the SharePoint site. I can guarantee that is not going to change, ever.

    I'm not saying you're wrong, Steve. I'm saying that its highly unlikely that the people I work with are ever going to change their practices.

    It's not that you have to adopt these practices, but my point is that you ought to have a set of principles you follow. I find many groups, especially in enterprises, where there just aren't consistent practices.

    These are one person's recommendations, and I agree with some of them. The are better than using something like Word, though using Word and keeping the Word doc in the repo aren't mutually exclusive things.

  • True. At least here we put documentation into SharePoint sites. At my previous job we'd put it here, there, and everywhere. Which really doesn't lead to any consistency.

    Kindest Regards, Rod Connect with me on LinkedIn.

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply