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

[Telok]

When programming anything non-trivial I get this weird feeling of relief when, after banging out a bunch of code involving batch xml parsing or a convoluted series of IFFs for example, it throws an error or fails a test. When something like that seems to work on the first try I become deeply suspicious and go back looking & testing for the error I just know has to be lurking in there somewhere.

Anyone else get that sort of thing?

[Captain Cap]

When programming anything non-trivial I get this weird feeling of relief when, after banging out a bunch of code involving batch xml parsing or a convoluted series of IFFs for example, it throws an error or fails a test. When something like that seems to work on the first try I become deeply suspicious and go back looking & testing for the error I just know has to be lurking in there somewhere.

Anyone else get that sort of thing?
Of course, I'd say it's perfectly normal to meet the impossible with suspicion.

[Batcathat]

While I don't program a ton (I do some occasional html for work, but that's mostly copy, paste and slightly modify) I think I have that attitude towards things in general. Too good to be true usually isn't true.

[Ibrinar]

I think that is normal psychology, a few fixes raise the confidence that the bugs are caught and it is good now while if it just works the bugs might be pesky non obvious ones you only find with thorough testing. Though of course there is no reason to believe the second kind of bug isn't there because you had a few of the first kind to fix.

But yeah if it isn't super small I kinda expect to have some minor errors and it can feel weird when it just works.^^

[Chronos]

I'm not really sure how I feel when it works right the first time. If it ever happens, I'll let you know.

[JeenLeen]

I'm with you on this. Professional programmer here.
When I write fresh code, definitely expect some errors and debugging.
When I update old code, I'll often have code run successfully (e.g., without errors) the first time. But I make sure to delve into test cases and look over data transformations ot make sure it did it correctly. E.g., just last night I updated a program for 2018-19 to run on 2020-21 data. Technically ran in that it generated output, but a load of error messages because the input changed and I wasn't aware.

What bugs me is that some of my co-workers aren't. I know one guy who assumes his code works as long as nothing crashes the entire process. Well, that might be some hyperbole (as he is a competent guy who makes good results), but he at least talks like that. No test cases, no checking the results to make sure they make sense, etc.

But that's better than the guy who got fired, who I think didn't even check if his program actually run. :smalltongue:

[Tyndmyr]

Depends on the code, and how complicated it is.

Sometimes I'm in a groove, and it's something I know well, and it all just works. That doesn't bother me, though neither does it surprise me when I find I missed something.

But if I'm doing something genuinely weird and have significant uncertainty over if I've done it right, well...then you do feel a certain bit of suspense when it doesn't crash, because you're looking for the flaw and not finding it.

Generally it'll turn up, though, so no great worry.

[Mastikator]

Anything non-trivial gets tried continuously while I make it, by the time it's "done" I've probably tried it a hundred times. And if I'm comfortable with the domain and requirements I'll have tests done before that. To be honest I never feel like code is truly done, there's always refactoring to be done, better structure and naming. What forces me to move on to the next task is that the next feature isn't going to write itself.

[halfeye]

There's also the problem that debugging is fun, so there is some motivation to allow bugs to have fun finding them. That is a temptation that must be very rigorously resisted, and it's not easy.

[Captain Cap]

There's also the problem that debugging is fun
:confused:

[Manga Shoggoth]

There's also the problem that debugging is fun, so there is some motivation to allow bugs to have fun finding them. That is a temptation that must be very rigorously resisted, and it's not easy.


:confused:

How fun it is depends on the nature of the code and the nature of the bug, but I wouldn't want to allow bugs into my code.

In fact I'm usually quite pleased when something works first time.

[Storm_Of_Snow]

I'm a QA - if it all worked first time, I wouldn't have much of a job :smallamused:

More seriously, I have done some coding (automated tests, some small applications for internal company use only) and in some ways, you learn more when it doesn't work initially.

It starts getting annoying when you've been saying it'll be working in five minutes for three hours though.

[JeenLeen]

