/home/dkramer

David Kramer's high-entropy blog

Knowledge Management Tips

I ended up talking about knowledge management quite a bit at Agile Games 2018 and Mob Programming 2018.  I don’t have a lot of formal training in this area, but it’s something that I’ve focused on a lot, and I’ve learned a lot from people who have studied it a great deal.  Rather than respond directly, I decided to add a blog post about it, to benefit more people.  This is an unordered list of these tips.  I would love to hear your additions or feedback on it.

Push vs Pull Communication Channels

There are two different general ways of communicating information: Push and Pull.  Push is when you send information out to recipients and they get notified (email, Twitter, Slack, etc) and Pull is when the recipient seeks out that information that was published earlier (Website, wiki, CMS, documentation).  Using the wrong type can prevent the recipients from having the most recent information in a timely manner.  The main deciding factor is, is it more important that people know about this information as soon as possible (changes to policy, status/availability updates, issues), or that people have the information when they need it (requirements, specifications, resources, environment details).  Many tools can do both, like wikis, which allow people to get notified of updates).  Email doesn’t work nearly as well as you would think at either push or pull, because most people in technical fields get so many emails that they find it hard to both notice and respond to timely emails and categorize those emails so they can find them later.

Lower The Barrier To Information Sharing

Creating and updating documentation is rarely the most favorite part of anyone’s job.  It’s rarely prioritized when the work is planned out, if it’s budgeted at all.  Starting to write documentation seems to be much harder than adding to it, so making it easy to get started is a big deal.  A little bit of good documentation can be a whole lot better than no documentation. There are several ways to make it easier:

  • Create a culture that values knowledge management at all levels: If the culture from the top does not value knowledge management, and time spend “not coding” is seen as wasted or overhead, then knowledge management will never get the time, resources, and attention required to do it right.  If team members know that time spent on sharing knowledge won’t be appreciated, they are less likely to focus on it.  It’s also important to convince the technical community of the benefits to them personally, like not getting stuck being “the database guy” or “the owner of the Therblug component”.
  • Create templates: You can either create generic templates for the kinds of documentation or information sharing you expect, or identify an existing one as an exemplar. “This is what a component documentation home page should look like”.   “Here is an example release communication”.  “Stories should have a format like this”.
  • Use a tool that makes it easy to iterate and easy to find information: If your way of creating documentation is to write a word document or PDF and upload it to a shared drive, it’s not very likely you’ll see a 1.1 version, let alone a 2.0 version.  In part that’s because a word document is not a very good collaboration tool, and shared drives don’t make it easy to find things.  I am a huge fan of wikis.
    • Wikis let you truly collaborate (some in real time)
    • Wikis allow endless hyperlinking, instead of forcing one path to each document like a shared drive, and dynamic links in the text to other pages and people.
    • Wikis make formatting very easy so the writer can focus more on the content
    • Wikis usually have subscriptions to topics to notify interested parties of changes and additions
    • Many wikis allow enough security that some sensitive information can be published to a limited audience
    • Many wikis are versioned, allowing everyone to see changes over time, and revert undesirable changes
    • Wikis often let you export pages as HTML, PDF, or DOC if you need to distribute the information externally
    • Creating a new page in a wiki is usually as easy as referencing the name on an existing page
    • Wikis have built in search engines
  • Maintain distribution lists: Recording the information is only half the battle. It needs to be delivered to the right people.  Relying on people to keep track of everyone in each group, and even which groups are interested in which topics, is error-prone, especially in a growing organization.  Mailing lists can be helpful, but the best tool for maintain distribution lists is something that can be used by several channels, like Active Directory/LDAP.
  • Divide up the work: Sometimes there’s only one subject matter expert in an area, but it’s often the case that different people know all, or different parts. Instead of putting the burden on just one person, you can have different people work on different parts, or have reviewers contribute to the initial effort.

Read on…

Share

Listening To Your Tools

