Developer using Agile

[d000hg]

Company internal IT departments are normally where the worst offences occur, e.g. not using source control or any sort of issue-tracking system, the code only builds on one developer's machine, nobody knows which server is running the live code, etc

 

[original PM]

Belive it or not I am an Agile Practitoner PM (with certificates and everything).

There is no correlation between code reviews and Agile.

Code reviews for me are part of the dev teams QA if they do not do it and the code is crap it will be picked up and resolved during testing (or should!)

Agile is more about the way you approach the whole project in that very generally you expect to have numerous code drops and iterations as opposed to trying to gather all requirements up front and then developing to that even though it is often quite clear that that is not going to produce the desired effect.

Downside is that when people hear Agile they seem to think it means little to no requirements.

My twopenneth worth anyway.

 

[SpontaneousOrder]

I would rather not have anything to do with agile dev departments really.

This is the trouble with people (and it's amazingly pervasive in the Uk at least from what I've seen) who don't realise that there is no such thing as 'Agile'. (not necessarily you - i mean the departments you try to avoid)

Some guys knocked up the 'manifesto for agile software development' (note, no 'Agile manifesto') out of frustration at the state of the industry that they saw at the time, which was great. Nothing specific - just some general principles to aim for.

Then we also had XP and all of the associated goodies which are really just good engineering practises, but are essential if you actually want to achieve any real agility - you can't be agile if change is too expensive.

Then things like Scrum - which again is great. The Scrum guide is only a few pages, and exists as a mechanism to leverage the agility you've already built into your engineering practises. Scrum != agile. Scrum is a framework to leverage your agility, where the projects suited to Scrum.

At least 80% of people I work with these days have no idea what agility is. They get sent on a CSM course, or get 'taught' by someone who has been on one, and think 'Agile' is splitting work into 2 or 3 weeks chunks, moving coloured bits of paper around a board, having a chat every morning for 10 minutes, estimating in points (even if they simply end up mapping points to man-hours , and not documenting anything.

How many times have you heard someone propose doing something perfectly sensible, with the caveat "it's not very 'Agile', but..." ? Instant signal that they don't have a ******* clue what they're talking about.

Trouble is there's such an industry in being a snake-oil salesman now that I'm not sure that 'Agile' will ever be recoverable as a useful word.

 

[SpontaneousOrder]

There is no correlation between code reviews and Agile.

If anything the kind of code review the OP was talking about (where the senior guy edits it all afterwards himself) is anti-agile. How can he benefit from the introspection & learning which an iterative lifecycle at least partially promotes, if the code that gets dropped is never actually code he wrote himself?

Code reviews for me are part of the dev teams QA if they do not do it and the code is crap it will be picked up and resolved during testing (or should!)

Although there is a difference between good quality code insofar as it functions 100% correctly, and good quality code insofar as it functions correctly AND it fosters agility (or even just general long-term maintenance). In my experience code reviews tend to be aimed at that side of things, rather than catching defects (which as you say, tests are for).



Also, assuming the OP is in a Scrum team, then from a purist point of view it shouldn't really be the case that all code goes through the senior guy for review - there's no one person in charge in the team, and in this case one person is clearly in a position of authority.

 

[SpontaneousOrder]

What I've never got is why would you pay twice as much to get something done...

I can see the justification for doing it occasionally to bring someone up to speed but continually?

It's typically cheaper.

 

[v6g]

In my experience, the whole purpose of Agile is to create well-paying jobs for middle-aged men with no real skills.

On that basis, it is tremendously effective.

 

[doodab]

Although there is a difference between good quality code insofar as it functions 100% correctly, and good quality code insofar as it functions correctly AND it fosters agility (or even just general long-term maintenance). In my experience code reviews tend to be aimed at that side of things, rather than catching defects (which as you say, tests are for)

+1.

To me being agile is about creating code that not only works but that can easily be fixed, maintained, extended and grown and making those things a design goal. To that end a lot of modern techniques & tools such as IoC containers, automated refactoring, automated unit tests, code quality checkers, TDD, Continuous Integration etc serve a purpose and they serve it very well in that they automate a lot grunt work and facilitate an agile end product. Big A Agile & SCRUM etc are codified process stuff dreamed up by managermen in the hope of achieving small a agility. Some of it helps, some of it doesn't, and it depends more on who's doing it than the particular flavour they have chosen IMO.

The point of this level of quality control is not just to catch bugs but to ensure the code you have developed fulfills those other aims of being maintainable and able to cope with change so that it has a long shelf life. Testing will catch bugs but there is more to code quality than that and it takes other programmers to look at a piece of code and judge it's overall quality. It covers everything from basic readability such as formatting and having descriptive variable, parameter and method names, use of standard terms where appropriate e.g. pattern names, embedded documentation that actually adds value, doesn't confuse and isn't inaccurate, through to good OO programming practice and high level architectural concepts.

I'd also say that if you have quality people on your team you will often learn something from a code review. Certainly when I was younger I learnt a lot from having senior guys I respected give constructive criticism.

 

[doodab]

It's typically cheaper.

In the long run. Unfortunately too often those in charge think a development project means delivering release 1 by a certain date and don't consider the full service life of an application. I am lucky to work with a software house with a product roadmap so longer term thinking is part of the package and while we still have to meet immediate customer needs it makes life a lot easier.

 

[SpontaneousOrder]

+1.

To me being agile is about creating code that not only works but that can easily be fixed, maintained, extended and grown and making those things a design goal. To that end a lot of modern techniques & tools such as IoC containers, automated refactoring, automated unit tests, code quality checkers, TDD, Continuous Integration etc serve a purpose and they serve it very well in that they automate a lot grunt work and facilitate an agile end product. Big A Agile & SCRUM etc are codified process stuff dreamed up by managermen in the hope of achieving small a agility. Some of it helps, some of it doesn't, and it depends more on who's doing it than the particular flavour they have chosen IMO.

The point of this level of quality control is not just to catch bugs but to ensure the code you have developed fulfills those other aims of being maintainable and able to cope with change so that it has a long shelf life. Testing will catch bugs but there is more to code quality than that and it takes other programmers to look at a piece of code and judge it's overall quality. It covers everything from basic readability such as formatting and having descriptive variable, parameter and method names, use of standard terms where appropriate e.g. pattern names, embedded documentation that actually adds value, doesn't confuse and isn't inaccurate, through to good OO programming practice and high level architectural concepts.

I'd also say that if you have quality people on your team you will often learn something from a code review. Certainly when I was younger I learnt a lot from having senior guys I respected give constructive criticism.

The way I see it, you've got the manifesto with its general principles. That's it. That's as much as I'd ascribe to 'Agile'. Then you realise you can't actually be agile without those sound engineering habits. So most of those xp style goodies will be a core part of 'agile' out of necessity.

Then anything else like scrum us just a way to leverage that agility you've already built in. It makes no sense on its own which is where a lot fall down.


Not sure if I already said that - I'm on the beach using my phone. Squinting.

 

[d000hg]

In my experience, the whole purpose of Agile is to create well-paying jobs for middle-aged men with no real skills.

On that basis, it is tremendously effective.

Your experience says more about the kind of places you work than Agile IMO The places I've seen it used well have all been young enthusiastic teams.