Not another banjo joke!

What has sixteen legs and three teeth? The front row in a banjo workshop. Mommy, I want to grow up and be a banjo player! Now honey, you know you can't do both. The jokes that come out of our work, whatever it is that we do, can reflect real points of frustration built into the structure of that work. Let's look at technology assistance: there are well-known jokes about the difficulties that occur in IT consulting that have been posted over and over again on the net for years. In the requirements analysis area there is the oft-repeated parody of The Night before Christmas that ends: And the user replied with a snarl and a taunt Its just what I asked for, but not what I want. In the domain of the "help desk" there is the famous problem submission form that begins. 1. Describe the problem. 2. Now describe the problem accurately. 3. Speculate wildly about the cause of the problem. These jokes would not show up over and over again if they did not reflect a problem built into the way we do work. I fretted about these jokes for a while until it began to resonate for me: Each of these pieces describes a situation where the technologist is habitually dissappointed by the quality of information he feels he is getting from his users. The consultant feels he could do his job beautifully, if only the user gave him better information. But since this problem occurs so often, we have to assume the problem is somehow created by the way the work is done - it can't be that users in general just don't know how to communicate. (Unless, of course, they are all banjo players) After all, we are all users. The technologist is looking at communication between the user group and the technology group as being made up of information flows in two directions: if you could just manage to tell me what the problem is, I might be able to tell you how to fix it. The user sees it exactly the same way. I will tell you what I need, and then you can tell me what to do. Maybe this concept is the source of the frustration - instead of two disjunct information streams, perhaps we need a single collaborative knowledge support effort here. Knowledge Management is often looked at as a an effort lying snugly within the organizations' boundaries. But at least three of the most critical tasks in IT consulting - trouble resolution, requirements analysis, and training - explicitly involve collaborative use of knowledge by the users and the technology assistants. These groups may be within the same organization, or in different companies. But we need to envision a shared knowledge support infrastructure that crosses the boundary between techies and users if we want to improve these fundemental IT interactions. p.s. only a few more days to see Picturing the Banjo at the Corcoran Gallery! Tags: nptech, km, IT_consulting

Using our heads

In a couple of posts a few weeks ago, I warned that information that is just in people's heads and not shared organizationally cannot be considered organizational knowledge, and suggested the reuse of routine communications as a path to capturing this knowledge in a way that does not create endless new documentation tasks. But Sharon Richardson in a thought-provoking post on her Joining Dots blog proposes that the emphasis on documents of any sort is a very limited view of knowledge management. ...I think Knowledge Management should be replaced with Knowledge Support. The phrase Knowledge Management just naturally lends itself to managing something tangible and that means documents - but stuff in documents is really just information, it requires a person to use it as knowledge....Knowledge Support shifts the focus to people and the application of knowledge. The "stuff in documents," Sharon suggests, is just one leg of a triad that comprises organizational knowledge - the other two are the "stuff in heads" and the "stuff in databases". And its the actual investment in people that she sees as the neglected component of knowledge management. She doesn't offer specific examples of this type of investment - but I found myself thinking of the Pair Programming model popularized by the Extreme Programming methodology, also known as XP. In this approach, all coding of software is done by two programmers working together. Despite the initial perception that this method will double the number of person-hours for each task, pair programming has been seen to generate better-designed and less buggy software, with only a slight increase in the number of person-hours involved. So here is an approach that increases sharing and immediate application of knowledge directly between heads without any intervening documentation process. Often, in organizations where time is scarce and money even more so, investing in knowledge application this way seems an unjustifiable waste. But pair programming has been shown to be quite cost effective. This is an example from software development, but maybe there are investments like this in other domains that all of our organizations could be making in order to leverage our human knowledge better. Tags: nptech, km, extreme_programing, pair_programming

The "neigh"sayers take the floor again

So let's beat that dead horse one more time... because Jeffrey Zeldman said it so well in his A List Apart blog last month. You know which dead horse I mean - is Web 2.0 some exciting new wave non-profits need to catch, or is it just a bunch of marketing hype? That old debate. Zeldman's posting comes down right where I am. Of course technology is developing rapidly and there are new tools and techniques you'd be a fool not to explore -- in fact there are quite a few I will urge you to take a look at. But the fact that a product is built using a tool that has been associated with the web 2.0 phenomenon means absolutely nothing about that product's usefulness or value. The fact that it is "collaborative" or "read-write" means nothing unless it is adding real functionality you and your users did not have before. Zeldman wields a full dose of sarcasm and hyperbole in this article- but he says it with absolute clarity when he writes: Consider this scenario: Steven, a young web wiz, has just celebrated his bar mitzvah. He received a dozen gifts and must write a dozen thank-you notes. Being webbish, he creates an on-line “Thank-You Note Generator.” Steven shows the site to his friends, who show it to their friends, and soon the site is getting traffic from recipients of all sorts of gifts, not just bar mitzvah stuff. If Steven created the site with CGI and Perl and used tables for layout, this is the story of a boy who made a website for his own amusement, perhaps gaining social points in the process.... But if Steven used AJAX and Ruby on Rails, Yahoo will pay millions and Tim O’Reilly will beg him to keynote. Now, this doesn't mean you should sit smugly with your static website you had a consultant build for you in FrontPage three years ago. It just means to avoid the hype as you look at the new web technology - and keep your focus on how each tool might further your mission by improving communication with your community. Tags: nptech, web2.0

