Alan Dean - All Comments

On RESTful Basket State

Alan Dean — Sun, 09 Nov 2008 17:09:19 GMT

In two previous post (" When Basket Checkout isn't RESTful " and " What a RESTful

On RESTful Basket State

Alan Dean — Sun, 09 Nov 2008 17:09:17 GMT

In two previous post (" When Basket Checkout isn't RESTful " and " What a RESTful

What a RESTful Basket Checkout might look like

Alan Dean — Fri, 07 Nov 2008 19:31:59 GMT

In my previous blog post, I discussed " When Basket Checkout isn't RESTful " so here are

re: Native VHD Support in Windows 7

Pooya — Tue, 04 Nov 2008 17:05:17 GMT

Interesting, thanks.

Now that native VHD is going to be supported, it was good also if Microsoft could add native virtual machine support to Windows 7 or a later verion, so that for instance 2 operating systems could run at the same time without a need for another tool such as Virtual Server.

Boot to VHD and Boot to VHD in Parallel

Bookmarks about Scalability

Bookmarks about Scalability — Fri, 24 Oct 2008 23:00:18 GMT

Pingback from Bookmarks about Scalability

re: Agility is not Viral

aland — Tue, 14 Oct 2008 10:00:21 GMT

To your first question, I would say that I have seen the productivity of non-alpha staff increase by using agile techniques and practices so I don't think it is simply down to alpha geek productivity.

To your second question, I would make the observation that it is very easy to be busy and not make progress at the same time. Following ineffective practices will make you ineffective and non-productive.

Finally, I agree that success is typically down to hard work alongside talent but that doesn't imply that we cannot all improve our practices.

re: Agility is not Viral

alistairl — Tue, 14 Oct 2008 09:24:49 GMT

Your post raises two interesting questions. To begin with, is the success of agile down to agile itself, or the hard working so-called "alpha geeks" that you mention in your article?

Secondly, if teams regress to old habits - and this is because they are busy, what are they busy doing?

My own answers would be - I think the major degree of success in any project is down to the hard working talent on the team. Secondly, the team is wasting time.

re: Agility is not Viral

aland — Sun, 12 Oct 2008 12:24:20 GMT

Interesting. I have never been comfortable with the term 'Agile' in a development context either, although for different reasons to you.

For me, 'Agile' feels like a term invented because 'extreme programming' sounded too scary to "the suits" in the business. I could live with the buzz-wordiness of it if it carried a strong semantic, but it doesn't. Agile seems to mean whatever someone wants it to mean (it's a bit like SOA in that way).

However, I fear that the ship has sailed on the semantics of Agile and on our ability to replace the term. In conversation I tend to try to use the phrases 'introducing agility', 'embracing change' or 'continuous improvement' instead of Agile. I do so because I am not a fan of 'off the shelf' methodologies which is what I see far too much of in Agile these days. That and the seemingly inevitable accusation that you are 'not Agile' if you are not doing {insert protagonists favoured practice here}.

Having said all of the above, I do think that there is value in a non-development-centric approach which can be exemplified by the Charteris byline of "enabling the agile enterprise" as this speaks to my view about enculturing organisations. Further building our capability to achieve exactly that is something that I care passionately about and was the driver for my presentation.

re: Agility is not Viral

David Oliver — Sun, 12 Oct 2008 11:54:37 GMT

I agree wholeheartedly ... people are lazy ... they will always take the quickest path even when it isn't best for them in the long run. It is like getting more exercise, you know it is good for you and you will feel far better for doing it but sitting in-front of the TV with a coke, crisps and choc-bar sounds like a far more appealing idea.

My problem with Agile development is calling it 'Agile'. It is in every-way very descriptive and therefore logically correct word to use but on a human level it does sound pretentious, marketeerial and a techno-buzzword to be hated by everyone that isn't a geek. I think we would have a much better chance at wholesale adoption if we also changed the name.

re: "Separating REST Facts from Fallacies" voted onto the DDD7 agenda

aland — Sat, 11 Oct 2008 11:37:29 GMT

Sorry, I don't know. The news spreads like wildfire when they do open registration though.

re: "Separating REST Facts from Fallacies" voted onto the DDD7 agenda

Pooya — Sat, 11 Oct 2008 11:18:07 GMT

Thanks Alan,

Do you know when the registration will open? I saw no clue on the site!

re: "Separating REST Facts from Fallacies" voted onto the DDD7 agenda

aland — Fri, 10 Oct 2008 14:08:22 GMT

Yes, you will need to register when registration opens. You need to be quick off the mark though - last time all the places went in about 4 hours.

re: "Separating REST Facts from Fallacies" voted onto the DDD7 agenda

Pooya — Fri, 10 Oct 2008 13:56:50 GMT

Hi, don't we need to register to come?

re: Principles and Axioms

David Oliver — Sat, 09 Aug 2008 11:50:29 GMT

You could go one step further and do alternative databases and BPM engines as well.

re: Principles and Axioms

Glenn Block — Tue, 22 Jul 2008 19:32:50 GMT

The list implies that some things on the list are mutually exclusive though they are not.

For example TFS vs user scenarios on story cards. You do not have to do one or the other, you can do both. For example p&p practices uses XP yet also uses TFS for workitems. Stories and Epics tend to be more coarse grained than workitems. You can start with cards, and then create work items in TFS that correspond. You can do this on an incremental basis.

The implication is that it's a black and white decision and that you cannot mix and match. The reality is that you can mix and match based on the needs. This story continues to improve with frameworks coming out of Microsoft like MVC which can integrate well with open-source containers like Castle, Structure Map, etc.