Advantages of wikis

The biggest advantage of a wiki is the ease of linking between documents.

The second biggest (and distinguishing) advantage of a wiki is the ability for everyone to edit.

The first advantage, linking, is not the sole domain of a wiki.  But many people (myself included) use wikis specifically for this purpose.  The ability to create (and track) documents through links is the principal power of the web as a whole, but I can think of few applications outside of wikis that make this easy.  I maintain the principal feature of a CMS is the ability to link pages as well, and it is probably the most poorly implemented, as well as the biggest lock-in.

So what makes up this feature?  I think it consists of two main parts: The ability to assume part of a URL, and the ability to tie the page title to that part of the URL that needs specified.

One important feature of a wiki for me is the ability to build a hierarchy of pages, such as tools:testing:bug-tracking:mantis (or tools\testing\bug-tracking\mantis.)  This is namespacing in code, and in wiki’s it is valuable too.  Using composition, you can also include an element in a different hierarchy (namespace) as well, such as projects:open-source:php:mantis.  It is a powerful organizational feature.

A CMS that had a good sitemap generation tool would be advantageous, particularly if pages could then be composed of components in different hierarchies.  By sitemap generation, I mean the ability to create hierarchies of pages as objects that can interact (through links) and be called by aliases or alternate routes.

I mention routes, because I think of Rails’ “routes” mechanism for mapping pages (or servlet-mapping, for java afficionados).  The other feature of wiki URL, and CMSes, and Rails that people are drawn to is pretty URLs, or rather, descriptive URLs.

The other feature of wikis that people like, as I mentioned is the ability for everyone to edit.  It’s also the most trepidatious.  Wikipedia is the hallmark of success for this feature, but a large part of their effort is in fighting corruption, spam, and bias.  It’s the reason something else hasn’t taken it’s place.  For every wikipedia, there are a million overrun, neglected, or out of date wikis (like my own.)

Permissions, captchas, and administrators are the answer to this.  But most wikis die of organizational failure.  The ability to edit pages (and link mapping), and the ability to structure them in hierarchies is critical to the success of a wiki.

The choice to restrict access is a critical one, and paradoxically, is more important (and more harmful) at the point before which a wiki draws the userbase to be self-sustaining.

The question then is, how do you build up the user base to reach a self-sustaining management level in a wiki without it getting overrun or disorganized.  Better spam prevention, approval workfly, and organizational editing may be the answer.

I’d be curious to know what that point is.  I’d guess it would be around 100 dedicated or 1000 casual users.  For a restricted environment (such as an intranet or members only wiki) that number might be as low as 10 (or possible exists in a ratio of perhaps 1:3 dedicated to casual users), where organization and relevance being the battles needing fought, rather than spam.    The ratio may be the key, where spammers would count as some number of casual users.  Clearly also, the administrative tools affect (and should be aimed at lowering) this ratio.

Google docs ate my presentation

It’s tempting.  Just click here and create a presentation.  No need to install powerpoint (or open office).  But don’t do it.

I was about 3 hours work into a presentation, and Google docs decided to crash.  It saved regularly, so I felt comforted, but guess what?  My presentation doesn’t exist anywhere except as a broken link in Google’s system.

Not only was it the presentation, but about a half page of commentary on each of 14 slides.

Ideas for testing articles

Here are some articles/blog posts kicking around in my head that I thought I’d write down.

  • 3 types of tests (validation, regression, exploratory)
  • Focussed exploratory testing (and session based testing)
  • Web automation tools (Selenium, Watir, Canoo, Mechanize)
  • Page based testing framework (page elements and IDE completion)
  • Introduction to Selenium with STIQ (SolutionTestIQ)
  • The QA stack (version control, documentation and requirements, task management, bug tracking, builds, code analysis, continuous integration, deployment, test framework, automation — examples: subversion, xwiki, projectpier, bugzilla, ant, cobertura, cruisecontrol, capistrano, junit, selenium )
  • Bugs, Tasks Tickets, and Features
  • Bugs vs. Defects (one bugs you, the other doesn’t match a requirement)
  • Triage – taming the bug database (include backlog review)
  • Grouping tests (with tags)
  • wiki test cases
  • test consulting survey (would you hire an independent consultant?)
  • testing and domain knowledge (why a consultant with a recurring part time relationship)
  • Version Control Systems – one of the most important QA tools (it allows you to break things)
  • Archetypical prospective customers
  • Scrum and Standup meetings

If someone asks for one of them, I’ll get to work on it. Otherwise, I’ll work through the list and add/subtract as I feel.

Ten commandments for business failure

I was at the library the other day looking for books about how to start a business and consulting and stuff like that, and Kelsey found this book:

The Ten Commandments for Business Failure” by Donald Keough.

