Developer using Agile

[doodab]

Yeah occasionally its quite good to work with someone on something, if its new to you or they have a lot of knowledge in this area.

Sometimes it's just good to bounce ideas off someone as well. No need when you're just doing the same old same old but when your diving into uncharted territory it helps clarify thoughts and spot obvious mistakes. I'd not go as far as sharing a keyboard though.

[minestrone]

I would rather not have anything to do with agile dev departments really. They seem to have taken standard practices of old rehashed as 'agile principles' mixed with just plain fooked up ideas and have a fair share of fookin twats involved in running the shop.

People tested code, shared idea and group worked in programming long before all this happened. Agile fans paint this picture that we were somehow saved from a the medieval age by Kent Beck and his fookin' stand ups.

[doodab]

People tested code, shared idea and group worked in programming long before all this happened.

+1. Most of what works is good about "agile" is the same common sense stuff most people were doing all along anyway. The increased automation of unit tests & builds & continuous integration is nothing more than a logical step on from getting compilers to turn source into object code. It's the most natural thing in the world for a programmer to use a computer to automate oft repeated tasks after all. It lets us shift our focus away from minutae and think about more important things.

Like lunch

[d000hg]

Sometimes it's just good to bounce ideas off someone as well. No need when you're just doing the same old same old but when your diving into uncharted territory it helps clarify thoughts and spot obvious mistakes. I'd not go as far as sharing a keyboard though.

Insist on using DVORAK

[doodab]

Insist on using DVORAK

I still have one of my laptops setup to switch into German with some key combination or another. It's a bugger for programming cos although the letters are mostly in the same place the various brackets and things are all over the shop.

[d000hg]

I've always heard that, but I've never seen it actually happening in my 20 years of doing this professionally. YMMV

As an aside, I'm amazed you managed that based on sheer statistics. IIRC you're more an old school C++ (even C?) developer and definitely long-running C/C++ projects tend to lag behind (or plain ignore) trends in software development "best practice" - but even so unless you work exclusively on legacy projects or in tiny teams in companies that don't really do software, it's quite an achievement!

[VectraMan]

As an aside, I'm amazed you managed that based on sheer statistics. IIRC you're more an old school C++ (even C?) developer and definitely long-running C/C++ projects tend to lag behind (or plain ignore) trends in software development "best practice" - but even so unless you work exclusively on legacy projects or in tiny teams in companies that don't really do software, it's quite an achievement!

Thankyou.

I've mostly worked for companies where the software is the main product, or part of the main product (i.e. with hardware as I'm doing again now). And they've tended to be small. What I haven't done is work for large corporates on their internal IT systems, which maybe is where the difference is. Small companies don't tend to have time for BS.

[VectraMan]

Then the team should also be rotated around the different areas of the system being built so that there are no silos of expertise.

That I'd agree with, though not with the appalling use of buzzwords. But that's just good management (lacking around here). The problem is process; somebody comes up with one, like everybody has to work in pairs, or everybody has to have their code reviewed every day, and then completely take their eye off whether it's actually doing anything beneficial or just getting in the way. And process that gets in the way generally pisses people off, which means it becomes a box ticking exercise, which I've seen many times. Once you have people required to "sign off" things, then quality tends to go out of the window.

[TheFaQQer]

Thankyou.

I've mostly worked for companies where the software is the main product, or part of the main product (i.e. with hardware as I'm doing again now). And they've tended to be small. What I haven't done is work for large corporates on their internal IT systems, which maybe is where the difference is. Small companies don't tend to have time for BS.

All my clients have been large corporates, and I think the last time I was on a project where there was any meaningful code review (so ignoring the one check I mentioned above to reformat the code from ANSI syntax to proprietary syntax) was when I lead the development team in 2006 and insisted on it because of the calibre of some of the developers.

[gardener]

I would rather not have anything to do with agile dev departments really. They seem to have taken standard practices of old rehashed as 'agile principles' mixed with just plain fooked up ideas and have a fair share of fookin twats involved in running the shop.

People tested code, shared idea and group worked in programming long before all this happened. Agile fans paint this picture that we were somehow saved from a the medieval age by Kent Beck and his fookin' stand ups.

It is our industrys' pop culture. Has nothing to do with agility obviously. Has a lot to do with incompetent looking for a recipe to follow.

Kent Beck is a cheesy fook, very american, egomaniac. He did say some reasonable things though.