Slashdot Mirror
A Decade of Agile Programming — Has It Delivered?
snydeq writes "InfoWorld offers a look back at the first decade of agile programming. Forged in February 2001 when a group of developers convened in Utah to find an alternative to documentation-driven, 'heavyweight' software development practices, The Manifesto for Agile Software Development sought to promote processes that accommodate changing requirements, collaboration with customers, and delivery of software in short iterations. Fast-forward a decade, and agile software development is becoming increasingly commonplace, with software firms adopting agile offshoots such as Scrum, Extreme Programming, and Kanban — a trend some see benefiting software development overall."
A team in my the company I worked for was designing a new set of software and were utilizing Agile development. Well, seems they spent so much time going back and changing the software due to the changing demands that they never got anything finished to demonstrate so they wiped out the project team.
I've worked in 100% waterfall, and in good agile environments, and I've found the key is to keep things small-a "agile", not to concentrate on capital-a Agile. Some places embrace Agile as a process, and fill binders with process documentation around their Agile process - at which point it's no better than any other.
I think the key to success is summed up in this line from T3FA:
In my experience, software development methodologies are more of a way of describing how teams already work. Sure you can put a name to it, polish it a bit, and other people can work toward that name, but there were tons of "Agile" projects and "Agile" groups before the manifesto. Maybe "Software companies" didn't do it before 2001 I don't know... but "software departments" of other companies have pretty much doing this since I have been around, which is a lot more than a decade.
The truth is that electronic delivery created agile development, at least for software companies. Internal departments have had the connectiviety for 2+ decades to deploy new releases often, but it wasn't till the late 1990s or early 2000s that a "boxed" software company could provide regular working releases to their customers (who wants to mail a CD or a stack of floppies every 3 weeks, and what customer would actually apply them?) Web-based apps and self-updating software just brought dedicated software development in line with corporate development practices, and then it was given a name.
2. It at least notionally asks the management to consider resources while committing to features.
3. It allows some kinds of software project to managed better. Things like merging products when companies merge, or when porting software to a new platform etc.
4. It works when the project has a large number of people with identical or largely similar skill sets. If the project has large number of specialists (like "Frank here is the only one who can even touch the turbulence modeling code") development will be slow, agile or not. At least the management should know not to commit to too many turbulence modeling features.
5. Rally proponents broad brush all skeptics as "people not willing to change".
6 Too many Rally concepts come from manufacturing and some of the examples and analogies don't even translate correctly. Take the famous, "burnt toast" example. A company decides to burn all the slices, and then scrape off the charred crumbs to get the color desired by each customer. Supposedly Rally will toast them right in the first try saving all the efforts that go into scraping off charred crumbs. Well, in software it does not cost me any money to char a toast and scrape the crumbs. Often times it is perfectly ok to render all the pixels of each body, even if another body is going to come back and override a lot or most the pixel later. You waste time trying to predict the final pixel value to render it just once.
7 Some times it is funny to see the Rally proponents not using Rally methods to develop their presentations, not using Rally for their own internal websites! Too many of them recite from a text book or a holy book instead of using actual code/project examples.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
I appreciate good management. I can live with no management, but I can't handle bad management.
SCRUM has sort of become a device for a manager to avoid managing. The human in the picture is replaced with a sprint chart and backlog tracker. It lets bad managers get by, while good managers are really thrown out of the picture.
I hated scrum in my old job. But the new job just throws out a list of features to implement, ranks it and throws it at one of us. There are no punishments for missing a day, no tracker to guilt-trip you and most importantly, the stand-up meetings are just before lunch. And mostly, serves to keep our communication channels open across the team.
I hated the time-keeping TPS report style scrum, but I'm cool with the new approach. I love the idea of sprints and taking a week out of a month to hammer something out. But this system only works with motivated teams with a fair scrum-master.
But I repeat, it is not a replacement for good management. It is as good as a way of letting me manage my tasks,but please (for the love of God, please) do not use it to manage me.
Quidquid latine dictum sit, altum videtur
From languages I've seen, programming has regressed in the last decade. When Grace Hopper wrote the first compiler, her dream was an english-like language that computers and people could both understand easily with a minimum of training. She co-wrote COBOL as the second compiler.
Older languages, like the mainframe DBMS NOMAD and the PC DBMS dBase were IMO brilliant. They needed little documentation, and no curly braces or other such nonsense you find in modern languages like C or Java.
The "language" I hate most is MS Access. Convoluted and unintuitive, you don't really write anything, and what's produced is "visual basic" and the equally unreadable SQL.
I hate it. I'd rather program in assembly, so I can know what registers are being accessed, whether I pushed or popped a stack (and which stack), etc.
I hate programming in a language that doesn't let me feel the metal. Hell, I'd tale old fashioned 1980 BASIC over the newer languages; it doesn't take long to learn not to write spagetti.
Free Martian Whores!
Agile has had the misfortune of being a buzzword that anybody can write about and sell books for. Lots of places then use it as the buzzword process that they are following when in reality the only thing that has changed is what they are calling it.
Other places genuinely try to implement it and find that by getting some things slightly wrong they cause themselves more problems than by sticking with what is familiar to them. This naturally sours everybody involved to agile.
TDD and XP are hard to get right.
However, TDD - Test Driven Development - is something that if your not doing then you probably should looking at implementing it. It raises the very valid question that if you don't know how your going to test something then how are you going to know when you've got it working. It encourages modular code, well factored code because otherwise writing the tests is going to be a pain the ass. Hint - if your finding writing your tests difficult then it probably has something to do with the design of your code, and that is why writing the test first works to improve design.
XP is even harder because it's a superset of TDD. Not only do you need to be getting TDD right but now the process also covers project management and client interaction.
In my mind, the most important part of agile, the part that makes it agile is not any of the above. XP and TDD may be good things but the essential part of Agile is the weekly retrospective where the team sits down and spends an hour on discussing what's going well, going badly or is just worrying and then comes up with ideas for how to improve what they are doing at that point in time.
The idea that the process that your team is working by is not fixed but is evolving is the most important idea of agile.
"Question: When have you EVER switched database on a web application"
Earlier this year, because expenditure needed to be kept to a minimum during the recession starting in 2008 so the initial build used MySQL with the goal of moving to MS SQL Server when profit forecasts were a lot safer and more stable, which they were (and still are!) earlier this year.
"HOW easy was it?"
Effortless, precisely because I'd used database abstraction. It was done and tested in around 20 minutes thanks to the well written unit tests accompanying our abstraction layer demonstrating that the switch worked as required.
"Is there ANYONE out there who only use pure SQL that is 100% understood by all databases the same?"
Yes, I did, for this particular project, for precisely this reason.
"Then go stand in the corner, because your code lacks any optimization."
That's a rather broad statement, there's plenty of optimisation you can do even with just standard SQL, whilst you may lose some additional DBMS specific optimisation features, you may still be able to reach suitable levels of optimisation with ease-
"Real developers optimize their code for the specific environment they are using."
What was that about magic solutions? Optimisation is something you prioritise like everything else. If your application runs at no more than 10% CPU usage and the load isn't going to increase because the userbase is fairly static and this provides plenty of room for increases your application would be expected to see then it's far better to ensure your code is maintainble, than it is to sacrifice maintainability for unnecessary and time consuming optimisation and save the company money by focussing on the priority that best suits the task at hand. "Real developers" should recognise that they simply don't need to optimise at all if in the specific case they are considering it is an unnecesary task.
To use a typical Slashdot car analogy, even the car industry gets this, this is why not every car is in a fight to be the fastest in the world, car manufacturers understand that when a lot of people are limited to a set speed limit anyway, there's no point optimising the car beyond that point and ensuring other things, like having enough room for children to sit in the back, are a priority. The speed of the car just has to be good enough to fulfil the end user's needs not be able to reach speeds which the vehicle will never ever be pushed to in practice at an unnecessary and possibly unaffordable level of cost to the end user.
I actually agree with pretty much everything else you said, but your viewpoint seems a bit contradictory- on one hand you seem to be arguing the basic principle that it's all about using the right tool for the job, but on the other you then seem to be arguing against ways of doing things that are perfectly valid in some scenarios. If you hadn't taken a pop at database abstraction and insisted that all "real programmers" optimise their code then I find little fault with everything else you said. As it stands it sounds like you're saying "You should use the best tool for the job, except in a few cases where I don't like that tool". Sometimes database abstraction has value, sometimes optimisation doesn't.