Whilst playing poker against my girlfriend last night, and consuming the odd Jack Daniels or three, she told me a story. Now I'm going to tell it you...
"Once upon a time, there was a very rich man. He gave two builders a million pounds each, and told them to build the perfect house and they had 6 months to do it. The builders went away, and time passed.
Later that year, the rich man returned and said to the builders, "Have you each built me my perfect house?" to which they both replied "Why don't you come and see?"
The rich man went to the first house and it looked magnificent. Massive oak doors throughout, marble on every floor, long sweeping staircases, towers and spires stretching towards the sky, more rooms than Buckingham Palace, swimming pools, gadgets and gizmos - stunning! The rich man nodded, and said to the second builder, "I'd like to see the house you built".
The second builder took the rich man down the road, to a far smaller house. It didn't have as many rooms and hardly any stairs. It had no marble floors or oak doors, nor swimming pools. The rich man nodded. He turned to the first builder. "My", he said, "Your house certainly looks the most perfect house ever. As payment, I'll let you keep that house." The first builder went away, to tell his wife to start packing.
The rich man turned to the second builder, and paid him for his time and effort. The second builder, looking downcast, thanked the rich man and turned to leave. The rich man reached out a hand to stop him. "Why do you look so downcast?" he asked.
"I've been a builder for 25 years, sir", the second builder said, "man and boy. Each part of that house was lovingly built by craftsmen I know and trust. They worked hard to ensure everything that one built fitted with what the next built, be that a window in a wall, or a handle on a door. I spent time with you, sir, finding out about what you liked and didn't, what you wanted and what you actually needed. Everything in that house works perfectly, will last a lifetime, and is everything that you asked for. So I'm very sad that I lost, sir."
"Lost?" said the rich man, "Lost? But you won my friend! I'm moving in tomorrow. This house is exactly what I needed." The first builder was confused. "So why did you give the other builder the house as payment?"
"Well", the rich man, "I don't like marble, and I can't swim. With just me and my wife, I don't need all those rooms! And nothing seemed to fit with anything else, either physically or in look. I turned the hot tap on, and cold water came out. I turned the TV on, and the lights went out. He can have it - it doesn't join together, the foundations look shoddy, the architecture is a mess and the basic utilities don't work. He obviously never tested them - it will cost a fortune to rewire. And another fortune for me to change the decor to what I want. And we'd never use the first floor, let alone those towers, with all those stairs - you know my wife suffers with her hip. Within a year, that house will have cost so much to maintain, and have so many patches all over it, he'll never be able to sell it. No, it is you I must thank sir, for you have built me exactly what I needed, and everything I wanted. This is my perfect house. I'll be recommending you to all of my friends!"
The second builder felt the warm rush of pleasure in a job well done. He shook the rich mans hand, thanked him politely, got into his van and drove happily towards the setting sun."
I've spent years learning about analysis, designing and building software, testing, selling, project management - trying to become a better professional. Turns out my girlfriend knew about it all along. And she learnt it in Sunday school. Still, I did win at poker...
Saturday, October 22, 2005
Friday, October 21, 2005
E-Learning 2.0
This article on E-Learning 2.0 (read Web2.0), again by Stephen Downes, is another gem. I'm not going to write about my thoughts for once, but just pick out a few sentences which struck a real chord with me.
"Sharing content is not considered unethical; indeed, the hoarding of content is viewed as antisocial. And open content is viewed not merely as nice to have but essential for the creation of the...learning network"
"In a nutshell, what was happening was that the Web was shifting from being a medium, in which information was transmitted and consumed, into being a platform, in which content was created, shared, remixed, repurposed, and passed along."
"For all this technology, what is important to recognize is that the emergence of the Web 2.0 is not a technological revolution, it is a social revolution."
"The e-learning application, therefore, begins to look very much like a blogging tool. It represents one node in a web of content, connected to other nodes and content creation services used by other students. It becomes, not an institutional or corporate application, but a personal learning center, where content is reused and remixed according to the student's own needs and interests. It becomes, indeed, not a single application, but a collection of interoperating applications—an environment rather than a system."
If you've reached this point, I hope your next step is clicking that link and reading the article. If not, you're probably on the wrong "social network". Still, lets part as friends, eh...
"Sharing content is not considered unethical; indeed, the hoarding of content is viewed as antisocial. And open content is viewed not merely as nice to have but essential for the creation of the...learning network"
"In a nutshell, what was happening was that the Web was shifting from being a medium, in which information was transmitted and consumed, into being a platform, in which content was created, shared, remixed, repurposed, and passed along."
"For all this technology, what is important to recognize is that the emergence of the Web 2.0 is not a technological revolution, it is a social revolution."
"The e-learning application, therefore, begins to look very much like a blogging tool. It represents one node in a web of content, connected to other nodes and content creation services used by other students. It becomes, not an institutional or corporate application, but a personal learning center, where content is reused and remixed according to the student's own needs and interests. It becomes, indeed, not a single application, but a collection of interoperating applications—an environment rather than a system."
If you've reached this point, I hope your next step is clicking that link and reading the article. If not, you're probably on the wrong "social network". Still, lets part as friends, eh...
Joining together Semantic Networks and Social Networks
I've just read this article by Downes called "Semantic Networks and Social Networks". There's an academic slant to it, but that's no bad thing as he manages to compress into very few words so many areas of discussion pertinent to our domain that I don't really know where to start. Lets say he covers nodes, community, indduals, semantic web, Tim Berners-Lee, RDF, ontologies, XML. Learning Objects, DOI's, RSS, DC, Creative Commons, Taxonomy, identity2.0 (this presentation by Dick Hardt has been doing the rounds at Talis recently - if you want to pass 15 mins in awe, check it out), FOAF, authentication, Clay Shirkey...you get my drift.
The overall thrust of the article is that semantic networks and social networks have developed on the web in isolation, and these need to be more explicitly linked in what he terms the SNN (Semantic Social Network). This is about, bottom line, relating personal information and resource information in more formalised, structured way.
I've not considered this yet, so don't have much meaningful to add. My first impression is that Talis are very focussed on content (i.e. resource) description, but people like Ian Davies are now adding this layer of identity to our debate. Indeed, authentication and authorisation has been part of the library debate for a while - we're just no closer to solving the real problems these create. Maybe the answer lies somewhere in bringing the social network (people) and semantic (resources) into a tighter mesh. I touched on this when I was talking about folksonomies, and globalisation, where I discussed belonging to different "villages".
I feel its time I started to widen my thinking.
The overall thrust of the article is that semantic networks and social networks have developed on the web in isolation, and these need to be more explicitly linked in what he terms the SNN (Semantic Social Network). This is about, bottom line, relating personal information and resource information in more formalised, structured way.
I've not considered this yet, so don't have much meaningful to add. My first impression is that Talis are very focussed on content (i.e. resource) description, but people like Ian Davies are now adding this layer of identity to our debate. Indeed, authentication and authorisation has been part of the library debate for a while - we're just no closer to solving the real problems these create. Maybe the answer lies somewhere in bringing the social network (people) and semantic (resources) into a tighter mesh. I touched on this when I was talking about folksonomies, and globalisation, where I discussed belonging to different "villages".
I feel its time I started to widen my thinking.
Wednesday, October 12, 2005
Goggle tagging...
Interesting one this, along the old folksonomy philosophy. Using the Google Search History (now termed "Personalised Search" I think), you can add tags/comments to pages you visit. Consider this in the future, if they take a del.icio.us approach and start sharing this, we have a the makings of powerful folksonomy of the web. If enough people buy into the idea...
Sunday, October 09, 2005
Less is more...
A combination of holidays (why, thanks for asking, they were very nice) and work has meant I've been a bit quiet recently. Anyhow, picked this up from O'Reilly, which also hit the radar of one of my colleagues (Ian Davies) who was fortunate enough to actually be part of the discussion. Either link will fill you in...
It's one of those things you read and find yourself nodding in agreement. None of it was "new" in my book, but it is refreshing and concise. Couple of things I'd like to add:
Documentation: I've been working on a documentation strategy for describing our platform recently, and the analyst team have been putting a lot of work into becoming far more agile in our specification approach. So I take issue with some of the comments regarding avoiding investing in a business plan and, especially, the comment "Build things, don't talk about building them. Don't write specs that will be outdated and totally unrelated to your final product. Don't create the technology and then slap a UI on it -- instead build the UI first, iterate and learn from your mistakes. Then, once the UI is done, put the actual technology behind it. Let the UI screens be the specification for your technology."
You need to document at high level - to strengthen understanding (it reinforces the thought process), to communicate, to scope, to build. The key thing is minimum documentation (yeah, yeah, all part of the agile principles). Its about documenting just enough and moving on when you're not adding value. This applies to the early business planning, business requirements, market requirements, project docs, vision/scope, etc, and equally applies to your functional specification. I wouldn't build the UI first, I'd storyboard first. May do a bit of work nailing down the customer problems and goals. Couple of use cases or scenarios may help, or they may not. Diving straight into the UI is going to get you a whole lot of grief. However, the sentiment is right. Do just enough work/documentation to understand, then "just do it"!!! The key problem is knowing when you've done "just enough" and that comes primarily from experience.
Features: I'm so with this. Less is definitely more. Just look at the i-pod. It was such a success over far more "feature rich" mp3 players because every feature added value to the user and let them achieve their immediate goal efficiently. There are no features to distract or create noise. Mobile phones are another one here. I use about 5% of the features on my phone. There are probably another 5% which would be really useful to me. But the feature noise is so high, this deters me from making the investment because "it makes me feel stupid". And I'm a techno-freak! Cooper has some wonderful stuff on this in his 'running the asylum' book.
I left libraries and moved to Talis for many reasons - one key one was that I wanted to make a difference to the lives of users, and the way the public sector works just doesn't encourage this (too much red tape!). Skywalk (the library instance of our Web2.0 platform - more at the Talis Insight conference) is going to be a wonderful tool to realise my goal - which is to realise the goals of all the institutions and their users who consume the web services we offer. What is going to be key is finding those key features which will make that difference to peoples lives and exposing these first/now, rather than delivering 101 features en masse a year from now when all those goals have changed. Less features = less noise = more value.
It's one of those things you read and find yourself nodding in agreement. None of it was "new" in my book, but it is refreshing and concise. Couple of things I'd like to add:
Documentation: I've been working on a documentation strategy for describing our platform recently, and the analyst team have been putting a lot of work into becoming far more agile in our specification approach. So I take issue with some of the comments regarding avoiding investing in a business plan and, especially, the comment "Build things, don't talk about building them. Don't write specs that will be outdated and totally unrelated to your final product. Don't create the technology and then slap a UI on it -- instead build the UI first, iterate and learn from your mistakes. Then, once the UI is done, put the actual technology behind it. Let the UI screens be the specification for your technology."
You need to document at high level - to strengthen understanding (it reinforces the thought process), to communicate, to scope, to build. The key thing is minimum documentation (yeah, yeah, all part of the agile principles). Its about documenting just enough and moving on when you're not adding value. This applies to the early business planning, business requirements, market requirements, project docs, vision/scope, etc, and equally applies to your functional specification. I wouldn't build the UI first, I'd storyboard first. May do a bit of work nailing down the customer problems and goals. Couple of use cases or scenarios may help, or they may not. Diving straight into the UI is going to get you a whole lot of grief. However, the sentiment is right. Do just enough work/documentation to understand, then "just do it"!!! The key problem is knowing when you've done "just enough" and that comes primarily from experience.
Features: I'm so with this. Less is definitely more. Just look at the i-pod. It was such a success over far more "feature rich" mp3 players because every feature added value to the user and let them achieve their immediate goal efficiently. There are no features to distract or create noise. Mobile phones are another one here. I use about 5% of the features on my phone. There are probably another 5% which would be really useful to me. But the feature noise is so high, this deters me from making the investment because "it makes me feel stupid". And I'm a techno-freak! Cooper has some wonderful stuff on this in his 'running the asylum' book.
I left libraries and moved to Talis for many reasons - one key one was that I wanted to make a difference to the lives of users, and the way the public sector works just doesn't encourage this (too much red tape!). Skywalk (the library instance of our Web2.0 platform - more at the Talis Insight conference) is going to be a wonderful tool to realise my goal - which is to realise the goals of all the institutions and their users who consume the web services we offer. What is going to be key is finding those key features which will make that difference to peoples lives and exposing these first/now, rather than delivering 101 features en masse a year from now when all those goals have changed. Less features = less noise = more value.
Subscribe to:
Posts (Atom)