My use of CRC and other personal interactions with Ward are covered on my web site.
As his LinkedIn profile states
"I have devoted my career to improving the effectiveness of technical experts, mostly by creating new computer tools, but also by radically simplifying methods"
This will be the focus of my interview with Ward for Patterns of Success
John - Ward, thanks for taking the time for this interview. As I explained in the email I am looking to cover three topic areas:
- Patterns of Success
- Failures to Launch
- THE NEXT BIG THING
Ward - I would say our focus now is in helping small business use those services and especially in search engine optimization. We realize that it is getting traffic to the site, the right people to the site that matters.
John - So in the areas of Patterns of Success, what are some patterns that you have seen over the years?
Ward - I think there are a couple of different kinds of success. And one is getting your job done on time. And the thing there is not to make the job bigger then it needs to be.We are sometimes unsure of what we are supposed to do so we do everything what we might be asked to do. Sometimes developers avoid having a conversation with the customer asking "Would it be OK if we just did this?" A large part of Agile is the notion that we plan often, so we do not make these giant plans of everything we might want. Instead we say "Maybe we should do the first half and see if maybe thats enough".
John - Is that just a matter of we don't know where we are going til we get there, meaning these big plans try to anticipate things way out in the future OR is it that we think better in the small, in smaller units of complexity?
Ward - Its more like its easy to imagine software that has almost unbounded number of problems that you don't think about in the beginning. For example I wrote a report program once that sorted on the first column only in ascending order. People told me it was a terrible program.
John - Why did they think it was terrible?
Ward - Oh because it should sort on any column or select any combination of columns to sort on. And the problem was not that it could be programmed that way but that I could not make an easy to use interface that would explain how it would work. When my users opened my report sorted on the first column it was easy to understand and they could get onto reading the report.
John - So it was good enough to get the job done?
Ward - It was good enough for the moment. In XP terms that would be called taking a split. Lets split the functionality into a release that is basic and then talk about adding extras in a later release.
So the idea is to be willing to do less and that is a skill that comes with confidence. If you do not feel that you need to defend your programming ability or ability to conceive a system then it is easier to do something in a minimal way. I think that has grown into the concept of a minimally marketable product. That is at the product level, but as an individual programmer it sure feels good to get something done at the end of the day.
So a very important skill is the ability to separate out of a big project lots of little projects that are worth doing and doing quickly.
So that is one type of success. But I want to shift to another kind of success that I call exceeding expectations.When it comes to exceeding expectations I have a little saying... "The path to exceeding expectations probably does not go through meeting expectations".
In other words, if you are going to delight somebody, you are going to give them something that they didn't expect. So if the first thing you do is do everything that is expected and second do something that is beyond.... it is too linear. It is like delivering the asked for twelve sort functions and saying you are exceeding expectations by giving the customer fourteen sort functions.
For example, nobody asked for wiki, so how was it that I was able to make something so popular? Well there is a certain minimalism that allowed me to make it, but more important there are things in there were not expected like spec linking just because I was playing around with Hypercard and trying to figure out what it could do. So instead of trying to meet expectations you have to redefine the problem and ask what if they asked for this? Could I do that better then this?
One thing I discovered pretty early on is that if I went into staff meetings and delighted people with one thing they would forget about all the things I was supposed to do.
John - But there is a kind of genius... an inventing light bulb going on in the developer's head when they're listening to the customer saying what they want and offering up the unexpected, theres something about their own domain knowledge, thinking outside the box, their inventiveness that allows them to give back the unexpected. What is it? Are there just some individuals that can do this? Or is there a prescription that someone can follow to achieve the result?
Ward - The formula is to do a lot of it. Over many attempts to build software you build up patterns that you can draw on to solve the next problem. I look back at my own career and I started computer programming for fun. I did not take the class my high school offered when they got a computer, instead I sneaked in during my free period, made up problems and solved them. And even during my professional career I have done a lot of good work for my employers or clients but the stuff I am most know for I just did for fun. That willingness you have to invest your own time on a project gives you the freedom to turn a problem around and play with different solutions.
John - We've been speaking of wiki as a collaboration tool. Have you had a chance to play around with Google Wave?
Ward - Yes. I thought Wave was fantastic. I told people that Wave was more like wiki then wiki. I think that one of the things that happened to Wave was that people did not know how to write in the medium. When wiki first started people did not understand that you need to revise the document relentlessly to make it match your current understanding.
People ended up using Wave in a very conversational way instead of this document emergent way. When they could not get in touch with the people they needed to, they would just stop using Wave.
John - Well lets hope Google has learned some patterns from Wave and refactors that knowledge into some of their new and improved services.
Ward - If we want to talk about a Failure to Launch then Wave would be a good example. You need a critical mass of participation to be successful. That is also a classic problem with wikis. Companies will tell me that they need some of that wiki stuff and if it fails it is because the community around the wiki never formed correctly. First they need to be given a sense of what they are supposed to do in the wiki. Then you have to help them do it until they get good. Ah! Here is a formula for being successful at propagating ideas
- You have to have a technology, a computer tool that supports the propagation.
- You have to have a methodology, a way to use the tool to deliver its promise
- You need to have a community, the correct number of people using the tool and following the methodology.
John - Have you written down this methodology of how to use a wiki?
Ward - No, you might get me started on that, though. There is a nice book on wikipatterns that I wrote the forward for. It included several patterns for how an organization should launch the wiki.
John - So give me another dramatic failure to launch.
Ward - Hmmm. You know most of my ideas flop. But out of the failures it sensitizes me to the missing element for success... so whenever I fail it teaches me something I don't know how to do.
John - Let me change gears to our final topic... THE NEXT BIG THING. What do you think it will be three years out?
Ward - I recently made a prediction for Cutter Consortium. Something that could happen but isn't happening. And that something is the way systems are evolving... Software as a Service. I think that there will be refactoring across system and organizational boundaries.We need to allow APIs to evolve without allowing things to break.
John - What technology does this refactoring run on?
Ward - Well I have seen something in the Eclipse platform called refactoring scripts. I can save a refactoring script and can send it to you, where you can run it against your program without me having to know what the internals of your program are. In order for this to work, I would need dozens of examples of use of my API including refactoring scripts that can be applied to my demo programs. As part of my SLA I would promise to provide refactoring scripts for each of my API demo programs whenever I made a change to the interface.
John - So lets use a concrete example. Suppose we both work at Walmart and are working with Proctor and Gamble on a new Order Management System. We have an API and would send P&G some refactoring scripts that could modify their Order Management System. Right?
Ward - We have this dream that if we hold the API constant we can change anything behind it without impacting our users. But I believe that is false. Anything worth doing is exposed through the API.
If this is going to really work we will need to evolve those services so they do not have intimate knowledge of the other side. Thats why I say refactoring across organizations. Suites of demo programs and scripts that can be applied to them, available to the community of cooperating companies.
John - So if I go up to Eclipse Foundation will I find an example of refactoring scripts?
Ward - Yep, In fact when I was doing research for my Cutter article, I found a blog post that gave that example but it did not suggest the refactoring across organizations. In fact when I spoke with the authors they did not think it would be a good idea. They thought the API should remain stable. But if we are going to make something that has emergent properties instead of re-writing big programs over and over again we need to figure out a way for them to evolve.
John - Well thank you for taking the time to speak with me and share your ideas.
No comments:
Post a Comment