Comments on: 26 Hints for Agile Software Development

By: Rob Dean

Rob Dean — Mon, 21 Dec 2009 23:30:56 +0000

The point on YAGNI is well taken, and I am one of the biggest offenders, but there are many instances where I have antisipated a future need prior to the stakeholders identifying it. Adding this generalization has taken mere minutes when the rework of the application would have taken hours or days to do. I am a firm believer that most organizations believe that there’s never time to do it right, but there’s always time to do it over. That being said, everything is a balance, and it takes experience to understand where the line needs to be drawn.

By: David Pletcher

David Pletcher — Fri, 04 Dec 2009 03:42:53 +0000

I agree with the majority - most of these points while very useful are not particularly novel nor unique to Agile.

This is where Agile evangelists borrow practices - without correct attribution - and pass them off as something derived from the Agile cult of development.

By: Ran Jun

Ran Jun — Thu, 29 Oct 2009 03:48:53 +0000

I’m not very sure about this point: “Always run the tests before checking in. This guideline will help you satisfy the “never break the build” guideline.”

What does the “tests” mean? Unit tests? Or test cases? Can anybody clarify this?

By: Mr Magoo

Mr Magoo — Thu, 29 Oct 2009 02:05:52 +0000

Any list of general software tips for ANY of the software methodologies will have an overlap with something else. Pointing that out doesn’t really help.

I would also argue that even though the bullet point for a lot of these may be the same, the reasoning behind it and the implementation of the bullet point may be vastly different.

By: Ran Jun

Ran Jun — Wed, 28 Oct 2009 09:11:57 +0000

Thank you for the share, all of them are very valuable.

I agree that many of them are not agile-specific.

By: K Swenson

K Swenson — Thu, 22 Oct 2009 16:18:39 +0000

To your point, I would agree that about half of them could be considered agile-specific, and half might be equally applicable to any software project.

Consider a strongly Waterfall project. I am working with some teams in Japan that use a very strict waterfall model for development. To that team, about half of these are “surprising” and possibly even radical pieces of advice. Things like “write the test before the code” and “never implement before needed” are radical concepts to them. They pride themselves on “completeness” of implementation, to the point of inventing use cases which are not customer driven. The result is overbuilt code, another kind of waste. They wait 6 months sometimes to implement the tests. To those implementing in strict waterfall, the test is a “crutch” that should not be needed by developers doing their job correct. Surprising?

Probably you, like I, find the agile approach to be “normal” and perhaps have been using this for many years. I have been developing software since 1988 in a distinctly agile method. Many of these pieces of advice were second nature to me, until I saw a team that was not only not doing them, but actually making it a goal to work completely counter this advice.

Most important, though, glad you find these hints generally useful.

By: Scott Duncan

Scott Duncan — Thu, 22 Oct 2009 11:18:14 +0000

I do not fundamentally disagree with any of these ideas, but what makes most of them Agile-specific? These are ideas that have been recommended regarding software design and development for a couple decades at least. (One, writing tests before code, was not widely written and talked about, I don’t believe, until Kent Beck’s first edition of eXtreme Programming Explained.)

Now, they can all certainly help an organization “be agile,” but I do not see anything in most of them that uniquely grows out of the Values or Principles of the Agile Manifesto.

Articles and books from the 80’s cover almost all of these ideas. People such as Kernighan and Plauger wrote of them. The Unix environment produced ideas like “small is beautiful” and “make it work then make it fast.” Various O-O approaches suggested ideas related to classes and use cases.

Again, the advice is fine, but attaching “Agile” to them doesn’t seem to me to add anything valuable.

They are “26 Hints for Software Development.”