4 ms·
As a young software developper, what really bores me with Agile, is the name, the shiny box you put things into, where it should just be named "Good practices f
by Raphael_Amiard 16y ago
As a young software developper, what really bores me with Agile, is the name, the shiny box you put things into, where it should just be named "Good practices for software developement". It's the mentality of selling things as products, with some kind of prebuilt ideology and aesthetic built along with the core, that really makes me run far far away.
I don't want to be sold a product. The fact that it led people to try new ways of developping software, be it TDD or pair programming or whatever, is good, but heck, just give me the core idea, remove the gift wrap, and go away. I don't want nor need some kind of new age manager coach.
Anyway, the article seems to be making this very point in some way, but then, why the name agile ? Well for marketing of course. So, while i sort of agree with the article, well i'll just be far away looking, thanks.
- deleted 16y ago[deleted]
- cageface 16y agoExactly. It reeks of buzzwords and consultant speak. Every brush I've had with an agile evangelist felt like a scene from "The Office".
- Retric 16y agoMost of these approaches are far older than 8 years. But, large companies often have an “education budget” and there is an industry that repackages old ideas, gives them a shiny name, and sells them for a respectable profit. EX: Pair programming is very natural in a collage or contest setting. You often see people just default to that mode when under time constraints.
- neiljohnson 16y agoWarren Buffet is an unlikely person to quote in a discussion about agile, but ..... "First come the innovators, who see opportunities that others don’t. Then come the imitators, who copy what the innovators have done. And then come the idiots, whose avarice undoes the very innovations they are trying to use to get rich."
- rue 16y agoThe name probably makes more sense for people who wrote software before it came about. Even "non-agile" development processes have evolved in response in the last 8 or so years.
- joe_the_user 16y agoThe name makes sense but that doesn't mean it's not marketing speak.
- pohl 16y agoThe marketing speak is often useful when one needs to sell ideas to management who might otherwise default to waterfall. I can tell not many here have been in that situation or there would be more appreciation for the utility of branded ideas.
- eru 16y agoHas anyone ever used the waterfall model in any other capacity than to blame it?
- edanm 16y agoOf course. Most software was developed using that model. I think most software is still developed that way, actually, but most people on HN are more likely to be using new techniques. I also think this is the model that is still taught in most Universities.
- deleted 16y ago[deleted]
- run4yourlives 16y agoI don't want to be sold a product. Except that in many, many, cases, you do. :-) Not "you" in particular, but "you" as in enough of a client base that it matters. This is basically the issue with methodologies, regardless of what the contents of a methodology are! Being agile is applying those best practices as you suggest. This comes from years of experience on your team - either learned directly or through mentor-ship/apprenticeship, and will vary depending on the problem constraints and environment. Employing Agile Methodology is applying a pre-defined "solution" to a "problem" that exists, usually because the best practices are not applied at best, but most likely because they are completely foreign to the problem scope. It's the hammer/nail problem. There is a whole market of people looking for solutions to their half finished projects. There are many people selling hammers, screwdrivers, chisels, drills etc. etc. They all run into the same fundamental issue: not working with a complete toolbox. The solution to the problem seekers is to hire competent, experienced and most often expensive programming teams and allow them to properly define the problem scope and solution. This is complicated by the fact that often "you" cannot judge the competency or the experience of the people you need to hire. No amount of ignoring that very hard problem will make it go away. Not whatever process IBM was flaunting 20 years ago, not agile, and not whatever people come up with next. Hackers are painters after all, and you need to have good painters on your team if you are looking for a good painting. It's very similar to hiring a trades-person to renovate your house. In the end, you find one with a good track record and you essentially get what you pay for.
- bitwize 16y agoEric S. Raymond accurately characterized Agile when he described it as repackaging the things hackers do anyway, in a way that can be sold to non-hackers. Maybe you don't want to be sold a product. You're not the target audience for Agile Methodology(tm). The MBA and Tim Robbins crowd are.
- joe_the_user 16y agoThe problem is it is packaging some of the things hackers do anyway. When it's just something you do, it's fairly easy to see when it is or isn't appropriate to do. When it's a package, it's invitation/excuse or requirement to always do it that way. And as the gp says, that's a problem.
- cageface 16y agoIt's funny that you mention Tim Robbins because after listening to somebody talk for 30 minutes about the "values" of the agile process I felt like I'd just sat through a Robbins seminar. The harder somebody tries to convince me that they deeply, truly, personally care about their customer the more convinced I am that they're trying to sell me something.
- jsyedidia 16y agoI think you must mean Tony Robbins.
- kemiller 16y agoSo, this is what appealed to me about the XP/Agile/Whatever movement. It crystallized some of the things I already saw working into a framework that had some chance of making sense to the nontechnical people who would (IME) tend to freak out at some of the ways hackers work. As with most religions, what might start out as a good idea (love one another, take your vitamins) can turn into a dogmatic religion once the zealots take over.
- binspace 16y agoIt's also an arguably necessary way to change processes in (largish) organizations who do not have good practices. Sometimes it's necessary to be a highly paid consultant to be taken seriously.
- mattmcknight 16y agoThe reason for the name Agile is that it was defined in opposition to what came before it- heavyweight, big design up front, fixed requirements, documentation heavy, non-incremental, non-iterative processes. These methods had names- CMM, RUP, V Model, MDA, MIL-STD-498, and we needed a name for the anti-method to go against them and not be labeled a cowboy coder with no process at all, and sidelined from all important decisions. These were attempts to take the risk and uncertainty out of the process. Agile is an attempt to provide practices and approaches for dealing with the uncertainty- "embrace change" is very much the opposite of the "change is too expensive" mindset that it was trying to reset. This adjective "agile" is important, if only to be used as a defense against 300 page requirement documents set in stone by a contract, 500 diagram architectures created before a line of code was written, developers who never got to talk to a user. If we didn't have agile coaches and advocates, people who sat down to come up with a way to run their project might come up with the naive algorithm and head straight over the waterfall. I can see how the name doesn't seem to make much sense now that it is bandied about in very prescriptive step by step methods that probably seem not very agile to a person who had not lived through the horrors that came before. However, that is how it should be understood.
- edanm 16y agoBut you can't call it "Good practices for software developement". Over the years, that term has shifted. 30 years ago it meant the Waterfall method of analysis, 20 years ago it meant OOP, and 10 years ago it started to mean Agile. Hopefully, we actually are getting better at developing software. But don't think for a minute that what you call "Good practices for software developement" is something trivial, that was known all along, and that you'd have to be an idiot not to do anyway.