Yahoo Javascript Libraries go OpenSource

Many of us were digusted earlier this month to learn that once again Yahoo had cooperated with the Chinese authorities' request to turn over a citizen's private records, this time the discussion group threads of 35 year-old Li Zhi. The information was used to stick the dissident and former civil servant with an eight-year sentence on the charge of inciting subversion. The news, coupled with Google's capitulation to Chinese censorship, reached a boil on Capitol Hill yesterday, where the House dealt the firms a stinging rebuke for these practices, which lawmakers called "disgusting" and "abhorrent". I can't help wonder if this mounting bad PR played a role in Yahoo's announcement this week to release their Javascript user-interface library and a library of web application design patterns under an Open Source license. It's certainly big news. I just checked back to where I bookmarked the Yahoo announcement a couple of days ago in del.icio.us; at the moment 2888 other people have also bookmarked it. And its not just making waves among industry pundits following Yahoo's twists and turns - it's big news for developers who want to use new approaches to web applications - like Ajax - without spending - or charging - a fortune to build or buy code to do it. I can tell you the developers at my joint are eager to get a look at it. And the developer blogosphere is buzzing with the news. The libraries include tools for animation, DOM manipulation (the key to dynamic HTML), drag and drop, and httpXMLRequests (the heart of Ajax). In addition, calendar and treeview components are provided. The library is all cross-browser tested - a "graded browser" policy described in the documentation that lays out the Yahoo definition of "multi-browser support." As one blogger sums it up: I'm sure that this is probably a lot to do with...generating goodwill; but also hope that it will reduce duplication of effort and poor practices, and speed up the development process. The design patterns all have accessibility sections - which is great to see. Tags: yahoo, web2.0, webdev

Borland plans to spin off Delphi

It's the end of an era. And the beginning of another. Borland Software Corporation announced a couple days ago that it is spinning off its programming languages division into a separate company and seeking a buyer for it. These languages include Delphi, C++ Builder, and Jbuilder, the most widely used cross-platform Java development environment. Delphi, which was the first truly object-oriented language packaged with a visual development environment, was designed by Anders Heilsberg. Anders was with Borland from its inception in the mid eighties until 1996, when he was successfully wooed by Microsoft Corporation, where he has led the development of the C# language. To a large extent, It was Delphi, and its DOS-era former incarnation, Turbo Pascal, that built Borland. And a generation of pc applications. But languages are no longer the corporation's focus. The letter from Borland CEO Tod Nielsen says: Our intent is to create a standalone business focused on the IDE (Integrgated Development Environment) market, capable of investing in the opportunities that exist for these product lines and advancing developer productivity.... It goes without saying that we will do everything possible to ensure a successful transition of our products and customers to the new entity. Why do I care? Members Only Software products are all written in Delphi. Delphi has always had a fanatically devoted user base, and I seem to be among them. The ease of use, the great integrated editor and debugging tools, the huge component libraries have made it a natural for our sort of work, where rapid development equates to lower cost to users. So of course I'm wondering what this will mean for the future of Delphi. Is it finally getting a home of its own, or being sent to the glue factory? Most of the Delphi developers I've checked with are fully in favor of the move. Deepak Shenoy complains that Borland, who has been focusing on their software management tools and not on languages, has not been giving Delphi or JBuilder the investment it deserves, in terms of enhancement or marketing, and concludes: This is a great step for Delphi (and other IDE products). The team seems extremely excited in a happy sort of way, and seems to be waiting to throw away the shackles that hold them back. The message is universal, and clear: The IDE people at Borland want this, and want this now. It's time for us, the community, to watch them weave their magic. Another developer, Nick Hodges, writes: Delphi's biggest problem, of course, was that the product and all the people we know who work on it and love it ("Old Borland") were gradually being marginalized by "New Borland". Well, it sure seems like all the "Old Borland" folks will become part of Delphi, Inc. That's very good news. And the Delphi folks at Borland do indeed seem to be enthusiastic. David Intersimone, currently the longest term employee at Borland (he's been there since 1985!), says in his blog on the Borland site: I'’m really excited to be moving to the new company. We'’ve got the right team members, we'’ve got the tool and component partner eco-system, we have the authors, trainers, consultants, and we have the most important part:– a loyal community. Our new company will be focused completely on you and your success. Long-time industry watcher and former Borlander Jeff Duntemann sums it all up like this: I think many may have it wrong: Borland isn't dumping Delphi; Delphi is dumping Borland. So it looks good. A new and as yet unnamed investor, an increased focus on developer relations, and excited team members eager to get back into control of the product. I'm looking forward to the next release! Tags: nptech, delphi

