Programming question: are you glad it didn't work on the first try?

[veti]

I love it when the code compiles first time. It's reassuring that I've got a good enough handle on the language that my handwritten syntax and typecasting is, at least, valid.

In testing, however, it's more reassuring to find a few issues. That tells me that my tests are doing something useful.

[Manga Shoggoth]

It's frustrating how much Agile has dominated in technical environments. It is a tool that works well some situations. I know part of the reason people use it everywhere else is because there is someone wanting to sell Agile support products telling everyone that it applies everywhere, all the time. Still, I feel perhaps people use it because they aren't sure what else to use, so why not something they already know.

Back in the day (the mid 90's) when Agile was starting up my company was involved in one of the variations. As a result I spent some time studying it, and the documentation made it very clear that Agile wasn't for everything, even listing 5 broad areas where it should not be used (the three I remember are safety critical, financially sensitive, politically sensitive), and was very clear about its weaknesses. Almost none of the modern training I have dealt with does that.

I also see the standard "**** on waterfall slide" in modern training that was completely absent in the original stuff (at least, the stuff I saw). You'd think that no waterfall project ever succeeded and no agile project ever failed.

Agile is a really good framework, but people forget it's a framework. You use the bits that are appropriate and you adapt it to what you are doing, and if it doesn't fit you use something else.

[IthilanorStPete]

Back in the day (the mid 90's) when Agile was starting up my company was involved in one of the variations. As a result I spent some time studying it, and the documentation made it very clear that Agile wasn't for everything, even listing 5 broad areas where it should not be used (the three I remember are safety critical, financially sensitive, politically sensitive), and was very clear about its weaknesses. Almost none of the modern training I have dealt with does that.

I also see the standard "**** on waterfall slide" in modern training that was completely absent in the original stuff (at least, the stuff I saw). You'd think that no waterfall project ever succeeded and no agile project ever failed.

Agile is a really good framework, but people forget it's a framework. You use the bits that are appropriate and you adapt it to what you are doing, and if it doesn't fit you use something else.

Seconding all of these conclusions. The original Agile Manifesto talks about "people over process"; modern Agile training presents stuff like this unironically:

Spoiler: Big image

Show

[factotum]

The absolute f... is that? Looks more like a buzzword generator than a programming guide.

[IthilanorStPete]

The absolute f... is that? Looks more like a buzzword generator than a programming guide.

It's SAFe, the Scaled Agile Framework. Isn't it glorious?

[Manga Shoggoth]

It's SAFe, the Scaled Agile Framework. Isn't it glorious?

Yes. I got a certification in it a couple or years back... It is what happens when managers are given a simple thing to work with.

...Although in fairness, that was one of the few courses that didn't follow the "*** on the other methods" mantra - as the trainer put it, they dealt with too many senior people who had (successfully) used them.

[Jasdoif]

The absolute f... is that? Looks more like a buzzword generator than a programming guide.

It's not a programming guide. It's a structure for getting executives to decide and prioritize business strategies, other top-level management to decide and prioritize solutions to further those strategies, mid-level management to decide and prioritize projects to implement those solutions, and low-level management to decide and prioritize programming tasks to reify those projects.

Ideally this ensures every development effort provides the optimal amount of value to the business, isolates technical endeavors from out-of-band influence (e.g. office politics have already played out), means there's always an authoritative chain to answer "why are we spending time/money doing this?", and allows the people directly responsible for the work to decide how to accomplish the work. Of course anything with so many different people involved is bound to drift from the ideal, sometimes quite a bit....

[Sigako]

That entirely depends on length of what I do.
I'm not a dev or even a programmist proper, but I do use Matlab heavily in my work.

When it's a large script with lots of things to track and do, I'm usually anxious, if only because it usually takes too long to finish before I can catch any mistakes (not an algorithmic issue, just really big datasets to process in hundreds). When it's a quick hack under a dozen lines for an urgent problem, I'm annoyed by every single hiccup and delay.

Although I usually cheat, copying parts of scripts into console and executing them on a single dataset to see how it works, which technically doesn't count as a first try.
And once I managed to catch all bugs before execution by thinking very hard and careful, but it took about the same time as if I'd did it the usual way.

[kyoryu]

Seconding all of these conclusions. The original Agile Manifesto talks about "people over process"; modern Agile training presents stuff like this unironically:

Spoiler: Big image

Show

HAHAHAH!

The original idea behind Scrum was basically "hey, you know how we work in like hte last few weeks of a project? What if we did that all the time?"

What it has turned into is..... something else. Most implementations of Scrum are closer to what I call "Scrum-but" or "Scrum-butt". Take your pick.

[veti]

The original idea behind Scrum was basically "hey, you know how we work in like hte last few weeks of a project? What if we did that all the time?"

Is it me, or has "agile" become more or less synonymous with "scrum" now?

Time was, "agile" was based on the manifesto, and we assumed there were many ways to implement it. Now, it seems to me that when people say "agile", they're thinking scrum, and the alternatives have been forgotten. (For instance, test-driven development can be used as the basis for an agile program, but I think people dislike it because it means too much thinking up front, and the whole point of agile is to avoid that.)

What I remember about scrum is that it was originally touted as a way to retrieve waterfall projects that had gone off the rails (and I apologise for the mixed metaphor, but it really does reflect how people around me talked back when I was looking at this nonsense). Which meant there existed, before you started, a detailed spec, a plan, and a large base of code already written - wrong, of course, but still large and detailed, which is important. Trying to implement scrum without those prerequisites in place seems to me a bit like trying to drive a sports car across a ploughed field.

[kyoryu]

Is it me, or has "agile" become more or less synonymous with "scrum" now?

Sadly, yes.

Time was, "agile" was based on the manifesto, and we assumed there were many ways to implement it. Now, it seems to me that when people say "agile", they're thinking scrum, and the alternatives have been forgotten.

Yes, following the principles rather than the values is the source of much Scrum-butt.

(For instance, test-driven development can be used as the basis for an agile program, but I think people dislike it because it means too much thinking up front, and the whole point of agile is to avoid that.)

But it really shouldn't mean that much thinking up front. It's really more like detailed, just-in-time code specs.

What I remember about scrum is that it was originally touted as a way to retrieve waterfall projects that had gone off the rails (and I apologise for the mixed metaphor, but it really does reflect how people around me talked back when I was looking at this nonsense). Which meant there existed, before you started, a detailed spec, a plan, and a large base of code already written - wrong, of course, but still large and detailed, which is important. Trying to implement scrum without those prerequisites in place seems to me a bit like trying to drive a sports car across a ploughed field.

Ehhhh, maybe. I think it's mostly intended as a way to incrementally deliver a product to a customer, staying in touch with them, while maintaining flexibility to incorporate new information.

I also tend to think it works often best in scenarios where you're mostly dealing with known tech stacks and little "research" code. If you've got experienced web devs that basically know How To Do Web Stuff, and are working on a web site, I think it's great.

[Storm_Of_Snow]

I'd say that if you get support from those above, and a motivated team implementing it, then it doesn't really matter what processes you have in place, you'll be productive.

A disfunctional company with people keeping their CVs updated so they can get out the door asap, and again, it won't matter what you have in place - what gets released will be poor quality.

The problems come when it's "company x does this so we should" without any thought about whether that'll work for you, or someone new in a managerial position tries to bring in exactly what they did at their previous company because it worked there (usually only because of one or two people) and that's the only thing they really know how to do.