Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
AskYourself
May 23, 2005
Donut is for Homer as Asking yourself is to ...
They are being serious but I guess you are wondering about the love-hate relationship of Agile... Yeah it's weird.

Usually, when business want to implement Agile it's because of a need to have numbers on productivity. What Devs want is well specced, small chunk of work that can be implemented without sacrificing quality.

One party want number to generalize management of cat-herding, while the other party want clear goals to attains.

When Agile does not go well, it's because the goal are not oriented.

As other have said, the moment you start measuring Velocity, put it in an admin dashboard, and use it as some form of retro-feedback source is when poo poo hit the fan. That's when workers and manager start resenting each other.

Adbot
ADBOT LOVES YOU

100 degrees Calcium
Jan 23, 2011



Messyass posted:

And in that case demand that at least the same amount of energy is devoted to estimating the value of the feature.

God, I wish.

ChickenWing
Jul 22, 2010

:v:

I swear to god the longer SIT goes the more I come to understand why people hate null.

Vulture Culture
Jul 14, 2003

I was never enjoying it. I only eat it for the nutrients.

Messyass posted:

Just stop estimating effort, unless it is to make an honest decision whether to deliver a certain feature or not. And in that case demand that at least the same amount of energy is devoted to estimating the value of the feature.
Bingo. I never understood the value in trying to get a handle on things that are naturally going to wax and wane. People's energy levels are up and down throughout the year, and their productivity goes up and down accordingly. You learn a lot more from understanding what's going on in your team members' lives than you ever can from a burn-down chart.

The main value of estimating is figuring out ROI. If you've already decided you're going to do the feature or fix the bug, what's the loving point?

Destroyenator
Dec 27, 2004

