I think this post is worthwhile because Steve works for one of the best software development companies around and because he's an excellent programmer with a lot of experience.
He obviously knows what he's talking about.
I think what's missing (perhaps because he's not the best person to describe it) is what a company on the wrong path can do to set things right.
Google has obviously made a very conscious effort to keep their successful model as they've grown, bit many companies (especially those not started by techies) have made bad decisions.
How can an IT department -- assuming the department itself gets it -- make things better?
Unfortunately, lame parties are about the extent of the power most IT departments (or development team managers) have. They can't shift the entire culture of the company or start handing out astronomical rewards.
There has to be a middle ground, and it's this middle ground that's so elusive.
I would be interested in hearing how anyone has driven or been part of a lasting, positive change within the confines of a larger organization.
the kinds of programmers who buy extended warranties and self-help books and believe their bosses genuinely care about them as people, the kinds of programmers who attend conferences to make friends
One of these things is not like the others. I have made many, many friends at programming conferences. I am not sure why you wouldn't expect this to happen.
I agree with you, especially with regard to open source related conferences (I've made great friends at PyCon); but perhaps there's a difference at the more old-fashioned corporate conferences?
Yeah, I didn't understand that either. Maybe it's because I'm a weirdo, but the main reason I go to tech conferences is to make friends, who inevitably turn into business partners and clients.
Great post, especially the bit about life at Google:
- developers can switch teams and/or projects any time they want, no questions asked; just say the word and the movers will show up the next day to put you in your new office with your new team.
- Google has a philosophy of not ever telling developers what to work on, and they take it pretty seriously.
It's brilliant management I think: Hire talented engineers, give them extreme freedom, and choreograph the dance with clever incentives...
I'm of the opinion that Agile(Big A) is very useful for creating a system between companies. When something is an agreement between companies you need some agreed and consistent method of working out what happens when and enforcing that afterwards. Agile is much better in these circumstances than waterfall.
Comparatively, in a startup or internal development project in a software company there is much more of an ability to not deliver a particular feature or spend more hours on it.
A startup is likely to find Agile far too slow; whereas, corporates are scared by how fast and fluid it is.
If anyone cares, I wrote an article for InfoQ around this time which gathered some of the better commentary: http://www.infoq.com/news/2006/12/future-of-agile (buyer beware: I am (or was, at least) biased in favor of agile methods).
these are the kind of discussions i find worthwhile: an honest look at how something works well and how something fails. too often i see blog posts pitting A against B, or simply claiming A sucks.
(i guess A v B is a good/bad look at a higher level concept C...)
I wish even agile had a different name, one that isn't so tempting for people to use incorrectly, with no clue that it means something other than "able to change direction quickly". I've heard (very non-technical) people cheerfully volunteer to clients and developers that the project they're involved with is "agile", but they just mean "we have no real plan, anything can change at any time" - they have no concept that there's an actual methodology being implied by what they're saying.
I think using a term like "fluid" would have similar results - "we're using a fluid methodology so our project will be able to flow around any obstacle/mould itself to any scenario".
On the other hand these ideas spread so well because it seems like they're easy to understand...the first thing you think of when you hear something like Rational Unified Process is men in white coats with pocket protectors.
I vehemently disagreed with this post when it was originally written, but then at the time I was just being introduced to Scrum. I've since come to understand his point, and oddly enough, the part at the end where he talks about project management via queue theory and index cards is precisely what my startup (http://agilezen.com/) is based on. :)
He obviously knows what he's talking about.
I think what's missing (perhaps because he's not the best person to describe it) is what a company on the wrong path can do to set things right.
Google has obviously made a very conscious effort to keep their successful model as they've grown, bit many companies (especially those not started by techies) have made bad decisions.
How can an IT department -- assuming the department itself gets it -- make things better?
Unfortunately, lame parties are about the extent of the power most IT departments (or development team managers) have. They can't shift the entire culture of the company or start handing out astronomical rewards.
There has to be a middle ground, and it's this middle ground that's so elusive.
I would be interested in hearing how anyone has driven or been part of a lasting, positive change within the confines of a larger organization.