Working in Development: Leaving sounds like a great decision.

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Working in Development: Leaving sounds like a great decision.

«‹›434 »

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Clearly you contact the API author for each and every time that came up in the error message.

# ? Apr 26, 2017 00:41

Adbot: ADBOT LOVES YOU

# ? May 10, 2024 07:04

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

code:

try {
   serviceCall();
}
catch (Exception ex) {
    TwilioClient.Create(to: new PhoneNumber("developer's number")).Say(ex.GetMessage());
}

# ? Apr 26, 2017 01:42

xiw: Sep 25, 2011; i wake up at night
night action madness nightmares
maybe i am scum
Cpig Haiku contest 2020 winner

smackfu posted:

(And yes, all this Agile terminology is wankery but calling stuff by the wrong name does make you look uninformed.)

I really hate this right now

We're going through a process of talking about fixing our process. Scrum keeps coming up but we're not actually remotely close to doing scrum and it drives me batty because I just know someone will talk to our customers about how we're DOING SCRUM and look incredibly silly.

(I wish more agile processes were presented as 'hey this is a useful technique given the situation X and forces Y, it achieves Z' and we could just sensibly pick out the things that make sense in our situation with justification - but no, we're looking at cargo cult scrum with no product owners and hard quotes and estimating 500 hours of work up front.)

# ? Apr 26, 2017 01:47

KoRMaK: Jul 31, 2012

Holy poo poo at these polyanna stories.

ChickenWing posted:

Oh my god if someone started committing to my feature branch without at least talking to me first I would lose my goddamn poo poo

I would needle and erode them with questions of "why" like a loving 5 year old asking about the color of the sky.

# ? Apr 26, 2017 03:39

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

xiw posted:

(I wish more agile processes were presented as 'hey this is a useful technique given the situation X and forces Y, it achieves Z' and we could just sensibly pick out the things that make sense in our situation with justification - but no, we're looking at cargo cult scrum with no product owners and hard quotes and estimating 500 hours of work up front.)

Coming soon to Safari Bookshelf: Agile Process Patterns. The cover will be a black and white drawing Cthulu and it will make you crazy just looking at it.

# ? Apr 26, 2017 03:51

Volmarias: Dec 31, 2002; EMAIL... THE INTERNET... SEARCH ENGINES...

Iä! Iä! agile fhtagn!

# ? Apr 26, 2017 05:31

fantastic in plastic: Jun 15, 2007; The Socialist Workers Party's newspaper proved to be a tough sell to downtown businessmen.

Herbert West--Scrummaster

# ? Apr 26, 2017 07:25

redleader: Aug 18, 2005; Engage according to operational parameters

Clanpot Shake posted:

I had to provide support for an integration that sent us XML that didn't validate against the schema file they sent us. We had to massage the schema to generate code that would validate the requests they were sending us. You have certainly heard of the company that did this moronic thing.

...all of them?

# ? Apr 26, 2017 08:00

Messyass: Dec 23, 2003

Rocko Bonaparte posted:

Coming soon to Safari Bookshelf: Agile Process Patterns. The cover will be a black and white drawing Cthulu and it will make you crazy just looking at it.

My mind is blown that this doesn't exist yet.

# ? Apr 26, 2017 08:07

leper khan: Dec 28, 2010; Honest to god thinks Half Life 2 is a bad game. But at least he likes Monster Hunter.

Rocko Bonaparte posted:

Coming soon to Safari Bookshelf: Agile Process Patterns. The cover will be a black and white drawing Cthulu and it will make you crazy just looking at it.

Daily stand ups consist of developers presenting the team with anything blocking their progress. Hold them fast to a two minute interval -- languishing in silence, the team could tear at the fabric of reality; calling forth that madness which sleeps beyond time.

# ? Apr 26, 2017 09:41

Doom Mathematic: Sep 2, 2008

rt4 posted:

Reminds me of the job I got fired from back in January. My PRs would get rejected for not meeting their unique coding standards. When I changed one line in a 1000 line JS file, they'd expect me to fix the entire file to match their new style.

There was no automated tool you could run to fix that up?

# ? Apr 26, 2017 11:41

Keetron: Sep 26, 2008; Check out my enormous testicles in my TFLC log!

They fired that too.

# ? Apr 26, 2017 11:59

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Messyass posted:

My mind is blown that this doesn't exist yet.

What scared the poo poo out of me is that there are similar books out there. I looked it up after I posted that thinking, "There can't be... there can't be... right? Right?!"

# ? Apr 26, 2017 15:12

csammis: Aug 26, 2003; Mental Institution

KoRMaK posted:

I would needle and erode them with questions of "why" like a loving 5 year old asking about the color of the sky.

True story, when a previous company started trying to do MVP their consultant recommended this exact tactic to use on product managers asking for new features. They called it "five 'whys'" and the theory went that if you couldn't get to a concrete use case for a feature by the time you've asked "Why A? Because B. Why B?" five times then that feature isn't really necessary. It was fun the first couple of times and then the yelling / ignoring started...so yeah pretty much like a 5 year old :v:

# ? Apr 26, 2017 15:54

Doh004: Apr 22, 2007; Mmmmm Donuts...

csammis posted:

True story, when a previous company started trying to do MVP their consultant recommended this exact tactic to use on product managers asking for new features. They called it "five 'whys'" and the theory went that if you couldn't get to a concrete use case for a feature by the time you've asked "Why A? Because B. Why B?" five times then that feature isn't really necessary. It was fun the first couple of times and then the yelling / ignoring started...so yeah pretty much like a 5 year old

Oh god, using the 5 whys for product prioritization sounds atrocious. It's great for retrospectives but not that.

# ? Apr 26, 2017 16:47

Pollyanna: Mar 5, 2005; Milk's on them.

Prioritization, maybe, but for outright deciding on what features to have? It's not a bad idea. Especially cause it'll reveal features that have little-to-no justification outside of "I saw it on HackerNews once" or "marketing buzzword #7569217".

# ? Apr 26, 2017 16:51

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

Pollyanna posted:

Prioritization, maybe, but for outright deciding on what features to have? It's not a bad idea. Especially cause it'll reveal features that have little-to-no justification outside of "I saw it on HackerNews once" or "marketing buzzword #7569217".

Like the OP said, if all involved parties aren't into it as well, it'll degenerate into ignoring/yelling pretty quickly.

# ? Apr 26, 2017 16:52

KoRMaK: Jul 31, 2012

Rocko Bonaparte posted:

What scared the poo poo out of me is that there are similar books out there. I looked it up after I posted that thinking, "There can't be... there can't be... right? Right?!"

Post em

# ? Apr 26, 2017 16:58

KoRMaK: Jul 31, 2012

Skandranon posted:

Like the OP said, if all involved parties aren't into it as well, it'll degenerate into ignoring/yelling pretty quickly.

Consensual 5 whying

# ? Apr 26, 2017 16:59

Pollyanna: Mar 5, 2005; Milk's on them.

Please don't kinkshame.

# ? Apr 26, 2017 17:01

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

KoRMaK posted:

Post em

Okay it looks like they aren't full books, but an example:

Process Patterns for Agile Methodologies:

quote:

The need for constructing software development methods that have been tailored to fit specific situations and requirements has given rise to the generation of general method fragments, or process patterns. Process patterns can be seen in some third-generation integrated methodologies (such as OPEN) and in Method Engineering approaches where they are used as process components. They have also been presented as components in generic software development lifecycles where they represent classes of common practices in a specific domain or paradigm; object-oriented process patterns are well-known examples. Agile methodologies, however, are yet to be thoroughly explored in this regard. We provide a set of high-level process patterns for agile development which have been derived from a study of seven agile methodologies based on a proposed generic Agile Software Process (ASP). These process patterns can promote method engineering by providing classes of common process components which can be used for developing, tailoring, and analyzing agile methodologies.

# ? Apr 26, 2017 18:45

smackfu: Jun 7, 2004

Has anyone dealt with SAFe yet? Just the concept of "Agile but for enterprise" terrifies me.

I tried to look at the Wikipedia page but I didn't make it past the second principle.

1. Take an economic view
2. Apply systems thinking
...

# ? Apr 27, 2017 00:03

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

smackfu posted:

Has anyone dealt with SAFe yet? Just the concept of "Agile but for enterprise" terrifies me.

I tried to look at the Wikipedia page but I didn't make it past the second principle.

1. Take an economic view
2. Apply systems thinking
...

SAFe is insane voodoo horseshit. And this is coming from someone who is an Agile believer.

# ? Apr 27, 2017 00:35

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

SAFe is an excuse to do waterfall while acting like you are doing Agile.

At my place, they took it up and hoped everybody would magically become software engineers.

# ? Apr 27, 2017 03:55

KoRMaK: Jul 31, 2012

I'm currently integrating with ServiceNow again

Sharepoint for the Web 2.0

# ? Apr 27, 2017 04:19

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

I recently spent a few months contracting at a place that did SAFe across...9? teams that were all vaguely interrelated to a handful of end-user products. Every 3 months was a 2-day, full-work-stop, 'PI planning' meeting that meant that, at a guess, over 120 development staff(QA, dev, etc) sat in a room and did little more than talk about what the broad plan for the next 3 months was, and broadly speaking, management's attitude was "we will tell you WHAT we need and WHEN we need it, and you better deliver."

In one case, one of my sister teams pointed out everything in their backlog, said 'we have 100 points of capacity for this PI', and management said 'but we need this 150 points worth of features'. The team pushed back - 'sorry, we just can't do that' - and management's response was 'well, maybe if you re-organize your backlog, you can make it work.' Unsurprisingly when we went to the hilariously cultish Fist of Five show of hands, that team almost unanimously reported 1 or 2, and management was very upset they were being downers.

# ? Apr 27, 2017 04:49

Keetron: Sep 26, 2008; Check out my enormous testicles in my TFLC log!

Rocko Bonaparte posted:

SAFe is an excuse to do waterfall while acting like you are doing Agile.

And large companies jump the Agile bandwagon without actually changing anything but some titles.

# ? Apr 27, 2017 11:46

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

Keetron posted:

And large companies jump the Agile bandwagon without actually changing anything but some titles.

See my post a few days ago about the customer who renamed their "operations" team to "devops" without changing anything about how they do development or operations and now proclaims that they do devops.

# ? Apr 27, 2017 14:32

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Pollyanna posted:

Prioritization, maybe, but for outright deciding on what features to have? It's not a bad idea. Especially cause it'll reveal features that have little-to-no justification outside of "I saw it on HackerNews once" or "marketing buzzword #7569217".

It's horrendous, at least for products that are iteratively developed like most continuously-deployed hosted offerings, or mobile apps that have rapid update cycles. Lean and Kanban are the new hotness, but where they're useful is for testing yourself out of a bad idea. You can never, ever use these methodologies to accidentally test yourself into a good product. That takes a combination of vision and experimentation, and as anyone who's ever run a brainstorming session will tell you, it's absolutely impossible to experiment productively if you have people continuously shooting down each other's experiments before they can get off the ground. A good product owner should be able to explain their hypothesis for a feature and how they relate to a business's KPIs, to provide necessary context to the development team, but more than one why is usually extreme overkill.

e: to boot, the idea that developers know more than the product owners and stakeholders on what features will provide the most future value to the business is both combative and arrogant. It presumes incompetence on the part of the people making the decisions, which will never yield good results in that relationship.

Vulture Culture fucked around with this message at 15:18 on Apr 27, 2017

# ? Apr 27, 2017 15:07

vonnegutt: Aug 7, 2006; Hobocamp.

Vulture Culture posted:

e: to boot, the idea that developers know more than the product owners and stakeholders on what features will provide the most future value to the business is both combative and arrogant. It presumes incompetence on the part of the people making the decisions, which will never yield good results in that relationship.

Also, devs (myself included) are biased towards preferring features that are interesting to code, don't require weird workarounds, and aren't redundant or repetitive. Stuff like internationalization is always going to be on my poo poo list to build, but I know it's important. Other things, I might not know why it's important, but I'm not talking to our users and I'm not in marketing, so I'm going to have to take their word for it.

I've seen what happens when a team of devs decide to greenfield a product with no market research and no businesspeople. You end up with some marvel of overengineering that solves a ridiculously unlikely problem but has a UI that requires the user to perform 15 steps precisely in order to do anything. It's awful.

# ? Apr 27, 2017 17:04

lifg: Dec 4, 2000; <this tag left blank>; Muldoon

vonnegutt posted:

Also, devs (myself included) are biased towards preferring features that are interesting to code, don't require weird workarounds, and aren't redundant or repetitive. Stuff like internationalization is always going to be on my poo poo list to build, but I know it's important.

I didn't give a drat about Unicode until I heard someone mention that normalization is nearly impossible. Then it piqued my interest.

That's the key to getting devs to do something boring. Tell us it hasn't been solved adequately yet.

# ? Apr 27, 2017 18:56

csammis: Aug 26, 2003; Mental Institution

Vulture Culture posted:

e: to boot, the idea that developers know more than the product owners and stakeholders on what features will provide the most future value to the business is both combative and arrogant. It presumes incompetence on the part of the people making the decisions, which will never yield good results in that relationship.

In all fairness I should say that developers weren't part of this 5-whys-with-product-managers process. My part in this was as a senior architect over a subset of a large enterprise content management platform, and I was a product owner in my own right. Part of my role was to take feature requests from people who were not engineers or even necessarily system experts and turn them into engineering enhancements that kept the platform more or less cohesive. Quite often a product manager or sales person would come to engineering with a feature request that could already be solved by some lesser-known part of this massive system, so drilling down into feature requirements wasn't a waste of time.

That having been said almost all of our product mangers were very competent and 5-whys is built around the tactics of literal children so...yup. I already said it didn't go well

Hell at least we actually talked about adding features to the platform itself. Our system had a scriptable interface that was a dialect of Javascript, so really freaking easy to pick up on. 95% of our feature requests could have been responded to with "have professional services write them a script," the actual execution of which caused 98% of my alcohol intake.

csammis fucked around with this message at 19:43 on Apr 27, 2017

# ? Apr 27, 2017 19:38

Gounads: Mar 13, 2013; Where am I?
How did I get here?

smackfu posted:

Has anyone dealt with SAFe yet? Just the concept of "Agile but for enterprise" terrifies me.

I tried to look at the Wikipedia page but I didn't make it past the second principle.

1. Take an economic view
2. Apply systems thinking
...

I'm currently contracting at a SAFe shop, and have been really surprised at how not-terrible it is.

They actually pushed "agile" up through marketing, sales, management, all the way to the CEO. Their corporate forecasts are built around product increments. They have two gigantic partner deals going on, and even the contracts for those were based around PIs. Work actually flows from the top in a predictable manner. I haven't been surprised by a request from management since I started 5 months ago.

There is absolutely a huge amount of waste and dumb-assery. This past PI planning was down to two days from it's usual 3, but my team could probably have banged it out in two hours of a video call. Work moves slow.

All that said, I'm sure SAFe is a loving train wreck at most places.

# ? Apr 27, 2017 21:14

Rubellavator: Aug 16, 2007

I actually used to work on a team that did 2 days of sprint planning every 2 weeks. Day 1 was writing, pointing, assigning, and reviewing stories. Day 2 was breaking each story down into tasks with hour estimates. Each task was collected into a giant spreadsheet that we would get together and review again to make sure no one person was taking too much.

All of this would eventually be managed by stickies on a wall, and our PL would take about an hour to write down everything and move it over into excel.

# ? Apr 27, 2017 23:06

Ghost of Reagan Past: Oct 7, 2003; rock and roll fun

Having devs do bug triage is a recipe for disaster, I feel. No way it doesn't end up making someone mad.

It feels like it's tailor-made for devs, who certainly don't have the product knowledge of stakeholders or QA, to make mistakes and cause unnecessary friction.

Ghost of Reagan Past fucked around with this message at 23:51 on Apr 27, 2017

# ? Apr 27, 2017 23:46

Space Kablooey: May 6, 2009

Ghost of Reagan Past posted:

Having devs do bug triage is a recipe for disaster, I feel. No way it doesn't end up making someone mad.

On the flip side, there's no way to please everybody.

# ? Apr 27, 2017 23:51

Ghost of Reagan Past: Oct 7, 2003; rock and roll fun

HardDiskD posted:

On the flip side, there's no way to please everybody.

This is true as well.

# ? Apr 27, 2017 23:54

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

There's a sudden discussion at work around BDD - and so I played around with the general principle today and...can anyone here explain what in the hell I'm misunderstanding or missing about all of this? It seems like an extra layer of complexity, which means an extra layer in which poo poo can get hosed up, all for the sake of...'translate all of our requirements into a series of limited DSL definitions'?

# ? Apr 27, 2017 23:58

Mniot: May 22, 2003; Not the one you know

Cuntpunch posted:

There's a sudden discussion at work around BDD - and so I played around with the general principle today and...can anyone here explain what in the hell I'm misunderstanding or missing about all of this? It seems like an extra layer of complexity, which means an extra layer in which poo poo can get hosed up, all for the sake of...'translate all of our requirements into a series of limited DSL definitions'?

I did a medium-sized REST API test suite that was basically like https://github.com/grantcurrey/cucumber-rest#full-example

It was OK. The good parts were: we changed the implementation language of the tests (from lovely JS to less-lovely Python) and just had to rewrite command definitions -- the tests themselves stayed the same so we knew we weren't screwing up. Also, it's harder to get an incomprehensible test failure even when the devs writing the tests are real lazy.

The bad parts are obvious: the DSL is dumb and limiting and you're adding another layer of indirection. Code reuse isn't part of the gherkin language so it's pretty ugly. I wouldn't do it again, but I wouldn't be mad if I got handed some code that had BDD-style tests. It helps if you imagine that you're playing Polaris when writing the tests.

The claim of BDD (I think) is that your PM or (god forbid) marketing team can write their requirements into the DSL. Or maybe they're just supposed to be able to read it? I haven't had a PM or marketer who would consider doing either so I donno.

# ? Apr 28, 2017 04:23

Adbot: ADBOT LOVES YOU

# ? May 10, 2024 07:04

Messyass: Dec 23, 2003

Mniot posted:

I did a medium-sized REST API test suite that was basically like https://github.com/grantcurrey/cucumber-rest#full-example

[...]

The claim of BDD (I think) is that your PM or (god forbid) marketing team can write their requirements into the DSL. Or maybe they're just supposed to be able to read it? I haven't had a PM or marketer who would consider doing either so I donno.

That's a horrendous use of Gherkin. Of course the PM isn't going to read that. It's a purely technical test and doesn't explain the business value at all.

If you do BDD right, you work together with the PM/analist before implementation to come up with a set of examples that expresses the value of the story in terms that the business understands but that can also be implemented as tests. It can be a challenge to find this ubiquitous language, but that's also exactly what will help you in the long term. As a bonus a suite of well written, business readable test provides you with living documentation.

A well designed system will have most BDD tests implemented at the unit level / domain model, and not at the API level or UI level. That also makes it much easier to write tests that are actually functional and aren't bogged down by technical details.

# ? Apr 28, 2017 07:21

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Working in Development: Leaving sounds like a great decision.

«‹›434 »