I thought I might as well figure out how to do it right, so I added the book to the stack.

Don was the president of Coca-Cola in the 1980s and is probably most famous for heading the company while Coke was losing the cola wars to Pepsi, and especially for the New Coke debacle (that some say was a just brilliant marketing ploy.) The reintroduction of Coke Classic was probably the tipping point of the reversal, to where Coca-Cola once again enjoys a dominant position worldwide in the fizzy, sweet, caffeinated beverage business.

It was an interesting read, though the author didn’t dwell too much on New Coke, he does mention it, and accept at least partial blame. The moral of that particular story is “Don’t listen to consultants” — or rather “Listen to consultants if you want to fail.” Good advice, for my clients that is.

The whole book is written with that somewhat gimmicky formula: “Do X if you want to fail”, meaning “don’t do X if you want to succeed.”

It isn’t specifically about his leadership at Coca-Cola, but rather general business advice. The most profound point is probably in the introduction where he says he doesn’t have the formula for success but that he does know 10 rules (actually 11, there’s a bonus chapter) that are almost guaranteed to help you fail.

I don’t want to give away the rest of the commandments, because it might hurt book sales, and the 10 (11) commandments are really just pithy, common sense advice, but worth reiterating. The book is actually quite an enjoyable read, moreso for the interesting, optimistic tone of a successful man who may have made mistakes, but was definitely not a failure.

I thought he was surprisingly “with it” and his advice relevant to the times and up with technology and the current business climate. I particularly enjoyed his chapter on pessimism and how he skewered the Global Warming doomsayers without mentioning it or them by name (except for Paul R. Ehrlich, one of the leaders of the global warming movement, and then only in the context of his malthusian claims as recently as 20 years ago about the impending new ice age.)

Despite a few “Norman Einstein” moments (such as claiming India acquired nukes in the 1970s) and a slight tone of the born privileged, I enjoyed the book and appreciated the advice. I found myself liking and wishing to meet Don Keough long before the end of the book, and not changing that opinion by the time I was done.

Unfortunately, though, I plan on ignoring the 10 commandments, and finding a way to fail on my own merits.

It’s official

I’m an independent consultant looking for work. One Shore Inc is open for business.

Here’s my plan:

  1. Spend the next week fermenting, which means:
    • reading — how to be a consultant and starting a business books, articles and websites
    • brushing up on skills — tutorials, test deployments, quick scripts
    • networking — contacting other consultants and startups and asking for advice. Not looking for potential customers yet
    • marketing prep– finishing up one-shore website redesign. Getting business cards, etc. Creating copy for website, building brochure. Creating an “elevator script” and a “value proposition”
    • Business details — squaring out legal, accounting, & business stuff. That includes cleaning up my desk & establishing a routine.
  2. Spend the next month in R&D, which means:
    • Finding the right CMS/Framework for the website
    • More reading
    • Researching technology
    • Learning as much as I can from other small businesses
    • Learning as much as I can from potential customers (what do they want in a QA consultant / test tools?)
    • Building a prototype QA site
    • Work on side projects
  3. Spend the second month looking for customers:
    • calling businesses
    • talking to recruiters
    • advertising
    • attend meetings and workshops
    • writing articles
    • Further work on QA site and other projects
  4. Spend the third month doing “pro bono” work:
    • getting referrals
    • refining requirements (for both product and consulting)
    • building up a reputation
    • volunteer work for non-profits, etc.
  5. In May, I need to make a decision, continue development and customer search, or start looking for a regular contract job. I’ll probably want a 3 month contract to replenish funds and secure income for moving. The goal is to have a paycheck by May 15.
  6. Either continue consulting with an eye to diversifying after that or pick up where I left of after a contract. Possible move.

The side projects I’ll be working on (at least at first) will be for Herculean Group (an open source consortium) or Cape Henry Tech or related firm. I’m committed to 10 hours a week work for them for the next 3 months at least, doing java development, QA, and general IT operations. I may also take on web-dev work as well, but not in the first 2 months unless it falls in my lap.

I’ll also be working on the tools wiki and a QA tools book.

I’m open to contract work, telecommute full time work, or part time/short term on-site work.

I won a copy of Balsamiq Mockups

Nate Beck is a friend of mine who has a blog  where he writes a tip of the day about Flex development.  He had a contest where he asked other people to write a tip, which I entered.

With only a little back-room dealing, I managed to win the contest.  Peldi, the creator of Balsamiq Mockups donated a copy of it as the prize.  So now I have a tool for redesigning the One Shore website, and more importantly, for working on the QA Site and Harvest Requirements layouts.

The Confluence/Jira & Xwiki plugins for Balsamiq look interesting too.

Oh, my tip is also on Nate’s blog, its about using Sprouts for flex development.