Since I’m in Boston, we have a lot of snow to deal with this winter.  The other day I was clearing snow off my roof with a roof rake, and after about an hour for some reason it started pulling to the left when I pulled straight down.  I started to compensate by pulling the roof rake more to the right to compensate, but that didn’t really help much.  After finally getting frustrated enough to pull the roof rake down and look at it, I saw that one of the support brackets was no longer screwed to the rake, so the blade was unsupported on that side.  That’s why the rake was pulling to the left.  Had I looked at the rake as soon as I noticed the problem, I would have saved a lot of frustration, and possible permanent damage to the roof rake.  I fee we do the same thing with our software tools a lot.

Very often I’ve seen software where the usual reaction to compilation warnings is to tell the compiler to ignore them.  There are times when this is appropriate.  My favorite example of this is with Java Generics, where it’s very hard to get around some of the warnings for things that you and I know are perfectly safe.  Most of the time, though, compiler warnings are indicating a moderate to serious problem, or at least an area where the program might not be doing what you think it is.  Eliminating those warnings is an excellent collaborative activity, because we all have experience with different software issues.

So the next time you feel tempted to “ignore the Check Engine” light, spend some time finding out if there’s a more elegant solution than putting tape over it.

Share

Research Before You Buy

Geeks and non-geeks alike should do their research when buying electronic devices to make sure they can actually do what they want, and don’t have unacceptable attributes. In this post I’ll give some examples, and some helpful guidelines.

Share

Adobe Flex For Software Engineers

I have to admit when I first experienced Adobe Flex, the successor to Adobe Flash for rich internet application development, I thought it was a fragile toy that wasn’t good for much more than pretty moving pictures.  At my current day job, I had to not only learn it, but spend about half my time working in it (as opposed to my current favorite language, Java).  One thing I’ve learned from the experience is that it wasn’t so much Flex that I had a problem with, as much as Flex Developers.  The Flex developers I’ve worked with up until this job came to Flex from being Illustrators, Graphic Artists, or just kinda fell into it.  They never learned the art of software development, never learned to appreciate best practices, and never learned to value code quality or readability.  But as a long-time Software Engineer, I know you can create bad software in any language.  But now I’ve spent about 10 months working in Flex, and feel I can opine fairly. Read on…

Share

Give Me Liberty And Give Me Bugs

“Give Me Liberty And Give Me Bugs” is a quote by Martin Owens, leader of Ubuntu Massachusetts and fellow BLU (Boston Linux and UNIX Group) member.  You see, it all started innocently enough with a thread on the BLU list about the iPad.  The flames hadn’t actually reached the second floor yet, so I decided to squirt some napalm on it by mentioning that (1) I just bought an iPhone to replace my dead-end Windows Mobile phone, and (2) I have given up on trying to sync music and PDA data with Linux, and am now using an old beater Windows XP laptop just for syncing and backing up my phone.  You see, I’m a PDA geek.  I track lots of metadata about my calendar events, contact data, tasks, etc.  Since the PDA as a separate device is pretty much dead at this point (s0b) I rely on finding third party software for my phone.

But back to the argument.  There were two dominant camps.

  1. Those that see any vendor lock-in techniques, DRM, planned obsolescence, and anything that prevent you from doing whatever you want with something you own, as an affront to nature, and should be illegal.  They would rather have Open Source/unencumbered products that didn’t quite work right than locked-down commercial products that work very well, but only in the One True Way as determined by the vendor.
  2. Those that see companies as entities that will generally focus on their own goals, charging as much as they can get away with for as little as they can get away with, targeting their products towards the target audience they choose.  They feel to expect otherwise is being idealistic.  One should act accordingly, and not act shocked when Apple releases a new version five months after you buy one.

Read on…

Share

The History Of The Internet In A Nutshell

This is an awesome article.  I found the link from the Semantic Web group on LinkedIn.  I haven’t spot-checked it for accuracy, but there’s a fair amount of dispute over the history of computers and the Internet anyway.  But this article is very enjoyable, and includes many related historical points, like when certain companies formed, and the history of tangential technologies that made the Internet possible.  It’s a good read for geeks, and a great primer for geeks-in-training.

Share
Next Page »

Site info