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.
Quoth TFA: "Despite potential pitfalls, experts in the agile space agree that implementation of agile practices has benefited software development overall."
And in other news, despite potential pitfalls, the pope agrees that Catholicism has benefited religion overall.
The original manifesto's key message was "people over processes" which I still agree with. On the other hand the word "Agile" now means just as many processes as waterfall or RUP meant in the past. Shame.
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:
if waterfall has delivered?!
It seems most projects work in spite of waterfall, not because of it.
I'm not saying it doesn't work. That is for small/medium projects with a very tight scope it does.
What's the name of that FBI project again?! Virtual case file?! Oh well...
how long until
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.
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!
"People over process" is an important tenet in more ways than one, and not only in IT. Often, this message is taken to mean that teams and individuals are given more freedom to organise their own work, and are managed on outcome rather than activities. This is true in some ways, but it's more than that.
"People over process" to me also means acknowledging the value of each individual's skills and abilities. That starts with resourcing: instead of posting jobs for "2 junior programmers, 1 senior programmer, 1 encryption specialist (part time) and 1 PM", one would think "Together, Alice and Bob are up to the task of writing this module, Alice knows enough about encryption to cover that part of the job, and Bob is a good team lead". No two people are alike, and if you value people, that means that you account for their differences as well. Yes, it also means that if Alice calls in sick, you have a problem on your hand, but it's by no means an insurmountable problem.
And it goes beyond that. "People over process" to me also means that you let people do what they are good at beyond the call of their assignment. (as long as it benefits the company). As an individual, it means that you sometimes take responsibility for stuff that is not strictly your job. If someone contacts me with a problem I can solve, I do not answer with "Contact the helpdesk"... if it's likely the problem will get kicked down 3 layers, taking 2 weeks to come up with a non-answer. Instead I will take an hour off my regular work to provide a helpful answer (of course with the suggestion that they contact the helpdesk, and copying in support as well). This helps everyone, including the company.
Yes, accounting for individual differences makes budgeting, resourcing, managing continuity, and people management a lot harder. That's why managers hate "people over process" and why Agile IT gets loaded down with more process: resources are so much easier to manage than people.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
IT, or at least some people in IT suffer from what I call the "Oprah" syndrome. No, not the weight issue. The idea that a problem is just one problem and that it can be solved with a single solution. Or the silver bullet that will solve all your problems at once.
Software development is bloody hard, partly because it doesn't deal with a real product and testing a software product is extremely abstract.
If I design a better brake pad, I can test this fairly simply AND thorougly. We know exactly what it is supposed to do, how it does it and how we can compare performance. There is no magic, if the brakepad reaches 198 degrees on a sunday, the trunk will pop open. Also nobody will ask a brake pad engineer to add a christmas special to it, on the 25th of december, at 8 in the evening.
Web development especially suffers from the idea that if only we implement magic method number #45324521, all the hassle of web development will go away. Writing specs is long boring and not very sexy. So lets do agile and not write them anymore. Problem solved... eh no because spec writing is long boring and not very sexy because getting the requirements out of a user is like sucking cock. The user might enjoy it but you are just left with a bad taste in your mouth and a desire to throw up over the user. Or maybe that is just my dates.
"But if you do agile right", but if you do documentation driven development right! Any method, done right will most likely work. That is the definition of doing it right. Why is it so hard to do agile right? Why are there so many variants already?
I see a lot of "magic" solutions in web development.
Database abstraction, so we can magically switch database!!!
Question: When have you EVER switched database on a web application and HOW easy was it? Is there ANYONE out there who only use pure SQL that is 100% understood by all databases the same? Then go stand in the corner, because your code lacks any optimization. Real developers optimize their code for the specific environment they are using. This includes making use of database specific features. Don't use Mysql auto-increment and PDO and think you are database independent.
Frameworks take all the hardship out of writing code!!!
Question: How smart do you think it is to hire a coder who hates to code? It is like hating a singer who hates to sing, a spokeperson who doesn't like talking.
This is where a lot of the silver bullets come from, from people that don't actually want to be a developer but just cash the paycheck. You don't hire a cook who only knows how to nuke frozen meals do you? If you go to the supermarket and buy a microwave meal thinking wow, this makes cooking easy, then here is a hint: IT AIN'T COOKING. It is heating up food.
I see time after time some framework or tool promosing a complete working website without writing a line of code... EEK! That is my JOB! Luckily they are all wrong because what at most they do is create a straight CMS for your database, which is rarely what the customer wants. After all, there are already plenty of tools to graphically maintain your database content.
No, Agile hasn't delivered... for those looking for a silver bullet to the problems of development. For others, it is a valid method with its own problems that puts it along side more traditional models, not ahead of them.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Absolutely not. Never before have I experienced a method of programming that can be more aggressively mismanaged than agile. Many developers think agile is a means to produce better code, faster, and with better specs. Most management sees it as an excuse to provide no specs, to change their minds on what they want every 5 minutes, and call all of that "agile" development. These things ruin the name of agile development and provide such a bad experience for anyone stuck working with it, that it simply can't have managed to do anything but fail utterly to deliver. People have been fired over misinterpretations of what agile is. Others have left because of a misinterpretation that was shoved down their throats by management. And that's just all where I work... Perhaps it's better in other places, but I've never heard a story of it going well.
While you have a valid example of why database abstraction CAN be useful, you have not actually proven that it must be done every time just in case you might switch sometime in the future.
Seen to many developments throw speed out of the door for a migration that will never happen.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Old School here too. I do what I have to, to make a living. For fun, I program in FORTH and store my source code in 1K Screens represented as 16 lines of 64 characters each.
Simplicity and elegance is what I am looking for. A new Forth definition should be about 7 to 9 words long (not including noise like + - / ). If I somehow end up in a situation where I run out of room, It means I have used 15 lines for creating my definition. Which is another way of saying "Hey! your doing it wrong".
I think programming should be taught on an emulator of a Commodore64. Once you learn the computer from one end to the other and how to take advantage of all of it and understand all of its concepts, then you can move onto programming in a more abstract environment.
vi +