There's also the problem that debugging is fun, so there is some motivation to allow bugs to have fun finding them. That is a temptation that must be very rigorously resisted, and it's not easy.

I do enjoy some debugging. Learn neat ways to do stuff.
But when it's like 30 minutes or more to figure out there's a missing parenthesis, semi-colon, or I put a END instead of a RUN statement... that's frustrating.


It starts getting annoying when you've been saying it'll be working in five minutes for three hours though.

Ha, ha, yeah. That can frustrate co-workers, too.

[sihnfahl]

E.g., just last night I updated a program for 2018-19 to run on 2020-21 data. Technically ran in that it generated output, but a load of error messages because the input changed and I wasn't aware.
Ah, now, there's the fun part. You got error messages cause the way the data's presented changed, so any modifications to the presentation caused a fault.

I had to go over someone elses' code ... and the fun part is that it WAS working, just ... not all the time. No error messages. Turns out the SQL backend was filtering out the stuff that wouldn't parse under the old rules... so the new data was never presented.

[factotum]

It's always fun when your program doesn't work as expected because of bugs in the compiler, I find. Years ago I was writing an application and one particular part of it ran horrendously slow and I couldn't work out why. Eventually, I used the option to compile into assembly code instead of object code in desperation, and I found that one particular line of C code was being expanded into something like 3K of assembler for no readily apparent reason! I can't even remember what I did now--I think I added whitespace somewhere, something that shouldn't have made any difference whatsoever--and that 3K of assembly was suddenly a few bytes and the whole thing ran smoothly.

[IthilanorStPete]

