Rock!
I get the feeling there is some weird backlash against all things Agile lately. I've noticed it particularly in reddit comments.
I suspect it's young people who just weren't around before Agile.
I get the feeling there is some weird backlash against all things Agile lately. I've noticed it particularly in reddit comments.
I suspect it's young people who just weren't around before Agile.
XP was one of those things that prompted the creators to get together and formulate what they all had in common compared to traditional methods. This is what resulted in the Agile Manifesto.
The backlash if mostly against the consultants and pointy-haired-bosses that cherry picked from various Agile practices the things they could grok, and implemented that as a cargo cult solution.
In wider IT world, that cargo cult method has become known as "Agile", just like "hacker" now equals "cybercriminal" for the rest of the world.
* "move fast and break things" or
* "testing is the end user's job" or
* "what we were doing before, except with morning meetings where nobody is allowed to sit"
I expect some of the backlash is, ironically, against that.
It's similar to "devops" in this respect - a lot of people pretend to adopt the buzzword and then do almost the exact opposite of what it proscribes.
* "Bring in process-fascist SCRUM(tm) masters to put all creativity to a halt"
I've seen it, and it is the complete opposite of the Agile Manifesto's "Individuals and interactions over processes and tools".
Every time you code (whether requirements are clear or not), you go through the following steps (often executed in the space of 2-3 minutes):
1) Think 2) Write code 3) Build/run code 4) Test and see the outcome 5) Go to step 1
Even if you are not writing tests, you are doing step 3 and 4. Moreover, if you are not writing tests, you are doing steps 3 and 4 manually.
Manual is only quicker if there are a few of these iterations. If you are doing this iteration every 2-3 minutes, you will be doing it hundreds of times a day and thousands of times in total over the course of a project.
Automating that process will save you a lot of time in the long run, and will still save you time in the short run, as well as leading to higher quality code.
If I'm writing a library to add two numbers, it's easy to create fast tests with no false alarms. Assert.equals(10, new BigDecimal(5).add(new BigDecimal(5)) - simple, fast, no false alarms, easy-to-maintain.
Now imagine you're making a website and you want to test with multiple browsers, and it uses caching and connection pools and sessions and whatnot, and the website has several dozen pages, and there are a bunch of configuration options and feature flags and you need to test with all of them.
Now all of a sudden you're administrating a pool of VMs with different OSes, writing web-scrapers, launching web servers every test cycle, waiting for tests of pages you haven't changed, running n tests * m pages * o server configurations * p clients, and all of a sudden you're spending more time keeping your tests working, or changing your software so tests run faster, and you're hardly spending any time working on features users want.
Naturally, to someone writing the first type of software, unit testing seems perfectly logical. But I can also see how someone working on the second type of software might get frustrated!
Part of the point of unit testing is that you keep the 'unit' under test to be as small as possible so you don't have these sorts of problems and can run tests as frequently as is useful. It doesn't remove the need for other types of testing suites, but they can be isolated and run at separate times.
You're right - it eats a lot of time and it shouldn't. It's not as easy as unit testing and it should be.
I actually wrote an open source testing framework to handle this type of thing precisely because I was getting so frustrated with having to rebuild the boilerplate code to do this everywhere I went.
This is a simple example test I made with it - it uses a browser (w. selenium), libfaketime, and a mock SMTP server to test a django/celery/postgres/redis app:
https://github.com/crdoconnor/django-remindme/blob/tests/tes...
And this is the harness - it runs 5 services and a browser in 50 lines of code:
https://github.com/crdoconnor/django-remindme/blob/tests/tes...
The framework is currently in pre-alpha now, but it should be a bit more stable in a few weeks. It should be usable to test virtually any kind of software that runs on UNIX, also (not just python apps).
Easily handling the "m pages * o server configurations * p clients" problem is on the roadmap. Different browsers and server configurations will be treated as "just another kind of fixture", and it will be easy to feed fixture groups so that you can run the same automated test under multiple scenarios.
Consider the problem of intersecting two arbitrary 3D surfaces to get a curve. There are an infinite number of possible inputs. Except for rare simple cases, for each pair of inputs there are an infinite number of valid approximate solution curves AND an infinite number of ways to express each of those curves. Also, you want solutions which are well-behaved -- no kinks, no singularities, etc -- and as simple as reasonably possible (but no simpler).
And even that's still better than something like MP3 encoding or digital musical instrument UI testing, where the quality of the result is arguably subjective...
I was around before Agile became the thing that everyone was doing. Myself and many of my contemporaries are very cynical about it because what it most often seems to boil down to "what we were doing before but with more meetings and heavier process".
I've worked in places where Agile Evangelists would regularly take teams of people away from their desks for process-related meetings (retrospectives, planning, errr.... who the hell knows what else) for several hours at a time, more than once a week.
I've heard Agile consultants say things like "And the great thing about Agile is that if you start falling behind, you can take what you have to the customer, involve them in the process, and deliver even more at the next sprint!" as if it would miraculously provide extra developer time/effort for free.
And I've seen true-believers who seemed to think that if the project wasn't making progress then people probably just weren't doing 'Agile' hard enough, and probably needed even more meetings and process.
I like the manifesto. I don't like what often actually gets applied out in the field, and the consultants/evangelists are basically cultists AFAICT.
--edit-- I wouldn't claim to know about XP, I've never worked somewhere that embraced XP specifically, just places that decided to go 'Agile' and then proceeded to bog themselves down in so much procedure that projects started to fail.
I've only worked in one place where the morning stand-ups actually worked as they were intended - 5 developers go round the room, give a quick status and state any problems they have, identify who they need to talk to to get it solved, the get out again in under 10 minutes. Everywhere else I've worked they devolved into either developer chat/argument time or management info-broadcast time. For at least an hour. Every day. groan
As a result, many teams now insistently follow agile with a strong belief that it's the only way to make progress. They don't accept that before daily standups, people were still capable of communicating when they were blocked. Before sprints, people still came in every day and cranked out code. Before kanban boards and backlogs, people called them todo lists and often did have them in a shared document. Before 1-2 hour sprint planning meetings, people still had a strong sense of the direction of their project and the steps needed to get to a shippable state.
Agile defines units of work (the sprint, the story, etc) and sets up a fixed cadence for communication. It does not by itself create better code, better programmers, or better deliverables.
Now, I'm not anti-MBA. However, I do think that having people with engineering degrees be subordinate to people with MBAs is an outmoded business philosophy. They need to be more on par with one another.
Its not just the new blood. My sense is that people were sold agile as a silver bullet, and it unsurprisingly under delivered. Even with Agile+XP you still get bugs, delays and budget misses, the difference is that you know about it much earlier, which, in my experience doesn't make people as happy as I hoped it would.
I currently feel this way about Lisp too. I read the books, learned the basics, built stuff, even got a clojure job and, despite feeling better about my code, I'm struggling to provide measurable improvements over Java... but that doesn't mean I want to go back Java any more than I want to go back to 'not agile'.
A lot of projects would do good to have a light approach at spec writing, to get faced with problems before they're in code.
I'm unconvinced that a dev process is going to supersede dysfunctional technical management, no matter what we call it.
Sometimes requirements actually are set in stone and it's good to do this - I worked on an embedded device last year, with fixed interfaces and fixed security requirements. That project would have gone a lot faster if there had been an effort to explore and document these at the beginning.
--edit-- oh, and of course, agile projects never, ever miss deadlines...
Someone will undoubtedly come and reply to this saying that those places weren't really doing Agile, but that's irrelevant. They were claiming to do Agile, they paid some expensive consultants to train them on Agile, so from their perspective, they're Agile.