Don't ask me lady, I live in beer
In defence of estimates/velocity:
Good estimates can help with feature prioritisation in time sensitive projects.
Good estimates can give you projections of estimated completion dates.
Doing estimates as a group can be useful to share knowledge and expectations (especially if everyone isn't involved in grooming).
Tracking expected/completed work in a sprint and reviewing it with the team can help reveal problems in your estimation, or to surface distractions or impediments the team had to deal with.
Sometimes falling velocity can be useful to force issues with management eg. "our tech debt is getting to painful levels", "we have to support this other team too much", "we had too many bugs need to spend more time on testing".

It is misused constantly though and what you should push when people get lovely about velocity is: Failing meet the sprint forecast is either due to incorrect estimates or misunderstanding of the team's availability that sprint.

ToxicSlurpee
Nov 5, 2003

-=SEND HELP=-


Pillbug
One of the core problems that can probably never be fixed is the fact that people hiring coders often have no idea what coders actually do.

I'm quite glad my boss is a huge tech nerd because, well, sometimes a programmer is sitting in his cube looking like he's just staring off into space. OK, that is sometimes what he's actually doing but other times it's turning over options in one's head and considering tradeoffs. Sometimes I'm trying to come up with an algorithm to do something. Other times I'm hunting a bug and trying to figure out just what the gently caress caused it.

There is never one "best" answer and no code is ever perfect. It just isn't easily predictable what bugs will crop up, when, and what will cause them. Sometimes production grinds to a halt for a week while the team tracks down some bugs that absolutely must be fixed before anything more goes in. Every decision has ramifications and you have to end up planning for that.

The other thing is technical debt. Technical debt, if you don't fix it, collects interest. That small pile of debt right now can very easily totally cripple the whole operation if you ignore it for a year but the boss only gives a poo poo about numbers. Fixing problems and reducing technical debt isn't adding new features and new features are what we sell.

Plus every single time you come up with any sort of metric to measure the productivity of a programmer you have put a system in place that can be gamed and somebody will game it. This is especially true if you put programmers in competition with each other in any way.

AskYourself
May 23, 2005
Donut is for Homer as Asking yourself is to ...
And it's specifically easy for us to reverse-engineer how those number are calculated and to game the system.

Gounads
Mar 13, 2013

Where am I?
How did I get here?
CEO: Can you code-review this ticket to remove feature XXX because it was taking to long for the page to load.
Me: Where did this ticket come from? It doesn't make sense that feature would take long to load.
CEO: I wrote it
Me: Did you check to see if it was feature XXX causing the problem? Don't a bunch of our customers rely on this?
CEO: ...

I'll leave it to you to guess whether it was feature XXX that was slow or not.

necrobobsledder
Mar 21, 2005
Lay down your soul to the gods rock 'n roll
Nap Ghost
Development is one of the closest things to an artistic set of output the closer you get to doing something that's actually creating something new. A lot of software development is pretty much just business plumbing and is much easier to estimate due to the lack of actual innovation happening in the work. The problems begin when boring software managers think that R&D should be treated like an assembly line and go whole hog Taylorist management thinking that the methodologies are realistic or even close to accurate. So far I've mostly seen people trying to give the impression to people ponying up millions of dollars that they know what's going on and can give some confident projections about whether things will get done or not. Whether their methods work is never called into question unless deadlines are long gone or whoever is funding starts to get pressured by someone else.

Volmarias
Dec 31, 2002

EMAIL... THE INTERNET... SEARCH ENGINES...

necrobobsledder posted:

A lot of software development is pretty much just business plumbing

Heaven knows that when something goes wrong, poo poo starts spewing everywhere

Keetron
Sep 26, 2008

Check out my enormous testicles in my TFLC log!

Volmarias posted:

Heaven knows that when something goes wrong, poo poo starts spewing everywhere

QA is like a sewer, if it is done well you won't notice but if it goes wrong everything smells like poo poo.

smackfu
Jun 7, 2004

For our team, they laid off the QA contractors right before Christmas so we are just "going to have to point a little higher" and "velocity will go down" but "quality should remain just as high."

Hmm.

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

smackfu posted:

For our team, they laid off the QA contractors right before Christmas so we are just "going to have to point a little higher" and "velocity will go down" but "quality should remain just as high."

Hmm.

They got it backwards. Velocity up and quality non-extant.

Keetron
Sep 26, 2008

Check out my enormous testicles in my TFLC log!

smackfu posted:

For our team, they laid off the QA contractors right before Christmas so we are just "going to have to point a little higher" and "velocity will go down" but "quality should remain just as high."

Hmm.

Red Alert! Cutting QA is sure signs of a company in trouble and soon to be much more trouble. Run while you have a will to live.

Gildiss
Aug 24, 2010

Grimey Drawer

Keetron posted:

Red Alert! Cutting QA is sure signs of a company in trouble and soon to be much more trouble. Run while you have a will to live.

Yeah time to update that resume.

I do that every 3 months regardless of the current situation.

Iverron
May 13, 2012

Keetron posted:

Red Alert! Cutting QA is sure signs of a company in trouble and soon to be much more trouble. Run while you have a will to live.

What if you've never had QA despite much protest and still have quarterly meetings about "reducing bugs" anyway?

:shepicide:

Volmarias
Dec 31, 2002

EMAIL... THE INTERNET... SEARCH ENGINES...

Iverron posted:

What if you've never had QA despite much protest and still have quarterly meetings about "reducing bugs" anyway?

:shepicide:

Then you're already in hell.

Keetron
Sep 26, 2008

Check out my enormous testicles in my TFLC log!

I have been contributing from my phone, figured I should introduce myself a bit.
39 yo jerk-of-all-trades who went from oddjobs to manual testing to management and since about a year to test automation. I have been in the testing and QA field for nearly 15 years and only been writing code for money since about 4 months. To get from "I hate my life, I want a change in work" to getting paid for coding took me about 8 months of self teaching the in-demand languages and frameworks. My only formal education is my country's High School equivalent.

My job is mostly to automate interface tests, this can be SOAP calls with XML stubs or front-end GUI tests. The goal is to have an robust, easy to run testset we can run over every commit all the time. In daily practise we come close to this by having Jenkins deploy a Docker environment, run the tests and report whatever the result for every commit to remote on all branches. It is pretty cool actually because when people ask me if something is ready for Main, I first check the regression set. Of course I add to this set using the same story the feature is based on and either the developer is done first or I am done first, we work in the same feature branch and when we both commit our code, the tests, old and new, should all be green. There is an agreement to only merge code into main from a feature or bugfix after the branch tests are all green, this goes wrong a lot because why make a new branch for a super small fix that won't hurt anyone, I swear this code touches nothing else. Luckily we have nightly builds on main as well, whether or not something changed. I hardly write bugs, we fix things right away. Big thing to do is to have this test also run on the Chain Environments but I have some technical challenges to overcome first.

This is by far the best way of working I have seen so far and appearantly the lead engineer who thought this was a good idea when he read about it last year is giving talks to other companies on what we do with what tools. This is a huge international financial and yet the teams can work pretty Agile on features for the modular applications we write. It could be different elsewhere in the company, I don't know.

I seem to have a knack for whatever it is I do as I receive constant positive feedback and two teams both approached me to get to work on their stuff. I just want to sit in a quiet little corner and code up more tests so I stay as long as I given that. Considering I work as an independant contractor, life is good as long as demand is high. The craziest thing I have found is that this feels like the easiest money in my life as I can do my work close to effortless and I don't know why there is so much difficulty finding others willing and able to do the same. So to all people considering to write code for money, QA is not that bad but make sure you stay away from manual testing as that is the shittiest thing.

ProofTechnique
Jan 8, 2017

Keetron posted:

Considering I work as an independant contractor, life is good as long as demand is high.

General advice (if you're in the US, anyway) for people like you: If you haven't already, consider establishing yourself as an S corp. It's a bit more bookkeeping, but taxes are way more favorable than the double-loving that is the usual 1099 grind. Also, start a SEP IRA if you haven't already. It's a great fit for contractors and other self-employed types. I spend $15 a month on payroll and I've got a robot managing my IRA, and I've never felt more on top of my stupid life. The IRS oughta be pleased, too.

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

ProofTechnique posted:

General advice (if you're in the US, anyway) for people like you: If you haven't already, consider establishing yourself as an S corp. It's a bit more bookkeeping, but taxes are way more favorable than the double-loving that is the usual 1099 grind. Also, start a SEP IRA if you haven't already. It's a great fit for contractors and other self-employed types. I spend $15 a month on payroll and I've got a robot managing my IRA, and I've never felt more on top of my stupid life. The IRS oughta be pleased, too.

How expensive/onerous is setting this stuff up? I currently primarily work as a full time employee, but have some moonlight stuff and personal commercial projects planned over the next year or two. Is there any specific type of accountant and/or lawyer I should find to explain and set things up?

Being able to use that money coming in for capex without paying as much taxes on it would be awesome..?

ProofTechnique
Jan 8, 2017
Depends on your state, really. I think all told the setup costs for my company were a couple of hundred bucks tops between registrations with the Department of State and some other forms. It's a moderate hassle (writing bylaws, filling out forms, mailing poo poo out), but the turnaround time is pretty good, and then once you're an LLC you just send the IRS a form that says "this is structured as an S corp, k?"

If nothing else, it's a good way to silo your moonlighting, and it gives you more write-off opportunities. The major benefit is that as long as you pay yourself a reasonable wage (look around your area to find out what "reasonable" means), you can take the rest of the money as a distribution. Your regular wages are subject to FICA and such, but the distributions are only subject to income tax.

By all means, meet with an accountant if you like, but mainly it's just looking up what forms and fees you need to put together and then registering with the state.

EDIT: Oh, and for the IRA stuff, just sign up for something like Vanguard or Betterment. Way too easy, and then you just have them auto-deposit money once a month. The benefit to the SEP for the self-employed is that if you have an unusually profitable month, you can dump that extra cash into the SEP to lower your tax burden (up to $50k/annum, IIRC, rather than the normal IRA contribution limit of $5k/annum).

ProofTechnique fucked around with this message at 22:55 on Jan 8, 2017

Doc Hawkins
Jun 15, 2010

Dashing? But I'm not even moving!


It's either 50k or 25% of your income, whichever is less. I don't know how that interacts with unusually profitable months. Maybe you can put in more than 25% of one quarter's revenue, as long as it's within limits at the end of the year? :shrug:

Munkeymon
Aug 14, 2003

Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.



My current employer switched to FinancialForce this year and boy howdy it must be nice to write software that the purchaser never has to use. I mean, except that you end up with a SalesForce-shaped stain on your resume, but I guess some people are into that?

Our internal company guide's step 1 is "Switch to the Classic view" and well [internal screaming intensifies]

FlapYoJacks
Feb 12, 2009
Working in Development: [internal screaming intensifies]

Doghouse
Oct 22, 2004

I was playing Harvest Moon 64 with this kid who lived on my street and my cows were not doing well and I got so raged up and frustrated that my eyes welled up with tears and my friend was like are you crying dude. Are you crying because of the cows. I didn't understand the feeding mechanic.

ratbert90 posted:

Working in Development: [internal screaming intensifies]

This is me all day every day

Keetron
Sep 26, 2008

Check out my enormous testicles in my TFLC log!

Yesterday I was working in a different spot amongst people who don't code and I have to learn to keep the profanities down it seems.
I was unaware how loud I am when maintaining other people's garbage.

Mniot
May 22, 2003
Not the one you know

Keetron posted:

Yesterday I was working in a different spot amongst people who don't code and I have to learn to keep the profanities down it seems.
I was unaware how loud I am when maintaining other people's garbage.

I always assume that scream-coders are doing it intentionally so that everyone will be too afraid to ask them for help.

The software engineer’s guide to asserting dominance in the workplace

Pollyanna
Mar 5, 2005

Milk's on them.


Bongo Bill posted:

Every bug happens because a previous story was done wrong.

If this happened because it was accepted when it should not have been, then the effort spent on "fixing" it is actually additional effort correctly implementing a rejected story. If it's like that, there's a case to be made that the bug should not be estimated, because the ensuing reduction in velocity is actually accurate - it really did take that amount of time to do it right, and consistently measuring it that way will account for the friction introduced by inevitable human errors. This carries the caveat that it takes a very disciplined organization to process that information effectively; it can exacerbate the consequences of existing bad incentive structures, to say nothing of the complications introduced by prioritization.

On the other hand, if the bug is something that was not touched on in the original story, then it's better thought of as an expansion of the scope of that story. That means it merits re-estimation, and the difference between the original estimate and the new one might as well be applied to the bug itself.

Most teams are probably better off estimating bugs.

I mean, ultimately, like everything else, it comes down to "Why is this being measured?"

What about occasions where the change or feature by all accounts passed every single measure of acceptance testing, but resulted in a weird fuckup further down the line or somewhere unpredictable in a different part of the product? What happens when pulling on one string in the web fucks up another part?

ratbert90 posted:

Working in Development: [internal screaming intensifies]

basically

Mniot
May 22, 2003
Not the one you know

Pollyanna posted:

What about occasions where the change or feature by all accounts passed every single measure of acceptance testing, but resulted in a weird fuckup further down the line or somewhere unpredictable in a different part of the product?

Generally, we shouldn't expect that production will be 100% bug-free. Developers have no incentive to do that and I've never worked at a place where it was treated as important. (Screaming at people when a production bug is found doesn't count.) That said, hopefully you do a little postmortem and decide "we should add a test for usernames that are entirely emoji" or "we're not able to test on Windows Phone, so that platform is unsupported".

What's an example of a weird fuckup further down the line? I can think of bugs that had complicated steps to produce, but could always have been caught if we'd just had one more automated test cases.

quote:

What happens when pulling on one string in the web fucks up another part?

Either you anticipate this in advance and "fix a spelling error in the navbar" is estimated as a 2 month job, or you only realize that things are hosed halfway in and you have to tell the team that the job is way bigger then you all thought. If it happens all the time, then you've got a code-base in need of some cleanup.

The frustrating thing when I was doing "Scrum" is that management treated the sprint as an iron-clad promise, so getting an estimate wrong was unacceptable and you'd get all the developers dumping a gently caress-load of code onto QA the night before the sprint end.

Iverron
May 13, 2012

Keetron posted:

Yesterday I was working in a different spot amongst people who don't code and I have to learn to keep the profanities down it seems.
I was unaware how loud I am when maintaining other people's garbage.

I moved offices the other day and warned the other guy I now office with about my doing this. Turns out he's the same way.

Profanity is our one light in the darkness.

Ghost of Reagan Past
Oct 7, 2003

rock and roll fun

Iverron posted:

I moved offices the other day and warned the other guy I now office with about my doing this. Turns out he's the same way.

Profanity is our one light in the darkness.
"Who the gently caress wrote this poo poo?"

*git blame*

"gently caress me."

Maluco Marinero
Jan 18, 2001

Damn that's a
fine elephant.

Ghost of Reagan Past posted:

"Who the gently caress wrote this poo poo?"

*git blame*

"gently caress me."

It's never not funny to realise the code is yours as you're griping about it.

Bongo Bill
Jan 17, 2012

Ghost of Reagan Past posted:

"Who the gently caress wrote this poo poo?"

*git blame*

"gently caress me."

git-blame-someone-else

ToxicSlurpee
Nov 5, 2003

-=SEND HELP=-


Pillbug

Munkeymon posted:

My current employer switched to FinancialForce this year and boy howdy it must be nice to write software that the purchaser never has to use. I mean, except that you end up with a SalesForce-shaped stain on your resume, but I guess some people are into that?

Our internal company guide's step 1 is "Switch to the Classic view" and well [internal screaming intensifies]

Name recognition, I imagine. SalesForce is a steaming pile but some HR person that knows absolute balls about technology could see that and go "oh I know what that is" or "we use that I shall put this in the pile" and get you past that filter.

Iverron posted:

I moved offices the other day and warned the other guy I now office with about my doing this. Turns out he's the same way.

Profanity is our one light in the darkness.

All of my coworkers sound like sailors pretty much. I was kind of worried that I'd let some profanity slip and get reprimanded/fired. I tend to swear a lot but can keep it under wraps 99% of the time when necessary.

Then my boss said "gently caress" about 40 times in a meeting. We tech nerds basically have our own wing of the office that's pretty separate from sales and whatever. People that swing by for whatever reason apparently are well aware that this is our territory and we'll loving talk the way we drat WELL please. Some places just don't give a crap about swearing. I think this especially applies to tech pros because what techies deal with is frequently frustrating and rage-inducing.

One of our top techs is...very passionate. I hear him punch a wall about once a month. He's actually a really nice guy otherwise but does he get livid at big enough problems. I've never seen him get mad at people but devices sometimes piss him off.

Maluco Marinero
Jan 18, 2001

Damn that's a
fine elephant.
Eh, honestly I think it's a sign of unoriginality and a lack of vocabulary/communication skills, than any sort of philosophical stand. Swearing all the time is just such low effort.

Like this stuff just ain't worth it. I've worked among others in scenarios where mistakes result in death/grevious injury with less cursing.

redleader
Aug 18, 2005

Engage according to operational parameters
The emotions run high because the stakes are so low.

Slash
Apr 7, 2011

Maluco Marinero posted:

Eh, honestly I think it's a sign of unoriginality and a lack of vocabulary/communication skills, than any sort of philosophical stand. Swearing all the time is just such low effort.

Like this stuff just ain't worth it. I've worked among others in scenarios where mistakes result in death/grevious injury with less cursing.

Surely not using swearwords reduces your vocabulary; by definition you are using fewer words.

spiritual bypass
Feb 19, 2008

Grimey Drawer
People should learn to feel their feelings without letting them crudely rule their behavior imo

Gildiss
Aug 24, 2010

Grimey Drawer
OK fine so no cursing at the code.
But what about cursing at terrible PM's and managers? Also at the people who write the bad code?

Adbot
ADBOT LOVES YOU

ChickenWing
Jul 22, 2010

:v:

ill say what i loving want :clint:

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply