It's now confirmed that the new iPhone will be a closed platform. More of an iPod than a Mac really, which as a potential third party developer I view as a disaster. However I'm still hopeful, the phone has these widgets you see...
Andy Ihnatko of the Chicago Sun Times is one of the select few to have been hands on with the iPhone, and he's managed to confirm that while the iPhone widgets aren't exactly the same as OSX's Dashboard widgets, they do use the same technology. You can also build them using Dashcode, although presumably not the currently released version. As Andy says this really does hold out the hope that the widget layer at least will be open to third-party developers.
Showing posts with label Agile Development. Show all posts
Showing posts with label Agile Development. Show all posts
Friday, January 19, 2007
Friday, November 17, 2006
As agile as a herd of rihno?
Joel Spolsky is one of my favourite dispensers of wisdom, which is why it annoys me so much when he says something so obviously wrong, and especially when he contradicts himself doing it...
This week I've spent most of the week locked in my office with my headphones on hammering out new code, actual new code, to do actual new things I couldn't do before. That felt good, its not something I get to do that often any more now I'm hip deep and sinking fast in operations.
As a project matures more and more time gets sucked into maintenance, support and making sure things only break when you expect them to break. Adding features becomes an incremental thing, but sometimes you get the chance to crank out a really big block of code. These chances don't come along that often and shouldn't be squandered. By ignoring several moderately important "other things", I've managed to compress a month long project and a seriously large chunk of code into a weeks work.
That just wouldn't be possible if I'd had to context switch that much. For really short context switches like people ignoring the sign on my door telling them to go away, or a quick email response, I've found that pausing the music I'm listening to, dealing with the interruption, and them restarting the music will allow me to "check point" the state my head is in and the data structures I've built there while I'm working. I'll still loose ten or fifteen minutes because I won't be rolling along at full speed any more, but the damage is fairly limited.
Longer switch outs are more problematic, in fact there was one point this week where I had to drop what I was doing and do something else. It took me two hours, and then it took me another six hours to carefully reassemble the pile of stuff in my head and get back to where I was before I was interrupted. So that was eight hours gone because I had to drop what I was doing for two hours, there isn't such a thing as a short interruption when you're coding, not really...
I'm all for agile development, but agile development shouldn't mean that you get locked into endless fire fighting or you'll never get those big features out the door.
This week I've spent most of the week locked in my office with my headphones on hammering out new code, actual new code, to do actual new things I couldn't do before. That felt good, its not something I get to do that often any more now I'm hip deep and sinking fast in operations.
As a project matures more and more time gets sucked into maintenance, support and making sure things only break when you expect them to break. Adding features becomes an incremental thing, but sometimes you get the chance to crank out a really big block of code. These chances don't come along that often and shouldn't be squandered. By ignoring several moderately important "other things", I've managed to compress a month long project and a seriously large chunk of code into a weeks work.
That just wouldn't be possible if I'd had to context switch that much. For really short context switches like people ignoring the sign on my door telling them to go away, or a quick email response, I've found that pausing the music I'm listening to, dealing with the interruption, and them restarting the music will allow me to "check point" the state my head is in and the data structures I've built there while I'm working. I'll still loose ten or fifteen minutes because I won't be rolling along at full speed any more, but the damage is fairly limited.
Longer switch outs are more problematic, in fact there was one point this week where I had to drop what I was doing and do something else. It took me two hours, and then it took me another six hours to carefully reassemble the pile of stuff in my head and get back to where I was before I was interrupted. So that was eight hours gone because I had to drop what I was doing for two hours, there isn't such a thing as a short interruption when you're coding, not really...
I'm all for agile development, but agile development shouldn't mean that you get locked into endless fire fighting or you'll never get those big features out the door.
Subscribe to:
Posts (Atom)