This and That

As if you don't get enough of my holding forth here, Marshall Kirkpatrick interviewed me the other day for Techsoup's Netsquared project, and posted it here. We talked about the work of my company Members Only Software, and how I see emerging Internet technologies impacting the non-profit arena. It was a really enjoyable, rambling conversation. But the posting is most noteworthy for the accompanying photo of me playing my fiddle at the Speedy Tolliver fiddle contest in Arlington VA a couple years back. 2. Around the same time, Marshall also posted an interview with Beth Kanter. You can read the interview here. If you don't read Beth's blog, well, you oughta. Beth is a Cambridge, MA blogger and techy who has done a lot of work with arts and educational organizations. She also does a lot writing relating to Cambodia. Beth picked up on my fiddling photo and expressed her musical solidarity by posting this picture of her playing the flute, thirty years ago, along with a touching yet classic story of how she met her flute teacher. 3. This week I discovered the blog of Ken Stein (no relation), a teacher in New York city. While the blog is not primarily about technology, he explores in this post his ideas for utilizing Writely, a web based collaborative word processor, as an educational tool. 4. Dave King is the acting director of IT at the Kansas City public library. His blog explores technology, web, and usability issues as they apply to libraries. Dave provides useful running commentary on a number of his experiments, such as creating a video blog from a Treo PDA, or setting up to give a webcast. Well worth a read. 5. Amy Kincaid, whose blog on fundraising is always worth looking at, points us this week to a great list of fundrasing and grantwriting resources hosted at Michigan State University. I've already been able use these resources to look very wise to an organization we work with, and pass on news of some available grants in their field. I do like to look wise. 6. Malin Coleridge of Techsoup reports that she got 880 responses to the survey on technology challenges facing non-profits that she and I developed last month! I'm very eager to see the results, and very grateful to everyone who took time to fill out the survey. I'm hoping that by learning what actual day-to-day issues are causing the most problems for organizations, we can learn more about the which of the solutions we techies are excited about really matter over the next couple of years. Tags: nptech, net2

Growing Organizational Knowledge

In the last post I talked about the difficulties we see organizations have in managing knowledge. So often vital information is just in one person's head. But what's worse, it may be spread across heads, with no-one having a complete picture of an issue. And in some cases, these heads are not all within the organization, but may be on the shoulders of outside partners or consultants. In my experience, for information to be truly organizational knowledge, at the very minimum four things must be true: It must be written down so it cannot walk out the door. It must be easily retrievable across the organization, so it can be found when it is needed, by any authorized person. Authorship must be shared so it represents a complete view of each topic It must be easily updated as reality changes. The first point seems obvious - but its a big problem. Writing takes time. That's why so many documentation projects fall by the wayside. But there is a more agile way to build documentation - by re-using the routine communications that are generated in the course of actual daily work. Whenever your or one of your users asks or answers a question, announces a policy, or simply shares information, chances are an informal email or other document was generated. In the best of all possible worlds, you might want to carefully rewrite this email before posting it as official documentation. You know you'll never get to it. But you can turn that email into organizational knowledge if you put it where authorized users can see it, add to it, comment on it, and search for it. But where would that be? Now that we have a process, we need a tool. Here is a perfect application for a wiki. A wiki is a website that allows a community of users to easily add and edit content and is especially suited for collaborative writing. We've been finding that the wiki is a perfect place to plant organizational knowledge. There are a number of wiki tools around. The inexpensive hosted wiki service EditMe can be started in minutes, and costs as little as $5.00 a month. At Members Only Software we've been using it to build our new Help System for our applications, and we're really impressed. Especially when you consider it is hosted - no installation or maintenance! An Editme wiki allows you to upload attachments to each page, to allow comments on the page, and to determine which users can edit a page and which can only read. You can set the rights differently on each page. Readers can view the history so they can see who made what changes. Users can see an index of page titles, or search the entire site for specific text. Of course the editor makes it very easy to put in hyperlinks to other wiki pages or external sites. To stay up with new information, users can request that the system automatically email them every day with links to all changes made the day before. How would you use it in daily life? Suppose someone sends you an email with valuable information in it. Don't remain the only one who get access this information - cut and paste it into the wiki. You download a pdf from your software vendor's site. Attach it to a page in the wiki. As you start integrating the wiki into your workflow, you realize it can become the first place you put information. When someone one your staff asks you a question about your fundraising software, for example, don't email them the answer. Add the answer to the wicki knowledge-base, and then email your user a link. The next time someone asks the same question, the answer is already there to be re-used. But before you do, ask them why they didn't search the wiki before bugging you! Tags: nptech, km, wiki