the mantra...
Passed down to me by the senior dude when i first started working...
"On time, on spec, on budget. Pick any two..."
Anyone have similar experience...;-)
P.
Erik Meijer: AGILE must be destroyed, once and for all
A couple of months back, Dutch computer scientist Erik Meijer gave an outspoken and distinctly anti-Agile talk at the Reaktor Dev Day in Finland. “Agile is a cancer that we have to eliminate from the industry," said Meijer; harsh words for a methodology that started in the nineties as a lightweight alternative to bureaucratic …
-
-
-
Thursday 8th January 2015 13:58 GMT DropBear
Re: the mantra...
Indeed. Problems appear when management inevitably decides that such a "negative attitude" is unacceptable, and both three shall be satisfied, or else. Predictably this works about as well as throwing a tantrum about working warp drives and teleporters to be produced at once, except one can't actually explain that to management - they exist to communicate decisions to you, not to let you talk back.
-
-
Wednesday 28th January 2015 09:01 GMT kiwimuso
Re: the mantra...
@ phil dude
Shit mate, I don't know where you worked but when we were writing Assembler on an IBM mainframe for an airline back in the day before "organised" management came into play, we ALWAYS got all 3 right on target.
It's when the "professional managers" were involved and they brought in all the meetings to report 'progress' and multi-level management of a project that it all got fucked up.
We spent more time on so-called project management which in my experience, simply added more time and expense to the overheads.
I can quote, without mentioning any names, that I was involved in a project involving international companies, which we managed to complete in 6 months for a cost of around a quarter of a mill, while our opposite numbers spent several million and took well over 12 months to complete.
Bullshit costs money!!
Just my humble opinion but then I am now safely retired, and so obviously old-fashioned and 'out of touch' so I MUST be wrong!!!!
Back then Agile wasn't a concept, it was the normal way of working.
-
-
Thursday 8th January 2015 12:12 GMT Voland's right hand
A few good pints
The few good points he has made are not sufficient to result in the summary conclusions.
Scrums suck, no doubt about it. I have yet to see a scrum that is not a waste of time.
Test driven development as used in most companies does so too because in most cases developers write tests to test a piece of code and NOT THE FAILURE CONDITION BEHAVIOUR. However test driven development does not suck as a general rule - it is doing it wrong which sucks.
Other elements of agile - retrospectives, etc are quite useful when done properly.
-
Thursday 8th January 2015 13:24 GMT breakfast
Re: A few good pints
Even just working with the success paths, if you're building the foundations of a larger application having plenty of unit tests is by far the best way to ensure that it at least works to some degree. You won't catch all the problems that the system will encounter in the real world, but if you don't have the test suite in place, loads more problems will be encountered further down the line. I have no strong opinion whether you write the tests or code first, as long as they are written in close proximity to one another, but unless you have unit tests for most of your logic, you're lining yourself up for unnecessary pain.
Also putting an automated test in to catch bugs once they're identified is a great way of ensuring you don't inadvertently put them back in later. In an ideal world nobody would do that, but it turns out that some things about the world are less than ideal.
-
Thursday 8th January 2015 17:41 GMT thames
Re: A few good pints
I think the real problem is the cargo cult approach to any methodology that is taken by many users. The problem is exacerbated by consultants who make a living telling people the "right" way to do whatever is fashionable at the moment.
There's no one right way to do things in all cases. As was said years ago in a different context "there is no silver bullet". Managers and developers still have to know what they are doing, and they have to apply techniques that are suitable to the project at hand within the industry they are operating in and appropriate to the size of the team and the personnel involved. In other words, we need competent people and they have to think about what they are doing.
The main problem that people have with unit tests is writing them to satisfy a "code coverage" metric rather than using them to find problems. In other words, a useful tool has become subverted because process is elevated over result.
And that pretty much sums up with what has happened to agile in general. It has been systematized into the antithesis of what it was supposed to be, which is the elimination of bureaucracy so that people can get on with the job of producing something useful.
-
Friday 9th January 2015 10:03 GMT GitMeMyShootinIrons
Re: A few good pints
"I think the real problem is the cargo cult approach to any methodology that is taken by many users."
Well said. I once had to tell a project manager in rather blunt terms that PRINCE is not a religion.
Try processes, sure, but drop what isn't working. Don't keep it purely out of stubbornness.
-
-
Thursday 8th January 2015 22:07 GMT JohnMcL
Re: A few good pints
A software tester friend of mine refers to Agile as Fragile (and he has an alternative and shorter word for Scrum) . Testing is a nightmare when the client keeps changing his mind about what's wanted and there's either no written specs or the specs keep changing. Also, software testers are almost as rare as hen's teeth and yet every Fragile project needs at least one tester.
-
-
Friday 9th January 2015 13:52 GMT Anonymous Coward
Re: A few good pints
Having worked as a test engineer on both Waterfall, PRINCE2 projects, and with Agile, Scrum, projects, I have to say this isn't my personal experience. As a tester, I want to get my hands on the code as soon as the dev is done with it. If I find any problems, I can talk to them while the code is still fresh in their mind, retest any fixes as soon as possible, and just generally keep the cycle as tight as possible. In my fairly considerable experience, these short cycles are far easier to create and maintain in agile dev environments.
The hideous, pre-agile, old school way of getting a code drop for test with hundreds of bugs and features meant that by the time you uncover an issue, the devs already re-factored the problem code creating further newer bigger issues without having realised the problem, then moved onto some other feature and forgotten all about the nugget they were working on.
I never again want to be working crazy hours to get everything done in the compressed 'testing phase' because the dev time took longer than planned, but the release milestones had already been agreed.
As a tester I absolutely want the product owners to be able to change their mind after seeing something they don't like rather than stick with some decision made with limited information weeks ago.
Testers probably benefit more from iterative, agile workflows than anyone else on the team. I'd go as far saying a tester that doesn't like agile is probably doing it wrong.
-
Monday 19th January 2015 13:38 GMT Meerkatjie
Re: A few good pints
I'm a software tester and if I'm going to work on a bad project I would rather it be agile than waterfall.
I've recently finished a contract where almost no-one talked to each other and there were silos of control all over the place. The project was waterfall and most times I would pick up the specification and find the code didn't match, usually a month or more after it had been completed. Every time it would end up that the dev had 'interpreted' a different version of the spec and the business analyst had a version which was almost all in their brains. I spent most of my time during testing discovering specifications and what time I had remaining I would raise bugs that would be descoped and never fixed. Because it was waterfall both groups were reluctant to talk to me and discuss what it is they had done.
If it had been agile at least there would have been an expectation that they should talk to each other and me. There would also be an expectation that the code should be available to me sooner rather than later.
-
Friday 6th March 2015 15:33 GMT Anonymous Coward
Re: A few good pints
I've just finished up on a failed Agile/Scrum contract with exactly the same problems you mention. The day I started, I remarked that "this place is awful quiet, nobody talks to each other". Every new starter said exactly that same thing. The same lack of communication was flagged umpteen times including by fly-in management gurus. At every retro, someone forlornly would say our communication is getting a little better now" and I said, "it sure isn't" until I couldn't be bothered anymore. I counted at least 3 scrum gurus over a 2-month period. But nobody could fix this team.
-
-
-
Thursday 17th January 2019 12:09 GMT kadammanali987
Re: A few good pints
The SQA process has many times helped to find critical bugs prior to officially being released. Because of time constraints put on the developer, I do feel it is an essential process and the role of SQA Engineer is an essential role and will be for the foreseeable future.
I believe testing and that's still needed. Earlier testing was sole responsibility of testers now whole team is responsible.
Do we still need testers? Yes. Team consist all skills that require to code, test, deploy and maintain software.
-
-
Sunday 11th January 2015 20:07 GMT Michael Wojcik
Re: A few good pints
Scrums suck, no doubt about it. I have yet to see a scrum that is not a waste of time.
Your personal experience may not be definitive. We've been using Scrum for years, and I've generally found the daily scrums useful. I'm in three feature teams at the moment, which means 15 scrums a week; they rarely take more than fifteen minutes a day together, and I'd estimate at least one participant learns something useful about the state of the release in 10-12 of them.
By the same token, sprints (we usually run two-week ones) have been effective at keeping feature sets reasonable and ensuring complex features get broken down into small component features with good separation of concerns and well-defined interfaces, and making sure work-in-progress gets committed to source control and tested by the CI systems.
As usual, what we have in the story and comments are various people generalizing from their anecdotal experience and turning it into dogma. Unfortunately software-development culture not only allows but positively encourages this sort of grandstanding, and celebrates this sort of contrarianism as a good in itself.
-
Wednesday 18th February 2015 17:08 GMT Greg J Preece
Re: A few good pints
Your personal experience may not be definitive. We've been using Scrum for years, and I've generally found the daily scrums useful. I'm in three feature teams at the moment, which means 15 scrums a week; they rarely take more than fifteen minutes a day together, and I'd estimate at least one participant learns something useful about the state of the release in 10-12 of them.
Scrums are brilliant for team newbies. I'm a remote worker on a new dev team, and the daily scrums mean that there is a guaranteed 15-30 minutes* each day when all the busy people who already know everything about the system stop and talk about it for a bit. If I have a question on how to proceed, what something does, or I need help on some stack trace explosion that happened because silly ol' me dared to run "bower update", I can get assistance.
*10 mins of team updates, generally extended by a follow-on discussion on some aspect of dev
-
-
-
Thursday 8th January 2015 12:21 GMT Anonymous Coward
He advocates instead a “move fast and break things” model
This, and an apparent aversion to unit testing, is fine if you're writing apps to edit cute cat videos, less so if it's something I'm counting on for my life or livelihood. I don't think the idea behind Agile was to shove bug-riddled shit out the door as fast as possible.
-
Thursday 8th January 2015 13:08 GMT Mark 65
I'm willing to give the guy the benefit of the doubt and suggest he's implying that all code will invariably ship with bugs so shipping quicker and being more agile (for want of a better word) is preferable to the old bureaucratic bullshit methods whereby the fix came on some bizarre rolling interval after the issue. I've worked at places where releases could only occur once a fortnight. Period.
-
Friday 9th January 2015 09:09 GMT Matt Bryant
Re: Mark 65
".....so shipping quicker and being more agile....." Unfortunately, that is exactly the problem - senior management's perception of what agile (or any trend du jour) will deliver. The people that came up with agile thought an inclusive approach would lead to better/happier coding teams and therefore more successful projects. But what management hear is "agile means quicker results". In short, they believe agile will magically allow them to deliver the same product with the same resources in a shorter time (hence saving money), which, as any fule PM doth know, you get two of three not one for free.
-
-
Thursday 8th January 2015 13:34 GMT Charlie Clark
I'd don't understand how you can do "move fast and break things" without having unit tests. They seem pretty sine qua non to me, otherwise how do you know what's broken?
That said: tests are a development aid and a developer's friend and not an end in themselves. TDD can be a trap because without some code you won't really know what to test for. Better to write code/test couplets where the tests help you think through (and perhaps improve) the logic you've coded and then fix the implementation so that any breakages will be caught.
-
-
-
-
Friday 9th January 2015 04:06 GMT Eric Olson
Speaking as the requirements gatherer...
As a Business Analyst, I prefer the quicker turnaround times afforded by a sprint, as there is always going to be a change in what a requirement holder wants when even the most basic of features is demoed (or demoed as it self-destructs) in front of them. Having worked in a waterfall-esque environment where requirements documents contained a whole quarter's worth of development, to be delivered two quarters from now, it's impossible to keep the requirements to come in mind while gathering the requirements still needed (especially when there are multiple BAs working on a larger project). This goes double when there is migration from an existing app to a new one with different user bases, as you're also likely to run into duplication of requirements worded differently so you end up with two ways of doing similar things in the same application.
At the same time, I find that code fast and break things is a feature of the current agile-esque methodology at my new company. Things are produced, shit hits the fan, and we move on. Things break; it happens. That's why we hire support staff and keep the software architects employed.
-
Friday 9th January 2015 05:49 GMT Dagg
Re: Speaking as the requirements gatherer...
@Eric Olson - Speaking as the requirements gatherer...
Yea, the BAs like Agile as it means they don't need to do a proper job of collecting requirements. The approach appears to be "hey just throw some ideas over the fence to the development team and waste their time building crap to ill defined sh*t".
When stuff goes wrong they then blame it all on the developers...
-
Friday 9th January 2015 19:44 GMT Matt Bryant
Re: Erik Olson Re: Speaking as the requirements gatherer...
".... in a waterfall-esque environment where requirements documents contained a whole quarter's worth of development, to be delivered two quarters from now, it's impossible to keep the requirements to come in mind while gathering the requirements still needed....." The best PM I ever worked with was an old civil servant, he was strictly waterfall and no other, and he always added a section to the requirements doc he kept secret from the customer - the Wants. This was compiled from right at the start of the analysis phase and consisted of all the "wants" that anyone expressed but which didn't get actually made into firm requirements. Added to this was a good slice of political "likely-to-happens", which was a cynical look at the politics of the customer and associated risks. It was amazing how often his Wants section predicted the customer's (often many) requirements changes, but then one of that PM's skills was an absolutely brilliant way of getting inside the customer's head and understanding their real business drivers, environment and politics and not the bullshine the customer presented to us. Where possible, we dialled in the Wants into the design phase so that we could add them modularly if possible, then when the "unexpected" change in requirements arrived he could hum and haw, charge the customer for a massive redesign (which meant the sales team loved him too), extend the deadlines (so us grunts had extra time for quality control), and proceed with almost no change to the plan. The guy was a genius!
-
Sunday 11th January 2015 23:06 GMT Anonymous Coward
Re: Speaking as the requirements gatherer...
of course business analysts prefer agile. you get away with writing vague specs and chucking the risk over to the developers and testers.
when the shit hits the fan, users don't go back to reading your specs to work out what was agreed. and if they do it's so vague they read into it whatever they want.
no. what happens is the developers end up capturing the specs *you* were supposed to capture, the functionality has to be rewritten and the testers have to redo their tests (which they have to rewrite beforehand).
i've noticed a steep decline in the quality of output from business analysts since agile became popular. i've also noticed any idiot can (and does) train to be a ba when they appear to be unable to fulfill any other function in the company. rubbish at everything? you can be a ba!
apologies to all the good ba's. i know a few and they get lots of flack from the numpties who charge the same rates but struggle to tie their shoe laces.
-
-
-
-
Saturday 10th January 2015 20:40 GMT Anonymous Coward
On your Life...
Some of the code I write has other peoples lives hanging on it since it's used for medical decisions.
I really don't want to find myself hauled in front of a Fatal Accident Inquiry for a coding fault going live that's entirely avoidable with a tiny bit of effort.
But looking at the guys shirt in the picture he clearly lives in a fairly land of cute cat videos.
-
Thursday 8th January 2015 12:23 GMT dogged
Agile is just decent communication and getting dickwad project managers off your back so that you can actually take time to refactor code instead of just shoving hastily-written deadline-driven "just about good enough" code out into production.
Scrum is what happens when you let people are a) idiots b) Americans* AND c) in marketing get their hands on Agile and it should be burned with fire.
And Unit Tests are not about predicting failure conditions in live! They are about making each unit of code modular and robust
*seriously, nobody involved in the creation of Scrum had ever even seen a game of rugby. "Oh, it's named for the way a scrum runs up the field passing the ball to each other" - the fuck? Shut up and go away.
small mod tweak - fewer ad homs, please
-
-
Thursday 8th January 2015 13:05 GMT dogged
> Have you ever played rugby?
Every weekend for about half of every year since 1982, yes. A scrum does not run anywhere unless something's gone very badly wrong. A team does. A scrum does not. This basic lack of information is a fine example of the half-baked nature of everything about Scrum.
small note to mod - the ad hom was ad Erik Meijer.
-
Thursday 5th March 2015 10:45 GMT rusk123
I think the metaphor is appropriate but misinterpreted.
One of the key attributes of rugby is that the team is composed of specialists who co-operate within a rigid structure, and the emphasis is on team play. You can get by on a running/kicking game or if you've a heavy front line just steam-rolling the ball, but the best teams master the continuum between both, and thus draws in the entire team to the simple goal of getting the ball over the line.
The actual "scrum" itself is where play restarts. Your scrum-half (not sure if this is the scrum-master or product owner - I feel the latter is more like the coach) puts the ball in, you all push and squeeze a bit the ball is released and play continues.
I think the scrum itself is meant to be the standup, though many other aspects of the process (refinement, retrospectives, sprint planning) create this "pressure cooker" scenario, where the team comes together in uncomfortable yet intimate circumstance (anybody ever played lock?) as a punctuation between plays.
I suppose the process could have more appropriately been called "Rugby" (glaringly absent from the metaphor is the opposing team though), but I guess Scrum was more catchy and is probably the most
salient attribute of the sport to an outsider looking in.
-
-
-
Thursday 8th January 2015 13:20 GMT toadwarrior
Unit tests aren't a TDD only thing. His complaint was against TDD rather than unit tests.
However he has a point. A bad developer writing unit tests is pointless. If he writes bad code why on earth would anyone think he'd write good tests?
Moon pig uses TDD, C.I. and all those cool buzzwords and look how safe their api turned out.
Relying on the code writer to test his own code is just about pointless.
-
Thursday 8th January 2015 14:51 GMT Simon Harris
"Relying on the code writer to test his own code is just about pointless."
At the last place where we did Agile development, for any given module we'd split into pairs - one would write the module, the other would write the tests from the module specifications, ideally without knowing (apart from the interface definition) how the module was coded.
-
-
This post has been deleted by its author
-
Thursday 8th January 2015 13:45 GMT Bob Starling
"a scrum runs up the field passing the ball to each other"
I spend a fair bit of time watching rugby and it seems that these days a scrum is something that starts with an attempt at organisation that rapidly turns into a collapsed heap with a random assignment of blame and punishment as a result.
Come to think of it that's not a bad metaphor for a lot of software development but I don't think its something to aspire to.
-
Sunday 11th January 2015 22:32 GMT Paul Hovnanian
RE: Scrum
@Bob Starling
I think this is a good observation. The term 'scrum' appears to have been applied to s/w development by someone unfamiliar with software, rugby, or both.
Or perhaps it was coined by someone with a wicked sense of humor who was spot on with an analogy describing the butting of heads while the object (the ball, or the code) sits unmoved. And the term was sold to the PHBs with exactly this hidden meaning in mind. And management hasn't got the joke yet.
-
-
Biting the hand that feeds IT