It depends, but usually yes, especially if we're counting a failing automated test as "not working". Especially if it's something I can easily write a test for, I'm only confident in that test if I've seen it fail; otherwise, I worry that the test won't indicate failure if the code being tested breaks in the future. This is also useful for refactoring test code (see this post (https://sirenian.livejournal.com/21808.html) about "refactoring [test code] against the red bar"), as well as the general idea of mutation testing. (Example mutation testing library (https://pitest.org/)) Unless the code is really trivial; the only cases where I'm content with the first run being successful is when I'm confident in relying on the typechecker to check my log; in the latter case, the "run and fail" cycle is replaced with more of a "see if it typechecks and respond to type errors" issue. That also requires a language with a type system I trust well; that's pretty much limited to TypeScript (in a project that's disciplined about not using "any" and using the most specific types possible) and Haskell. Rust would probably also qualify if I used it more.


It's always fun when your program doesn't work as expected because of bugs in the compiler, I find. Years ago I was writing an application and one particular part of it ran horrendously slow and I couldn't work out why. Eventually, I used the option to compile into assembly code instead of object code in desperation, and I found that one particular line of C code was being expanded into something like 3K of assembler for no readily apparent reason! I can't even remember what I did now--I think I added whitespace somewhere, something that shouldn't have made any difference whatsoever--and that 3K of assembly was suddenly a few bytes and the whole thing ran smoothly.

Oof, codegen bugs are rough to debug from everything I've heard. The one compiler bug I've run across in my own code was a typechecker bug in TypeScript.

[Storm_Of_Snow]

It depends, but usually yes, especially if we're counting a failing automated test as "not working". Especially if it's something I can easily write a test for, I'm only confident in that test if I've seen it fail; otherwise, I worry that the test won't indicate failure if the code being tested breaks in the future.
Yeah, that.

Backfilling tests against fixes that shipped a while ago because someone decided it had to be shipped right now, and the devs underestimated how long it would take them to fix it so they ate into testing time as well (and more likely all the way through it, through any contingency and beyond), and for whatever reason you can't put the old code anywhere to confirm what you're working on...

Always fun, honest :smallfrown:



Oof, codegen bugs are rough to debug from everything I've heard. The one compiler bug I've run across in my own code was a typechecker bug in TypeScript

Cascade failures are the worst as far as I'm concerned - where something earlier on in a sequence causes a failure further down, but when you run the failing functionality/test on its' own, it works perfectly happily.

[snowblizz]

I'm with you on this. Professional programmer here.
When I write fresh code, definitely expect some errors and debugging.
When I update old code, I'll often have code run successfully (e.g., without errors) the first time. But I make sure to delve into test cases and look over data transformations ot make sure it did it correctly. E.g., just last night I updated a program for 2018-19 to run on 2020-21 data. Technically ran in that it generated output, but a load of error messages because the input changed and I wasn't aware.

What bugs me is that some of my co-workers aren't. I know one guy who assumes his code works as long as nothing crashes the entire process. Well, that might be some hyperbole (as he is a competent guy who makes good results), but he at least talks like that. No test cases, no checking the results to make sure they make sense, etc.

But that's better than the guy who got fired, who I think didn't even check if his program actually run. :smalltongue:
I would wager as part of becoming a professional programmer you had to learn about testing and QA and how easy it's to make errors.

I wrote my master's thesis about end-user development and one of the issues is the propensity for non-professionals to not check for errors. The research at the time suggested about 4% of human cognitive activities (literally 4% of your keystrokes) resulted in errors, and that was the corrected rate. I.e. the person did kinda try check to see what they just entered just without a dedicated testing and error finding process. And it has nothing to to do with competence, intelligence, ability or anything like that really, our brains are just hardwired for "good enough decision, ASAP". Trying to sell in this need for testing and error finding was one of the major challenges they struggled with. Particularly for non-professional programmers.

So if you all are suspicious about your newly written programs the efforts of the people whose papers I read back then wasn't written in vain!:smallbiggrin:

[factotum]

I would wager as part of becoming a professional programmer you had to learn about testing and QA and how easy it's to make errors.


You'd lose that wager in my case--I was a professional programmer (e.g. my main source of income came from it) for seven years without ever having had any formal programming training. Heck, in my first job they basically sat me down in front of a video recorder and told me to watch this video series on how to program in C, and I was producing actual code within 2 days.

[Tyndmyr]

You'd lose that wager in my case--I was a professional programmer (e.g. my main source of income came from it) for seven years without ever having had any formal programming training. Heck, in my first job they basically sat me down in front of a video recorder and told me to watch this video series on how to program in C, and I was producing actual code within 2 days.

The US military is similar. It's a ten week course, and prior computer use of any type is not required or tested for in order to sign up for it. Or at least was when I went through it.

It's pretty accelerated, but they most certainly don't focus on QA or test driven development. I had previously gone to college for CS, so I did happen across some of that, but plenty of people did not. For what it's worth, I believe test driven development to be overrated in most cases and avoid it whenever possible.

It's one of the few career fields where degrees are still considered fairly optional, no professional certification is required for many jobs, and thus, if you can do it, you can just start doing it, and getting paid relatively well for it.

[Storm_Of_Snow]

You'd lose that wager in my case--I was a professional programmer (e.g. my main source of income came from it) for seven years without ever having had any formal programming training. Heck, in my first job they basically sat me down in front of a video recorder and told me to watch this video series on how to program in C, and I was producing actual code within 2 days.

I did computer science/studies at school, but wound up doing an engineering degree, and then became a tester because I kind of misread the job advert, and luckily my first boss wanted someone with a science background, not a computing one.

Twenty-something years later... :smallamused:

In my experience, most developers (programmers, coders, whatever you want to call them) just focus on that - hack the code together and get it out the door because they don't feel they have the time to make a good job of it.

QA, UX, all those sorts of things - if they're not in the feature spec or user story, it's probably not going to get done. Especially if you're in an agile development environment, with managers who don't really understand it, but think it means they get everything yesterday. :smallfrown: And, to be brutally honest, there's a number of developers out there who think doing QA-type work is somewhat beneath them.

That said, I've worked with a few developers who'd quite happily come and ask my opinion on things, walk me through their unit tests and so on, and funnily enough I very rarely had any major issues coming from them.


For what it's worth, I believe test driven development to be overrated in most cases and avoid it whenever possible.

Me too - some managers love the sound of it, but they try and shoehorn it into an agile development environment and it either never starts or gets halfway and then all falls apart.

IMO, TDD for anything but trival functionality works when you can basically get all the spec written up front (so full on waterfall), otherwise the developers are really only guessing what the inputs and expected results should be and even experts in the field they're developing for will get it wrong.

[Telok]

QA, UX, all those sorts of things - if they're not in the feature spec or user story, it's probably not going to get done. Especially if you're in an agile development environment, with managers who don't really understand it, but think it means they get everything yesterday.

Ye gads, don't remind me. Please.

Although with that particular fake-chocolate covered cluster of nuts our direct manager was fine. The client... I had to get hired on by the client in order to get the data dictionary and file paths the project was supposed to be using for thd db migration and document management...

Happily everyone directly in involved retired, moved thousands of miles away, or changed jobs & dropped off the face of the planet within 6 months of going live. Aside from the occasional urge to find & strangle a few of those missing people, everything has been pretty smooth sailing ever since.

[Willie the Duck]

It's one of the few career fields where degrees are still considered fairly optional, no professional certification is required for many jobs, and thus, if you can do it, you can just start doing it, and getting paid relatively well for it.

Manager for programmers/data scientists here. We consider both degrees and certifications in the hiring process. However, what you have done, or what you can adequately show you can do, take massive precedence. I always include people who are actively doing a task in the second interviews, so they can ask questions and see if the responses indicate someone who would (perhaps with some nudges based on the peculiarities of our systems) be able to accomplish the work objectives.



In my experience, most developers (programmers, coders, whatever you want to call them) just focus on that - hack the code together and get it out the door because they don't feel they have the time to make a good job of it.

QA, UX, all those sorts of things - if they're not in the feature spec or user story, it's probably not going to get done.
A huge amount of my job is making sure that (often much smarter than I) people's brilliant solutions solve the problem that the requestor actually wanted solved.


Especially if you're in an agile development environment, with managers who don't really understand it, but think it means they get everything yesterday. :smallfrown: And, to be brutally honest, there's a number of developers out there who think doing QA-type work is somewhat beneath them.

Me too - some managers love the sound of it, but they try and shoehorn it into an agile development environment and it either never starts or gets halfway and then all falls apart.
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.

[Tyndmyr]

Me too - some managers love the sound of it, but they try and shoehorn it into an agile development environment and it either never starts or gets halfway and then all falls apart.

IMO, TDD for anything but trival functionality works when you can basically get all the spec written up front (so full on waterfall), otherwise the developers are really only guessing what the inputs and expected results should be and even experts in the field they're developing for will get it wrong.

That's largely been my experience with it.

It's also been exceptionally rare that the spec has been fully written up front. At a bare minimum, there are always some changes along the way, and often so many changes that it becomes a completely different project. Setting requirements and schedules seem to be incredibly challenging to nail down in advance.

So, in practice, you often end up with some flavor of agile...though perhaps not a terribly functional one. The conceit that a stand up means that everyone will be brief in meetings is perhaps my largest quibble with it. Perhaps most of us greatly wish that, but there always seems to be that one guy who is quite happy to talk at length.


Manager for programmers/data scientists here. We consider both degrees and certifications in the hiring process. However, what you have done, or what you can adequately show you can do, take massive precedence. I always include people who are actively doing a task in the second interviews, so they can ask questions and see if the responses indicate someone who would (perhaps with some nudges based on the peculiarities of our systems) be able to accomplish the work objectives.

How's hiring at present? Finding qualified folks here who want to move is like pulling teeth. And qualified mostly means just skills and/or willingness to embrace learning the bits they don't. Every project has a few unique oddities, so that latter part is largely unavoidable, but so far as I can see, it remains a pretty great career in terms of pay and job availability. That's likely the biggest reason why degrees are nice but not necessary, there's just a really strong need for candidates.

[Willie the Duck]

How's hiring at present? Finding qualified folks here who want to move is like pulling teeth. And qualified mostly means just skills and/or willingness to embrace learning the bits they don't. Every project has a few unique oddities, so that latter part is largely unavoidable, but so far as I can see, it remains a pretty great career in terms of pay and job availability. That's likely the biggest reason why degrees are nice but not necessary, there's just a really strong need for candidates.

Challenging, to say the least. I should mention that I work in U.S. Healthcare Informatics, which, given the pandemic, you can only imagine how much the internal need for our products have increased in the past couple years. Everyone who used to be in the field still is (and asking 4-5 figure increases to change jobs, often justifiably so), and we want to grab as many people coming into the market as possible. We've had departments increase from 2-3 people to a couple dozen. With that kind of situation, everyone who might be able to train a learning-embracing fresh face is already burning the candle at both ends. Thus, even when we do get people onboarded, getting them to the point of net positive output is a huge commitment, and the stress levels are high. I have talked a couple new young employees out of quitting during the first six months (they ended up thriving once they got past the initial hurdles), and gave another emotional permission to do so (they would not have). I've been team dad more often than I ever felt possible, which is both humbling and awesome (and frightening and frustrating and challenging and rewarding and...etc.). I still love what I do, but man do I wish we had a little more breathing room at the moment.

Yes. Programming (of all stripes) is incredibly employable. To all you youngin's, even if you don't want to spend your days with C or Python or the like, pick up an SQL or R or SAS class along with your main degree (if you find out you don't like the main career of your degree, programming pays the bills very well while you form a new strategy). If you don't want a 4-year degree, consider technical school. Or all sorts of online resources (many of which are free). The degree is, more than anything, evidence that you can sit down, pay attention, stick with a thing, and all the other basic adulthood things we otherwise aren't sure you know how to do. Alternate evidence to that effect works.

[Mastikator]

How's hiring at present? Finding qualified folks here who want to move is like pulling teeth. And qualified mostly means just skills and/or willingness to embrace learning the bits they don't. Every project has a few unique oddities, so that latter part is largely unavoidable, but so far as I can see, it remains a pretty great career in terms of pay and job availability. That's likely the biggest reason why degrees are nice but not necessary, there's just a really strong need for candidates.

I'm a software developer, I get a job interview offer about every other or third day. Been a software developer for 10 years, no noteworthy diplomas or certificates, if I had that I expect it would mean my salary would be higher (and I'd likely have to start my own company to really take advantage of that).

I imagine the people on the other side of the table are desperate for someone like me to be honest.

[Storm_Of_Snow]

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.
Oh yes - basically, it's always promoted as because Amazon or Google or whoever use it and they do whatever. That's their environment, that's how they work and it doesn't transfer across with success guaranteed - usually because of one or two people on the team who do what they dodespite management's actions completely unnoticed by anyone .


That's largely been my experience with it.

It's also been exceptionally rare that the spec has been fully written up front. At a bare minimum, there are always some changes along the way, and often so many changes that it becomes a completely different project. Setting requirements and schedules seem to be incredibly challenging to nail down in advance.

So, in practice, you often end up with some flavor of agile...though perhaps not a terribly functional one. The conceit that a stand up means that everyone will be brief in meetings is perhaps my largest quibble with it. Perhaps most of us greatly wish that, but there always seems to be that one guy who is quite happy to talk at length.

Agreed, and even if the spec is fully written and agreed, the timeline properly organised and contingencies built in and so on, there's always bugs, support issues, unforseen co-worker absences, departures and new hires to bring up to speed, days where, say, the office network breaks and doesn't come up again, some new environment that you now have to support, a new version of a dependancy that breaks half your code...

For standups, I've seen egg timers used fairly well - you need everyone to buy in and adhere to it though, and if there is anything major that has to be addressed by the whole team rather than getting two or three people together to hammer it out, they need to put their hand up at the start and if necessary, derail the whole thing, not sit quietly and wait their turn.

[Tyndmyr]

Challenging, to say the least. I should mention that I work in U.S. Healthcare Informatics, which, given the pandemic, you can only imagine how much the internal need for our products have increased in the past couple years. Everyone who used to be in the field still is (and asking 4-5 figure increases to change jobs, often justifiably so), and we want to grab as many people coming into the market as possible. We've had departments increase from 2-3 people to a couple dozen. With that kind of situation, everyone who might be able to train a learning-embracing fresh face is already burning the candle at both ends. Thus, even when we do get people onboarded, getting them to the point of net positive output is a huge commitment, and the stress levels are high.

Yeah, that's a rough scenario. High stress murders your retention rate, especially when folks can just go get a different job. Early on, I took such a position before I learned the various warning signs of such a role, and after a week, realized I could, just...not. To date, that's the only time I bailed on a job super early.

These days, I'm mostly doing big data stuff. Splunk's the hot tool of the moment, and it's pretty solid, but invariably any sufficiently complex system will need someone to handle data normalization and management upstream of Splunk itself. This is honestly not all that bad or hard to pull off, but finding people who want to do it....even for quite good money, is still challenging if not offering a work from home position. Lots of desire for that these days, and it's great for the jobs that are well suited for it, but not every business is on board with it 100% yet, and sometimes a specific job genuinely needs on-site people.


Yes. Programming (of all stripes) is incredibly employable. To all you youngin's, even if you don't want to spend your days with C or Python or the like, pick up an SQL or R or SAS class along with your main degree (if you find out you don't like the main career of your degree, programming pays the bills very well while you form a new strategy). If you don't want a 4-year degree, consider technical school. Or all sorts of online resources (many of which are free). The degree is, more than anything, evidence that you can sit down, pay attention, stick with a thing, and all the other basic adulthood things we otherwise aren't sure you know how to do. Alternate evidence to that effect works.

Oh, definitely. Having a range of skillsets is handy. I've done a wild list of things, and while realistically coding remains the easy moneymaker, if that ever changes, I'll get by. Having some technical skills blends very well with many other careers, and provides a very solid fallback for rough patches.

A couple of certs also provides a bit of that reassurance if you haven't gotten a degree. These are, if you know the stuff, quite easy, and a great deal cheaper and less time intensive than college.



For standups, I've seen egg timers used fairly well - you need everyone to buy in and adhere to it though, and if there is anything major that has to be addressed by the whole team rather than getting two or three people together to hammer it out, they need to put their hand up at the start and if necessary, derail the whole thing, not sit quietly and wait their turn.

The problem usually tends to focus on someone that's either management, or senior enough that management doesn't want to step on their toes. Which, hey, that's life, but it does drag on a bit. I like the idealized goals of Agile, but real world implementations vary significantly.

My absolute favorite projects are when I get a semi-clear list of requirements and get to work on something entirely solo. Most frequently this happens when a project has been attempted before and has train wrecked, and has non-technical folks in charge of it. That basically removes all of the non-technical annoyances from a project and results in a delightful amount of freedom in the details.

[kyoryu]

Not really. A good amount of TDD/unit testing can help catch most obvious errors up front, and then good design to prevent overly-complex code can do wonders.

[kyoryu]

IMO, TDD for anything but trival functionality works when you can basically get all the spec written up front (so full on waterfall), otherwise the developers are really only guessing what the inputs and expected results should be and even experts in the field they're developing for will get it wrong.

Your experience of TDD does not match mine.

I use it to effectively create a specification on-the-fly. Also, unit tests shouldn't be interacting with dependencies, so those integrations with real dependencies definitely aren't unit-testable.

[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:

https://www.agilest.org/wp-content/uploads/2018/03/scaled-agile-framework-4-5-big-picture.png

[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 (https://www.scaledagileframework.com/). Isn't it glorious?

[Manga Shoggoth]

It's SAFe, the Scaled Agile Framework (https://www.scaledagileframework.com/). 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:

https://www.agilest.org/wp-content/uploads/2018/03/scaled-agile-framework-4-5-big-picture.png


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.