Month: July 2008

Blogs and Wikis

I have done a moderate bit of blogging and wiki editing, although most of it has been behind the closed walls of employers.  I got to thinking about it though, when is the “right” time to use a blog or a wiki?  I have my own opinions based on that …

First let me say that I tend to think of both blogs and wikis as business and/or resource tools, I do not think of them as a way to communicate personal information – I do that other ways with my friends.  I may want the whole world to see what I think about a technical or political topic, but that is very different than letting you know where I live or who my family members are.  I know not everyone agrees with me in this area, but I think it is important to understand my stance on what is appropriate for public vs private consumption to understand my thoughts on when to use a blog vs. when to use a wiki.  Now that we have gotten that out of the way, let’s move on.

I think most people think that the decision is straight forward – use a blog when you are the sole owner of the material or thought, use a wiki when the content is shared.  Makes sense, but I don’t think it is the whole picture.  When I think of a blog I think of a way to communicate unrelated bits of temporal data.  Maybe news or a short burst of thoughts on a topic, or commentary.  That’s not to say there isn’t or shouldn’t be some connectedness between blog posts either within a blog or across blogs.  The connectedness is useful and good, but not the same connectedness of a wiki.  I see a wiki as trying to tell a story or provide direction that is not temporal.

But what does that mean, temporal vs. not temporal?  What I mean by that is that a blog is a one time shot – I am telling you something as it is or as I see it then and there at that point in time.  I don’t believe a wiki presents itself in the same way.  A wiki is made up of inter-related content that, while created over time, should be able to withstand the test of time (i.e. it should be updated to reflect current status, not subject to a point in time).  A wiki can be constantly edited and corrected, and should be.

But doesn’t that really take me back to the first point about who “owns” the content of the blog post vs the wiki entry?  Not really.  I can’t argue with that point, I believe it to be true.  But what if you are the sole owner of the content of both a blog and a wiki?   Why would you do that, you ask?  (i.e., why would you have a wiki only you could edit)?  Because of the type of content, style and connectedness of the content, and the expectation of the reader.

