Stack Overflow for Teams

Stackoverflow launches StackOverflow for Teams. Stack Overflow for Teams offers a number of useful features:

  • Unlimited private questions and answers: Team members can ask as many questions as they need, and unlike monolithic internal wikis, they can expect relevant answers from team members to their specific questions.

  • Intuitive archiving feature: Tags allow users to sort through questions and answers by topic in order to dig deeper into a subject of interest. When an answer to a given question populates, the user will also see related questions and answers that could prove useful.

  • Member profiles: The Teams platform showcases each user’s specific skill set and the topics about which they frequently answer questions, so team members know whom to consult within their organization if they need further insight.

  • Seamless integration into the workflow: Stack Overflow for Teams is on, already a popular daily destination for developers. Furthermore, Teams integrates with existing tools like Slack, so Q&A fits easily into a team’s existing workflow and communication processes.

It seems like "one more tool to try to offset the problem of requirements, code, and architectural decisions not being adequately documented for future staff to understand." I always wonder if software teams should add technical writers embed with developers, architects, QA, and BA assets to actually document EVRYTHING and keep documentation up to date. It will mean re-writing documentations as people change their minds in response to business needs but it would provide an historical record that answers "How the hell did our systems end up looking like this?" which seems to plague every organization that hires programmers to write custom code. Sometimes it's hard to give the developers who wrote the code the benefit of the doubt that they made the wisest decision based on all known variables at the time. I'm certainly guilty of questioning the intelligence, breeding, motivations, etc of the programmer of an app I had to modify once, only to realize that I had developed the code in question five years previously. Eventually I remembered why the feature had to be coded that way and wrote a 666 word comment section explaining why the feature was written the way it was and how one should orient their state of mind to understand and edit the logic. And I further apologized for the mess of code that the feature was and left my personal phone number in case a future software developer wanted to berate me for it. And four years later I got a call from someone saying they had been laughing for 15 minutes because they had gone from "WTF?" to gradual understanding as they read through my verbose description of why. Whether that dev updated the comments to reflect their changes is something to which I have no answer.

Over the years working in software development I’ve concluded, reluctantly, that the ONLY documentation solutions that matter are the code, revision control logs and issue trackers. Create massive comment blocks to explain things if you have to but put it all there in the code, next to the things that matter. Then it has half a chance of still being accurate. And, you know exactly where the documentation is. If the code becomes obsolete and is removed, you naturally strip out documentation that is no longer relevant at the same time.

Revision control log messages are important. I so hate lazy messages; if you change 15 files in random ways and your message is “fixed bug”, I think you should be fired. If it’s in the issue tracker, your log had better mention the number. Add a paragraph daring to explain what the hell you did so I can read a sensible log history and figure out what happened when.

Issue trackers are useful for capturing every relevant detail, especially new information that is found while the bug is being investigated. The bug might come up again, and details can help to sort it out.

I'm not sure if it's worth it, but this struck a chord with me: No more digging through stale wikis.

No comments: