Non Agile Technical Roles

[Dark Black]

Yes indeed.

And, for example, wasting my time on voting for what feature of the last sprint should appear on the "cool wall" during a sprint retrospective is NOT what I ever signed up for.

This...

And don't get me started on "planning poker"... I nearly fell off my chair laughing the first time a client brought the decks of cards out..

[ChrisFromGreece]

Yes indeed.

And, for example, wasting my time on voting for what feature of the last sprint should appear on the "cool wall" during a sprint retrospective is NOT what I ever signed up for.

Hahah... whoever runs your retrospective, tell them to read on what this meeting is about!

[LondonManc]

It is indeed a bit extreme, since it's nowhere prescribed as part of any agile process (as far as I am aware).

Yet am an advocate of less comments than more in the code since it quickly becomes noise. Code should be self explanatory... if you need comments all over the place, then maybe you need to rethink the design?

Comments should include things like design decisions - while any SQL developer worth their salt should be able to understand what it does, it's important to know why it's doing it. If there's minimal documentation barring a user story on a board that simply talks about what should be done, you're leaving yourself wide open.

[ChrisFromGreece]

Comments should include things like design decisions - while any SQL developer worth their salt should be able to understand what it does, it's important to know why it's doing it. If there's minimal documentation barring a user story on a board that simply talks about what should be done, you're leaving yourself wide open.

I would go for "just enough" documentation; enough that makes sense for the project/situation.

Am not against documentation at all, so don't get me wrong here. And I totally agree with the design decisions being documented. I just don't know if the code is always the best place to document that.

[eek]

My last contract, the code review would pull up anyone who commented their code. Part of the agile process was to not comment code, it was seen as a pointer to obscure code and a time waster.

I guess the logic there is that all classes should be single task, max 20 lines and simple enough that no comment is required as the class name should be enough.

The fact it results in 400 classes (most of whom are used only once) rather than 20 is neither here nor there...

[ChrisFromGreece]

I guess the logic there is that all classes should be single task, max 20 lines and simple enough that no comment is required as the class name should be enough.

The fact it results in 400 classes (most of whom are used only once) rather than 20 is neither here nor there...

Replace class with method and should be ok no?

[VectraMan]

Comments should include things like design decisions - while any SQL developer worth their salt should be able to understand what it does, it's important to know why it's doing it. If there's minimal documentation barring a user story on a board that simply talks about what should be done, you're leaving yourself wide open.

WHS. "Just enough documentation" applies to comments too. The problem is when people think they should do comments you end up with "++x; // increment x", which is just a waste of bytes.

[LondonManc]

I would go for "just enough" documentation; enough that makes sense for the project/situation.

Am not against documentation at all, so don't get me wrong here. And I totally agree with the design decisions being documented. I just don't know if the code is always the best place to document that.

Out of interest, are you a developer, BA, tester?

[ChrisFromGreece]

Out of interest, are you a developer, BA, tester?

Technical Architect

[eek]

Technical Architect

That explains everything....