/tech/ - Technology★

There was a long thread discussing agile development a few months ago, but the board spam killed it.

Nothing wrong with agile if its used the right way, and you have an engaged client. It's an effective way to do iterative development.

>>1059532

Pretty much that, if the requirements are unclear and that the client doesn't even know what it wants, or some other tricky part, it's better to have a tight iterative loop.

Otherwise it can have 1 week-1 month loop.

It might work in cases where you have developers with similar work ethics and level of motivation. Without that, and combined with weak management it can rapidly descend into a parasite/worker drone scenario.

>>1059570

Isn't that the case no matter what formal development method you choose?

>>1059532

>and you have an engaged client.

This right here is the problem: in practice, most clients barely know what they want.

>>1059529 (OP)

When the development team is doing agile but the business team is doing waterfall and there are sixteen "lead" designers that can't fucking finalize a single fucking mockup and over thirty business "owners" who can't fucking reach a consensus on features. Everybody wants agile timeframe with waterfall requirements and all that leads to is the dev team sitting on their asses for months on end until finally getting some god damn fucking requirements two weeks before the deadline.

>>1059584

The point of agile is to break up tasks into small and quick-to-deliver tasks. The point is that when requirements (inevitably) change during the progression of development, the team can quickly change direction as compared to other development models with longer iteration periods.

>>1059586

Good job anon! You parroted the words! That is indeed the point of agile. The other anon was making the point that that rarely happens.

/tech/ posters tend to be on the worker end of software development, which means we would really like to have mostly-stable requirements. You'll find a lot of people with the opinion that if a customer dosn't know what they want, they have no business getting software built.

>>1059603

I see a lot of posts that just parrot the words on /tech/. What the fuck is up with that? Do they think that they'll impress someone with their definition reading?

Anyway, I worked on a project with Agile and I hated it. I had no creative control over it whatsoever and was as boring as can be.

>>1059609

Why is creative control so important in a software development job? Programming a piece of corporate software is inherently boring. I don't know why anybody would find corporate software interesting to do.

>>1059623

You have a very bad attitude towards the vast majority of how business works. Computer software isn't the goal of most businesses when they are not software development shops. Computer software is the support for the business and not the focus of the business. As such, it is the programmer who is supposed to conform to the business environment and not the other way around.

Basically businesses are brain dead 99% of the time, which leads to agile development being shitty because all your requirements change 2 weeks before the deadline, after you've spent 6 months with the only requirement being "make a pretty gui". The blame then gets piled onto agile, because it's yet another buzzword that we have to comply to, and that makes it really easy to hate.

A real complaint is that agile leads to pointlessly complex code, since you typically don't really know what the fuck it's going to be used for and you have to account for edge cases that you'll never actually run into.

>>1059677

Yes, and that is why the software ends up sucking

>>1059676

>Why is creative control so important in a software development job?

Important?

I was making the point that it is frustrating to not have it at all. I don't know if it's "important" that a developer has it. Maybe it is if the client is concerned with quality.

>Programming a piece of corporate software is inherently boring.

You're right but you're falling for a big fat Nirvana Fallacy here. It is already boring, but not having creative control is even more boring. I wasn't even allowed to touch the RegExp they made me work with for emails. Jesus Christ.

Mostly, it's abused to micromanage people and make them feel stress and guilt about not keeping to a certain pace. I've never seen an "agile" company budget time for legacy code maintenance/refactoring, even though those must get done one way or the other, sooner or later (and later = higher cost). It's all about cranking out new features to impress clients or management until the code is such a fucking mess that nobody can reason about it or change anything without breaking something else. But by that point the people that needed to be impressed have been impressed, the checks have been cut, and the devs tasked with ongoing updates and maintenance are left to pick up the pieces and constantly have to defend why every change takes so long.

>>1059709

>I wasn't even allowed to touch the RegExp they made me work with for emails.

If the RegExp had issues, did you create a failing unit test and submit it as a bug ticket?

>>1059954

The regex worked, it was just stricter than it needed to be. It didn't cover some valid email formats.

They didn't care.

>>1060033

Benefit of the doubt, they had some legal or security reason to use exactly that regex. If your requirement was "implement email sanitization using this regex" then that's what you do. You don't bitch because the regex doesn't work with @cock.li emails or something.

Agile gets a really bad rep since it became a buzzword that long-nose salesmen throw around like it's the philosopher's stone, and as other anon have said, it will not work if the company works on a waterfall model all around while only the dev team tries agile.

From my work experience, if the dev team actually manages to take a hold of the production cycle of the company, and the other areas get used to the sprint cycle, you actually can get some work done.

Also, if your sprint doesn't focus on actually finishing a product that can and will be used as soon as possible, even if it means to do shit manually so it works, the client will just keep adding shit to the backlog pile and you'll never finish anything.

Too much management is fucking poison, the best environment in my experience is the end user telling the dev team what his problem is, no architects, no project managers. If you keep adding barriers between the end user and the dev team you'll suffer from "why are we implementing this?" "I don't know, someone said it was important".

At most you need someone whose work is to tell the other areas of the company to fuck off because we have too much work, most of the times this should be the product owner/scrum master or just someone that's more experienced and has a smaller chance of being fired.

Some of the symptoms associated with Scrum that are bad:

>A customer who doesn't know what they want or is too unclear about the direction of the project will always be an issue with a project regardless of development model, and will make an agile team inevitably work more as they try to understand through a bunch of iterations what the customer wanted. Scrum could be said to be enabling such terrible repeated behavior by customers, and its unhealthly for a project regardless of development model. It gives some businesses the wrong idea of what they can get with what they give, its not going to be like a magic wand that works simply because it isn't a traditional development model.

>Its associated with the open office craze. Not exclusive to Scrum, but open offices are distracting when its actually crunch time, might be good for brainstorming and bug hunting but there are things better done alone. Better to have a room or times designated for that specifically.

>Dicking around with Slack/Discord/other crap just because you have those Scrum meetings. You don't need emojis to do this, you just need text, and IRC provides that. Maybe Signal if you really need to use phones/other terrible mobile devices, or pick whichever FOSS multiplat chat program that actually works and is ready for the real world. There is no reason why your chat logs should be held for ransom, this is ridiculous.

>Strawman arguments to justify Agile methods over non-agile methods in general are used. Waterfall is not necessarily the exact development model used by non-agile developers, they ignore stuff like merit based cowboy coding that occurred in open source projects and/or situations where the developer is not beholden to a customer and simply designs the software themselves for example.

>Agile can't always save you from your company's management making poor decisions.

I like the idea of the Scrum master if they can keep the suits/biz folks at bay while managing the project a bit more impartially. Flexibility and less FUD about trying a new piece of technology is also good to an extent. The sprint cycle is really a customer based/assumption of ever changing goal thing, if your project doesn't meet this sort of description it might not really see any benefit from these sprints. Generally, the industry is way too excited about Agile for their own good.