Linked by snydeq on Tue 2nd Nov 2010 23:08 UTC
General Development InfoWorld offers a look back at the first decade of agile programming. Forged in February 2001 when a group of developers convened in Utah to find an alternative to documentation-driven, 'heavyweight' software development practices, The Manifesto for Agile Software Development sought to promote processes that accommodate changing requirements, collaboration with customers, and delivery of software in short iterations. Fast-forward a decade, and agile software development is becoming increasingly commonplace, with software firms adopting agile offshoots such as Scrum, Extreme Programming, and Kanban - a trend some see benefiting software development overall
Thread beginning with comment 448308
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: terrible article
by dpJudas on Wed 3rd Nov 2010 04:16 UTC in reply to "terrible article"
dpJudas
Member since:
2009-12-10

Not sure I agree.

Bad unit testing can be worse than no unit testing. Wasting your developers time writing a test that doesn't test anything properly is just a waste of time. Or worse, it tests that the code does what the code does thus making the test fail when you fix the code.

Even worse, an unit test is often described as the holy solution to all bugs, which again makes a lot of developers stop thinking about how to write resilient code. The unit test is supposed to find the bugs in it anyway. When the program then crashes at the customer, they conclude the unit test wasn't good enough instead of the way the code was written.

This is not to say that unit tests don't make sense, but I find the very overrated personally in the same way code reuse is often considered more important than any other requirements.

Reply Parent Score: 3

RE[2]: terrible article
by Gunderwo on Wed 3rd Nov 2010 05:05 in reply to "RE: terrible article"
Gunderwo Member since:
2006-01-03

In my experience there are a lot of companies that say they use Agile methodologies and do TDD when all they're doing is paying lip service to the buzz words that make them feel better.

In order for agile methods to work the developers and managers need to actually understand the how, and why of each step and do it right otherwise it's just adding extra overhead.

I've worked at several places that will SCRUM but then never do burndowns and calculate velocities. Or think that because they didn't get everything done in a sprint they can just add the missed tasks to the next sprint and end up in the same place at the end of the next one.

Bad management is bad management no matter what the buzzword methodology being used. And bad developers will always be bad developers if they don't try and learn how to become better.

Edited 2010-11-03 05:06 UTC

Reply Parent Score: 8

RE[3]: terrible article
by Tuishimi on Wed 3rd Nov 2010 06:52 in reply to "RE[2]: terrible article"
Tuishimi Member since:
2005-07-06

I would have voted this up but I already commented...

I can see that agile has benefits but only if it is done right and if everyone involved in a project knows and understands the process and tools well.

I come from the "old school" ways... it has been difficult but not impossible for me to latch onto this, but even I, with my minimal knowledge, see the process totally abused on a day to day basis... And let me tell you... a project run under the "agile" moniker but not REALLY is PAINFUL. I am in one of those right now.

Scrums break down into technical discussions, sprint planning becomes "this is what you all need to have done for this sprint"... etc.

I'd much rather do it the old way, spend time up front to use the old input-output requirements, functional specs/flow charts and design specs BEFORE we start coding so that it is clear as to what needs to be done.

No fancy terminology, meetings circumscribed by their purpose as they always were, development cycles demarked simply by deliverables, etc.

Now, I KNOW the agile process defines these things, but unless a company commits 100% to learn and implement it, it's useless.

Reply Parent Score: 5

RE[3]: terrible article
by Troels on Wed 3rd Nov 2010 09:43 in reply to "RE[2]: terrible article"
Troels Member since:
2005-07-11

Sure the methods can be abused and lead to horrible results, but i don't believe focussing on the burndown or velocity is really all that important.

Sure it is nice to know if you are on track or not, but what really matters IMO is breaking the projects into more mangeable sprints in the first place, dividing the developers into smaller groups that can have rapid communication, and the daily scrums that help catch problems before they get big, and of course the ability to quickly react when conditions change. Communication is the key word.

Reply Parent Score: 1

RE[2]: terrible article
by Troels on Wed 3rd Nov 2010 09:32 in reply to "RE: terrible article"
Troels Member since:
2005-07-11

Test driven development unit testing cant find all errors and is not meant to find all errors, if you try to make them do that, then you are doing it wrong. (not that there is anything wrong with systematic testing, but lets not confuse that with TDD or other agile methods)

The tests are mainly supposed to help you drive the code forward and let you refactor code while maintaining a reasonable belief that you have not broken anything.

Reply Parent Score: 2