I went to Open Web Vancouver 2009 last week. It's a two day, low-key conference about open technologies for developers, testers and others at that level of the business. It's a very well-run, well-attended and interesting conference, and very inexpensive.
The most interesting thing I heard about was PhoneGap. It's JavaScript that runs on all the major smart phones, so you have fewer cross-platform issues. And it gives web applications access to some of the functionality in the phone not normally accessible to a web application. On the iPhone, this means the current location and vibration.
There was a good workshop with City of Vancouver staff about their recent direction to open up the city's data, as well as moving to open standards and open source software. The first priority is the data. They're hoping that people will take the City's data and mash it up in useful ways. There's a Google Group about this at http://groups.google.com/group/vancouver-data.
18 months ago there was a lot of stuff about Ruby on Rails at this conference. This time the Drupal community was big. There was a presentation from Momentum magazine about how a volunteer built their website in Drupal. I thought they'd found money to have a professional develop the site, it's so good.
And Mozilla Messenging (i.e. Mozilla Thunderbird) is based in Vancouver. Who knew?
Showing posts with label Software Development. Show all posts
Showing posts with label Software Development. Show all posts
Monday, 15 June 2009
Thursday, 13 March 2008
Why Open Source is Better for Us All
I just read a very interesting way of looking at how open source creates a fundamental shift in the factors that drive software acquisition. Given that much of what's wrong in IT is about the relationship that customers and software developers are driven into by the economics of developing software, I really like the ideas in the post.
Friday, 1 February 2008
AJAX Security
It seems like every time I get to the point where I think I might get excited about writing a web application, I listen to a podcast about the abysmal state of security on the Wild West Web. The technology has to be made secure. We can't rely on programmers to do the right thing because we're human and we'll mess it up from time to time.
Tuesday, 22 May 2007
Why Agile Software Development isn't More Prevalent
I believe that agile software development leads to better software faster and therefore cheaper, and I think there's a lot of evidence to support that. So why, some seven years after the Agile Manifesto and many years after people started to do agile development, aren't the practices more common?
One factor that I think can't be underestimated is that agile pushes software developers and their managers out of their comfort zones way too much. Most development managers are more comfortable providing estimates up front and then reporting for most of the project that, "everything seems to be on track." At the end of the release cycle you have a period of discomfort, but that discomfort is mitigated by all the effort being put into getting the team to "pull it off."
Compare that to having to say early in the development cycle that, "we can already see that we're not going to get all the features in time, so do you want to drop features, and which ones, or do we move out the date?" That's way more uncomfortable because it's likely to be met by, "No to both." Then what do you do?
For developers, it's much more comfortable to just code what the Business Analyst told you to code, without having to address whether the user will deal with it. Moreover, why would a programmer want to produce code faster and cheaper? They get paid no matter how much work they do. Why would they want to even measure speed, as that could lead to being compared with their colleagues? It's much more comfortable to not even look at how fast the programmers are going.
Of course, successful agile organizations address these points. If you're looking at trying to make a non-agile organization more agile, you need to consider how really big a task you're setting yourself. It's hard to get people to change if they're not motivated to change, and the people who have to change to become more agile are actually motivated to do quite the opposite.
One factor that I think can't be underestimated is that agile pushes software developers and their managers out of their comfort zones way too much. Most development managers are more comfortable providing estimates up front and then reporting for most of the project that, "everything seems to be on track." At the end of the release cycle you have a period of discomfort, but that discomfort is mitigated by all the effort being put into getting the team to "pull it off."
Compare that to having to say early in the development cycle that, "we can already see that we're not going to get all the features in time, so do you want to drop features, and which ones, or do we move out the date?" That's way more uncomfortable because it's likely to be met by, "No to both." Then what do you do?
For developers, it's much more comfortable to just code what the Business Analyst told you to code, without having to address whether the user will deal with it. Moreover, why would a programmer want to produce code faster and cheaper? They get paid no matter how much work they do. Why would they want to even measure speed, as that could lead to being compared with their colleagues? It's much more comfortable to not even look at how fast the programmers are going.
Of course, successful agile organizations address these points. If you're looking at trying to make a non-agile organization more agile, you need to consider how really big a task you're setting yourself. It's hard to get people to change if they're not motivated to change, and the people who have to change to become more agile are actually motivated to do quite the opposite.
Subscribe to:
Posts (Atom)