5 hours later I got this...
Monday, January 29, 2007
Sunday, January 14, 2007
Gamma Testing
I was uploading some piccies on Flickr earlier and noticed that along with their logo, there was a subtle 'gamma' logo. I wonder, is this a dig at the empire known as Google and the perpetual beta program?
Monday, January 08, 2007
Thoughts from a train
First of all, it's pretty hard writing from a train where you don't have a seat with a table is pretty hard. I don't think when the engineers were designing the train I'm sitting on thought that the tray for eating would be used for resting a laptop on. On well, it's a minor thing I suppose, I can make do with the shaking, mistaking typing of mine.
So, I'm waiting at Kings Cross for a train to Edinburgh. I'm early as usual (a character trait which forces me never to be late, but always far to early!), so I get a coffee and pick up the metro. Searching, I find no-where to sit and once I finish my coffee I find no bin to put the cup in.
Why is it that we're so paranoid in London that we don't have any bins anywhere. We'd rather contribute to poluting our fair city the comprimise the security. Funnily enough I didn't notice any litter at the station. Go figure.
So, I'm waiting at Kings Cross for a train to Edinburgh. I'm early as usual (a character trait which forces me never to be late, but always far to early!), so I get a coffee and pick up the metro. Searching, I find no-where to sit and once I finish my coffee I find no bin to put the cup in.
Why is it that we're so paranoid in London that we don't have any bins anywhere. We'd rather contribute to poluting our fair city the comprimise the security. Funnily enough I didn't notice any litter at the station. Go figure.
Friday, January 05, 2007
Keep It Simple, Stupid!
I wrote this a while ago and just rediscovered it -
==================================
I really wanted to show off some of the functionalities of the new BT SDK by integrating it into Windows Media Centre Edition (MCE). However trying to implement the simplest solution in MCE proved to be a performance in itself.
Recently I'd read Adam Bosworth's blog in Joel Spolsky's Best Software Writing I book. As Bosworth said "It was essentially a reminder to a group of very smart people that their intelligence should be used to accommodate really simple user and programmer models, not to build really complicated ones". I felt this was certainly applicable in the case where I was developing an MCE add in.
I went onto read Bosworth's blog with all the comments posted. Bosworth talked about the simplicity of PHP and RSS and the complexity of WS*, SOAP and WSDL. Many of the comments discussed their disagreements with the decision to highlight these items but I feel many missed the point of the discussion in general.
Bosworth says it himself, "software which is flexible, simple, sloppy, tolerant, and altogether forgiving of human foibles and weaknesses turns out to be actually the most steel cored, able to survive and grow while software which is demanding, abstract, rich but systematized, turns out to collapse in on itself in a slow and grim implosion."
Alan Kay said (and we've heard it around the office plenty of times) "Simple things should be simple, complex things should be possible". We've heard Tim say this plenty of times, but the SDK demo really brought this home for me. We weren't making it simple for the developers who'd be using the SDK. Both capabilities and the .Net SDK were guilty of this. There are arguments as too why this was the case, but at the end of the day it wasn't easy enough and that's what any developer would say when attempting to use our services.
Bosworth talks about how the simple and ambiguous free text search (Boolean logic) won over the seemingly easier query by example. "The engineering is hard, but the user model is simple and sloppy". We have to ensure that we follow this logic. The .Net SDK is there to make life unbelievably simple for the developer. We have to ensure that we hide as much complexity as possible from each abstracted layer so that the component layer can do something cool in one line of code.
Bosworth has concerns regarding WSDL, but remember let's forget about the technology for now and look at the underlining issue. "When it doesn't work, no human can figure out why". We've all had our problems with WSDL and developing on MCE proved equally frustrating. Initially I had to install MCE to get the libraries to develop against and had to develop custom batch scripts to compile and register my add-in. When I was happy with my "Hello, World" MCE add-in, I was ready to develop a BT SDK app but when it came to run the application it didn't work and there was no stack trace, no log file, no acknowledgement that the add-in had even failed. With my limited MCE development knowledge, I had run into a brick wall with reinforced steel, concrete and MCE developers!
Bosworth goes onto discuss programmers who consider code to be a means to an end. "The important issue is the content and the community, not the technology". As mentioned earlier, I originally wanted to do a brown bag on integrating MCE with the BT SDK, but the technology was an issue and so was the lack of content within the community. Developing on MCE felt like developing using COM; powerful, but as a newbie MCE developer, overwhelming.
Bosworth focuses on the value not of the technology but of the content. "The value is neither in the computers nor in the software that runs on them. It is in the content and the software's ability to find and filter content and in the software's ability to enable people to collaborate and communicate about content (and each other)". I feel this re-enforces the comment about the engineering being hard, but the user model being simple. The technology isn't important. Whether it's SIP, Oracle, SOAP or WS* it doesn't matter. What matters is that we get the content that matters to the users who want it (if they're allowed to access it of course).
We've all probably taught out parents or kids to use a computer and the internet and Bosworth reveals something that as engineers we can often forget. "My mother never complains that she needs a better client for Amazon. Instead, her interest is in better community tools, better book lists, easier ways to see the book lists, more trust in the reviewers, librarians discussions since she is a librarian and so on". An awesome SDK, great content and easy delivery isn't enough; supporting tools and communities need to exist to make using the application an experience and too pool the knowledge into a community to expose the power and simplicity of the products that are on the market.
"For the first time since computing came along, AI is in the mainstream". People can argue both sides for this comment, but I believe this comment comes from the ability of software to filter and deliver content to the users efficiently and quickly.
==================================
I really wanted to show off some of the functionalities of the new BT SDK by integrating it into Windows Media Centre Edition (MCE). However trying to implement the simplest solution in MCE proved to be a performance in itself.
Recently I'd read Adam Bosworth's blog in Joel Spolsky's Best Software Writing I book. As Bosworth said "It was essentially a reminder to a group of very smart people that their intelligence should be used to accommodate really simple user and programmer models, not to build really complicated ones". I felt this was certainly applicable in the case where I was developing an MCE add in.
I went onto read Bosworth's blog with all the comments posted. Bosworth talked about the simplicity of PHP and RSS and the complexity of WS*, SOAP and WSDL. Many of the comments discussed their disagreements with the decision to highlight these items but I feel many missed the point of the discussion in general.
Bosworth says it himself, "software which is flexible, simple, sloppy, tolerant, and altogether forgiving of human foibles and weaknesses turns out to be actually the most steel cored, able to survive and grow while software which is demanding, abstract, rich but systematized, turns out to collapse in on itself in a slow and grim implosion."
Alan Kay said (and we've heard it around the office plenty of times) "Simple things should be simple, complex things should be possible". We've heard Tim say this plenty of times, but the SDK demo really brought this home for me. We weren't making it simple for the developers who'd be using the SDK. Both capabilities and the .Net SDK were guilty of this. There are arguments as too why this was the case, but at the end of the day it wasn't easy enough and that's what any developer would say when attempting to use our services.
Bosworth talks about how the simple and ambiguous free text search (Boolean logic) won over the seemingly easier query by example. "The engineering is hard, but the user model is simple and sloppy". We have to ensure that we follow this logic. The .Net SDK is there to make life unbelievably simple for the developer. We have to ensure that we hide as much complexity as possible from each abstracted layer so that the component layer can do something cool in one line of code.
Bosworth has concerns regarding WSDL, but remember let's forget about the technology for now and look at the underlining issue. "When it doesn't work, no human can figure out why". We've all had our problems with WSDL and developing on MCE proved equally frustrating. Initially I had to install MCE to get the libraries to develop against and had to develop custom batch scripts to compile and register my add-in. When I was happy with my "Hello, World" MCE add-in, I was ready to develop a BT SDK app but when it came to run the application it didn't work and there was no stack trace, no log file, no acknowledgement that the add-in had even failed. With my limited MCE development knowledge, I had run into a brick wall with reinforced steel, concrete and MCE developers!
Bosworth goes onto discuss programmers who consider code to be a means to an end. "The important issue is the content and the community, not the technology". As mentioned earlier, I originally wanted to do a brown bag on integrating MCE with the BT SDK, but the technology was an issue and so was the lack of content within the community. Developing on MCE felt like developing using COM; powerful, but as a newbie MCE developer, overwhelming.
Bosworth focuses on the value not of the technology but of the content. "The value is neither in the computers nor in the software that runs on them. It is in the content and the software's ability to find and filter content and in the software's ability to enable people to collaborate and communicate about content (and each other)". I feel this re-enforces the comment about the engineering being hard, but the user model being simple. The technology isn't important. Whether it's SIP, Oracle, SOAP or WS* it doesn't matter. What matters is that we get the content that matters to the users who want it (if they're allowed to access it of course).
We've all probably taught out parents or kids to use a computer and the internet and Bosworth reveals something that as engineers we can often forget. "My mother never complains that she needs a better client for Amazon. Instead, her interest is in better community tools, better book lists, easier ways to see the book lists, more trust in the reviewers, librarians discussions since she is a librarian and so on". An awesome SDK, great content and easy delivery isn't enough; supporting tools and communities need to exist to make using the application an experience and too pool the knowledge into a community to expose the power and simplicity of the products that are on the market.
"For the first time since computing came along, AI is in the mainstream". People can argue both sides for this comment, but I believe this comment comes from the ability of software to filter and deliver content to the users efficiently and quickly.
Subscribe to:
Posts (Atom)