Let’s use an example.  Here I am blogging about wikis and blogs.  It is a short (ok, not so short) opinion that I have right now.  It certainly isn’t any statement of fact, it is an opinion … and my opinion could change over time.  Since I don’t want to rewrite history I might actually make another blog post over time that states I have changed my opinion.  This is just the kind of thing that I would expect to read in a blog, but would never, ever read in a wiki.  On the flip side, I also have a wiki (shameless self promotion, visit  http://peragro.wikidot.com).  I have two main things on that wiki about SOA and SOA Governance (I plan to put more there soon).  Those topics connect to each other, they have sections that would make them way too long for a blog, and as the state of development and SOA changes, so should the content in that wiki.  What I said in the past is no longer relevant, only what people need to know to develop a good architecture at the time they are reading it with the most up to date information.

I am not sure if this post will actually help anyone work out any issues they have in trying to decide on over the other, and the fact of the matter is that the technology is converging anyway such that soon enough there won’t really be a difference between the two, just a difference in the types of content you find spread across a bliki (Blog + Wiki).  Maybe my real reason for doing this is to justify the various places I have squirreled my content away.  Anyway, you’ve read this far, go ahead and check out my wiki.

Advertisement

iPhone and Blogging in WordPress

This post is coming to the site courtesy of an iPhone 3G ….

So, what do I think of the usability of posting via an iPhone? Overall the experience is fairly positive considering that typing on a small keyboard definitely slows things down. I won’t bore you with yet another review of an iPhone since there are already so many out there. What I will tell you is that I do recommend the WordPress application from the iTunes application library. It isn’t flashy, but it does do the job of letting you post your thoughts when you don’t have access via a larger device … Maybe while you are sitting in the airport or taking a long ride in the car (notice I said riding, not driving!)

My advice? Try the iPhone app, take it for a spin, but do you hard core blogging on something with a little more finger real estate.

I can’t resist saying at least one other thing about the iPhone… I do very much like the 3G, although we don’t actually get those speeds where I live. Everything has been great, except MS Exchange integration. One of the big reasons I waited to get the 3G was to be able to get mail pushed from our corporate servers, and so far no dice. I was able to connect to some other Exchange services outside of our company, but so far we have not been able to find the secret ingedient to getting our mail server to work.

That leads me to leave you with a final thought on the various “answers” that people have out there to try and make this work:

If you are guessing, just say you are guessing and don’t fake being an authority ok the subject …. And if you really don’t know, just stay silent. All the garbage out there that is clearly not right just makes it take that much longer to find the real answers.

Agile vs. Agile

“Agile Development” has been a buzz term for quite a while, but people still manage to use it incorrectly.  When somebody comes to talk to you or your team and says “I think we need to be more agile”, it is always important to ask them what they really mean and make sure that they actually do mean “we” and not “you”.  Why does that matter?  What’s the difference?  Agile is good, right?

Well, not necessarily.  First off, lets define what Agile Development is.  If you ask any six pundits, you would probably get six different answers, but in general I don’t think anyone would disagree with:

Agile development is an iterative and collaborative approach to software development that allows teams to respond to changing demands of the business.

I am intentionally leaving it simple and leaving out things like how much process is needed / not needed, and what types of deliverables are required to avoid arguments and stick to the basics.  Anyway, that makes sense, who could disagree with that?

Plenty of people.  First off, let’s just state that agile development isn’t the right fit for every situation and not worry about why it might or might not be (that’s a topic that has been covered many times already).  The issue here is discerning what someone means when they say “we need to be more agile”.

There have been many times when the “uninitiated” project manager or company leader makes this statement, and what they really mean is that “you need to be able to respond to my every whim”.  O….kay.  That is one definition of agile, I suppose.  This manager hears agile and thinks, gosh, I really could get everything I want exactly when I want it, agile is about the team being able to respond to my every request.  Don’t laugh, there are plenty of people that think this, and why not, it actually has been the state of development for a long time.

This interpretation of agile only provides for one set of changing behaviors – that of the development team.  Agile behavior goes way beyond the development team, it needs to create change in an all-inclusive team that is composed of not only the development team, but those very managers and other stakeholders such as QA, Operations, and customers (internal and external).  A real agile development process touches everyone.  Agile is about everyone sharing the pain and the gain all together.  Agile is not about a couple of developers responding to issues whenever they arise, it is about the entire group understanding what is important and each taking a stake in the success of the delivery of whatever the end results may be.  Agile is about creating behaviors that lead to trust across an organization through predictability.

When everyone works together and takes responsibility for prioritizing what needs to get done and continuously communicates not just progress, but all apects of the work being done, the end result is more predictable and there are not any big surprises.  Predictability and trust are important – those are the cornerstones that help information flow throughout the collective group and provide the building blocks for everyone to not only appear successful, but actually be successful.

So, when someone comes to you to talk about agility, make sure you know what they mean, and if they don’t quite get the true meaning, gently give them a push in the right direction.

Innovation

[ This particular post is just reused material from one of my other blogs at Blogspot that I thought was worth reporting here. ]

I was reading an article about innovation on ZDNET a number of months back about innovation. It was the standard argument about what innovation is … is it revolutionary or creation of something from scratch? The article had two different points of view that it presented as it related to the topic. (Unfortunately, I can’t find the link to the article now.)

I think that both of them made some interesting points, but that they failed to put together what I think is a holistic view of the situation. Innovation need not always be the creation of something from scratch and need not necessarily be revolutionary … Innovation can also be using existing parts in a new way. What would be truly innovative would be to create two entirely different applications or services using 90% of the same pieces; pieces that already existed from other projects in the company or as parts of open source efforts.

If you sit back and really analyze most applications you will find that a significant portion of the effort involved with creating an application is the same effort that goes into every other application – security, data source access, presentation, transformation, reporting, etc. While each application may use these services slightly differently, the general idea is primarily the same. Think of how efficient an organization could become (and agile) if it concentrated on the 15% to 25% that truly makes applications different from one another. That would truly be innovative.