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
comedyblissoption
Mar 15, 2006

How are Agile sprints and commitments in a software development context sane in any way?

How does it make sense to commit to accomplishing work in a fixed time-frame that can easily overrun estimates?

Is there some psychological trickery involved in defining sprints and short-term deadlines that can result in greater productivity for some teams?

Sprints only make some sense to me in an organization that uses a source control system that makes it difficult to branch and merge new features (e.g. SVN). Sprints in this context would have the benefit of defining an endpoint of getting the code back into a stable state from a shitfest free for all of untested and interim commits.

Why not use a kanban approach where you just set priorities of estimated items and it's okay if they overrun their estimate because that is part and parcel of software development?

Adbot
ADBOT LOVES YOU

comedyblissoption
Mar 15, 2006

Ithaqua posted:

Kanban isn't a project management methodology. It's an apples-to-tractors comparison.
I was comparing a sprint-based methodology to a kanban-based methodology. Both methods are promoted under the nebulous and undefined "agile" umbrella.

comedyblissoption
Mar 15, 2006

Cuntpunch posted:

What I'm saying is that people go so goddamn hung up on these *ideas* without *practical application* that means a drat, that they end up figuring if they can quote SOLID or draw a Factory Pattern, that's all that matters. Want to develop software? Great! It's a cool job! But learn it by *DOING IT* not by *reading about it*. The constant fallback of the bad developer to tropes and terminology just points to me as a failing of spending too much time *reading* about how nails work, rather than hammering wood together.
Working professionals in the industry in general cannot agree on what good software design looks like. "Good" software design is extremely controversial!

Very fundamental aspects of software design like pervasive mutability vs pervasive immutability, use OOP implementation inheritance vs not, or static typing vs dynamic typing cannot be agreed upon.

comedyblissoption
Mar 15, 2006

smackfu posted:

What's so hard about SVN and branching for every story? Not as lightweight as git but seems workable.
I tried it and it doesnt loving work.

Merging is a huge loving pain.

If the dumb metadata files that svn shits all over your codebase (for merging purposes I think) are just SLIGHTLY messed up, all your merges are probably gonna get super hosed up.

Those metadata files I think are corruptible by SVN itself w/o anyone explicitly loving w/ them. At least that's seemingly what happened to me when I tried branching!

I got so frustrated I checked the SVN branch and main development into GIT and did the merge that way and it was a lot better. When that happens, you question why are you even using SVN...

comedyblissoption
Mar 15, 2006

In the early twentieth century there were lots of industrial studies done on what is the optimal work week and businessmen discovered that working your employees to death was counterproductive and that optimal productivity for the mean worker converged around 40 hours or thereabouts.

Henry Ford was cajoled by his peers for reducing the work week of his workers based on empirical evidence and was cited as a threat to industry.

The industry as a whole probably came around to the idea that working your workers to death is counterproductive.

These labor studies were done on labor that was far more menial than software development.

Businessmen and management in software are basically incredibly and willfully ignorant of these facts so that they can satisfy their childish and non-empirical notions of productivity and puritan work ethic. It also sometimes sets up an abusive and exploitive work relationship i guess.

I think there are definitely people that can still maintain productivity well above 40 hours, but those are not mean mortals.

comedyblissoption fucked around with this message at 13:47 on Jul 26, 2016

comedyblissoption
Mar 15, 2006

if theyre savvy/lucky they'll get promoted or receive a windfall before the consequences of their decisions can be realized

comedyblissoption
Mar 15, 2006

why does US culture continue the insult of being expected to give employers 2 weeks notice to quit but employers are not expected to extend the same courtesy when they fire you

comedyblissoption
Mar 15, 2006

KoRMaK posted:

I still don't understand how to merge conflicts in svn. Like, is it like sourcesafe where two people just shouldn't work on the same file at the same time?
You recreate your branch history in git, merge rebase it on top of trunk, then push your rebased commits to svn.

I've literally done this manually and it was a better experience than branch merging in svn. I didn't use git-svn because our svn repository was too big.

comedyblissoption
Mar 15, 2006

the killer feature of git over svn by far is being able to easily merge branches. this allows you to create small self-contained branches for each feature you develop.

svn makes it easy to create branches, but it completely misses the point by making it a really loving terrible experience to merge. thus, most people using svn avoid branching and only really use it in a hamfisted way to section off older versions of the software.

the svn way of not using branches for features suck, because what ends up happening on most development teams is that you have to work with a bunch of in-progress half-finished bullshit other people are pushing to the central repository that might break your poo poo and then you have to keep tracking down these problems over and over again

comedyblissoption
Mar 15, 2006

this is a superior way to develop even if you're literally just a 1-man dev team

comedyblissoption
Mar 15, 2006

Putting an estimated amount of work in a sprint and then "committing" to finishing the work is inherently contradictory. Estimates are estimates and not concrete timelines. Software development estimates have large windows of variability. A points based velocity is also a large window of variability. The only way you could possibly hit sprint "commitments" on a regular basis is to consistently undercommit, and lol if you think you can expect everyone to go along w/ a perception of intentional sandbagging. If somehow you are able to convince people to undercommit, then you have obnoxious bikeshedding about what to do when people run out of committed work for a sprint.

A cynical mind will view such an insane system as an attempt to get salaried employees to much more likely work significant overtime.

comedyblissoption
Mar 15, 2006

lifg posted:

I spent so long in college learning about time v space trade-offs in programming, but software development is all about development speed v correctness of new features. This little fact is something that didn’t really sink in until just recently when I read the Google SRE book.

Do other professions have this weird chasm between school and work? Is this like how lawyers (according to My Cousin Vinny) learn theory in school, and expect their firms to train them in practice?
Learning about data structures and time vs space trade-offs improves your development speed and correctness. You'll know immediately why you should use a stdlib dictionary instead of a nested for loop of huge time complexity and spend 1 second thinking about it and move on.

comedyblissoption
Mar 15, 2006

ratbert90 posted:

Yeahhhhhh that interview.

One of the older engineers I would have been replacing is PROUD of his ancient code having everything statically allocated and all of his variables global.
He said he wasn’t quite sure how many he had, but well over 1,000 by now.

No thanks. Nooooooope. Gonna walk away now.
How do you suss out that someone loves global variables and is allergic to dynamic allocation? Do you ask them questions about their codebase or do they just trumpet their pride at any chance they get to an interviewee?

I'm asking b/c getting someone to reveal this information would help me out whenever I interview.

comedyblissoption
Mar 15, 2006

baquerd posted:

Software engineers having a union would at least be a very clear signal to anyone decent to stay the gently caress away from that company. Engineers are only being exploited by lovely companies, the companies you want to work for are showering their workers with money and benefits.
Do you think big tech companies colluding to depress worker salaries doesn't count as exploiting workers as long as those workers were paid well above the median? Does this also make them not "lovely"?

comedyblissoption
Mar 15, 2006

baquerd posted:

Because they can get bigger yachts that way.

I only claim that unionization is not going to help the problem because when the incentives to work hard to get ahead go away and are replaced with rules lawyering and seniority bullshit, overall productivity hits the shitter and there go the wages.

Edit: and my original claim that only lovely companies are exploiting their engineers stands. Giving someone 300k total comp instead of 350k is not exploitation.
businessmen organizing together: good
workers organizing together: bad

Also, increased productivity doesn't mean increased wages. Productivity increases are decoupled from wage increases in the United States. Decent compensation compared to the median for developers has a lot more to do with low supply of skilled labor rather than their productivity. Even then, tech companies are some of the most profitable companies per dollar because they don't pay workers in accordance with their productivity. Pay will decrease if the industry is able to massively increase the pool of capable developers.

baquerd posted:

So all you union lovers, why don't you go ahead and found one? See how that goes? If you can organize enough people you can probably succeed, all you have to do is convince people to risk their cushy jobs in exchange for likely industry infamy, paying union dues, and nebulous promises about how it will actually be good for them?
worker co-ops are a better idea

comedyblissoption fucked around with this message at 02:19 on Feb 20, 2018

comedyblissoption
Mar 15, 2006

KoRMaK posted:

Elaborate. Assume I know as much as an 11 year old please.
Traditionally, a tiny group of people owns a business and undemocratically makes all the important decisions for everyone else of what to produce, how to produce, where to produce, who produces, and what to do with what is produced.

In a worker co-op, workers democratically own the business and make these decisions instead. Workers are collectively their own boss. This can take different forms. Workers can manage the business themselves. Alternatively, workers can hire their own managers instead of the other way around.

If you want an elaboration of this idea:
https://www.youtube.com/watch?v=BDiDt74Fyss

comedyblissoption
Mar 15, 2006

baquerd posted:

Sounds like Holacracy, which fails horribly at scale: http://nslsfacts.org/2017/09/26/lost-utopia-why-did-holacracy-fail/
https://en.wikipedia.org/wiki/Mondrag%C3%B3n_Cooperative_Corporation
the world's largest worker-coop has scaled to 74k employees and has been around for over 60 years

comedyblissoption
Mar 15, 2006

B-Nasty posted:

There's a big reason why worker co-ops are rare: how do you account for the risk during their creation? Founders of businesses take on an enormous amount of risk, both with their unstable employment (opportunity cost) and their material investment. Additionally, how does one get early loans or investment without offering some stake in the business?

It's easy to come along after a business is running smooth and start demanding ownership, but that ignores everything that made it successful enough to entertain such folly.
Worker coops can get money in many of the same ways a business gets money to start a business.
https://www.youtube.com/watch?v=87395oUPDR0

baquerd posted:

That company does almost entirely labor and other physical goods and services. Not software.
Tech worker coops exist.

Note that I'm not telling you to go out and start a worker coop right now or that anyone in this thread should. I am just informing people of pro-worker alternatives to unions.

comedyblissoption
Mar 15, 2006

Holacracy seems like an attempt to give people a faux democracy in the hopes of generating more profit for the actual owners of the business.

comedyblissoption
Mar 15, 2006

baquerd posted:

Any examples an average person is vaguely likely to have heard of? I admit I could be totally wrong, but why do you think that given the vast array of smart and motivated individuals across the industry, these are virtually unheard of? How do you explain that worker coops and unions comprise an overwhelming minority of the workplace?
You are absolutely right that unions and other pro-worker organizations are dying in the United States. The explanation is that the business community in the United States has successfully convinced workers that organizing is not in their interest and has many tools to kill worker organization. You might also notice such facts like the business community in the United States successfully convincing half of Americans that global warming is a hoax or not caused by man.

comedyblissoption fucked around with this message at 04:38 on Feb 20, 2018

comedyblissoption
Mar 15, 2006

If your definition of competitive is to pay workers as little as you can get away with, then yeah pro-workers organizations are going to be uncompetitive. Other countries do have a stronger union sector than the US that is able to compete with US companies.

comedyblissoption
Mar 15, 2006

I never said it was easy.

Also, banks lend money to worker coops in a similar manner like traditional businesses.

comedyblissoption
Mar 15, 2006

Keep in mind that established companies in the tech industry have much larger profit margins than other sectors of the economy. You would need a farcical definition of exploitation to look at for example apple's profit margins and come to the conclusion that no worker being paid six figures is being taken advantage of there.

Tech workers stress the importance of the dog and pony show you have to put on when negotiating compensation with an employer, but they also bizarrely stress the importance of not organizing for more leverage and ceding the power of organization to the other side of the table.

comedyblissoption
Mar 15, 2006

Che Delilas posted:

Talking them out of it would involve fundamentally altering their perception of what programming is. The fact that they think they can measure it in terms of commits or lines of code (I'm assuming, but what the hell else would they be using TFS to measure?) indicates that they currently think it's like working on an assembly line. Maybe you can convince your boss that his viewpoint is utterly backwards, but I wouldn't put money on it. Worth trying, but not giving yourself an aneurysm over; if you can't quickly convince him to utterly scrap this idiocy I would get out post-haste, because the job will turn to poo poo as your accomplishments become unappreciated and the environment becomes competitive and backstabby.
you could maybe convince them with a pithy quote from bill gates

bill gates posted:

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

but they are likely so brain damaged that they'll use some other stupid metric in pursuit of whatever misguided goal they have

comedyblissoption
Mar 15, 2006

Pedestrian Xing posted:

I learned the metrics we will be judged on are points per sprint and hours per point. It wasn't explicitly stated but was strongly implied that bonuses/raises will be given based on these highly accurate measures. :sigh:
lol you are managed by incompetent morons

are points assigned by the workers themselves in your organization?

also lol @ trying to completely defeat points as an estimation tool

comedyblissoption
Mar 15, 2006

the morons who came up with this metric will view you with derision and contempt if you point out to them that workers will be incentivized to game the points in this new performance system making the points completely useless for estimation

this is the level of dumb that equates performance with lines of code per day

:sever:

comedyblissoption
Mar 15, 2006

moving an office farther and reducing WFH time might intentionally be a policy to shed staff

comedyblissoption
Mar 15, 2006

BaronVonVaderham posted:

Pretty much. It came up in another development thread, but I just read the book Bullshit Jobs: A Theory, and a full time scrum master falls perfectly into the author's category of "taskmaster" (a middle management position that only exists to manufacture and assign work to underlings but doesn't actually produce anything that helps get that work done).
in a system where workers must give up what they produce at the end of every day and have no ownership over what they have produced, you need an army of supervisors and taskmasters to keep them in line and productive

comedyblissoption
Mar 15, 2006

CPColin posted:

Haha good one haha the sprint ends on Friday and the release is on Monday haha when are you supposed to submit PR's? haha
this is why I think sprints are a stupid workflow process

comedyblissoption
Mar 15, 2006

The management sounds incompetent. They don't know how to do anything but crack a whip to make up for their own failures at scheduling and planning work and then punch down to scapegoat people when it doesn't work out.

It sounds insane to me that they could be surprised by what's in the demo in spite of you telling them what's in it which is implying they don't even plan to go through it with you before flying out there and that they don't have basic communication skills. Think about what you would do if you if the roles were reversed and how unreasonable they are.

Don't feel bad and don't ever do something stupid like taking the plane tickets out of your paycheck.

comedyblissoption
Mar 15, 2006

no one should be allowed to feel superior about their keyboard shortcut capabilities in an editor

unless that editor is vim or emacs of course :smugbird:

comedyblissoption
Mar 15, 2006

Unlimited vacation means that the employer does not have to pay an employee for unused time off if they are laid off or fired, especially in jurisdictions requiring them to pay for unused time off. It's a cost-cutting measure to gently caress over the employees dressed up in Orwellian language. As a bonus you encourage more brown-nosing and groveling toward managers!

https://hiring.monster.com/hr/hr-best-practices/workforce-management/employee-benefits-management/unlimited-vacation-policies.aspx

quote:

Can flexible vacation policies reduce costs?
In a traditional vacation policy, employees either accrue vacation time throughout the year, or start off the year with a bank of days. If employees leave the company before using their accrued time, they are typically paid for their unused time.

Companies with unlimited vacation policies don’t have to carry any liability on their books for unused time off. This has the potential to save companies $1,898 per employee, according to research from Project:Time Off.

I suspect unlimited vacation is a Uniquely American :911: phenomenon since the US federally requires a minimum of 0 days of paid holiday or vacation while civilized societies like austria require a minimum of 35 days.

comedyblissoption
Mar 15, 2006

actually it looks like it's 38 days in austria now lol

just for an idea of how insanely hosed the US is:
https://en.wikipedia.org/wiki/List_of_minimum_annual_leave_by_country

comedyblissoption
Mar 15, 2006

I was trying to google anything that revealed what the median worker gets in vacation days at an "Unlimited Vacation" workplace. This is the only thing I could find:
https://blog.namely.com/blog/what-data-reveals-about-unlimited-vacation

quote:

We took a look at all of the personal time off request data for 2016, and then segmented those requests by unlimited versus traditional plans. The results reinforced the concerns of unlimited vacation skeptics: employees with unlimited vacation plans take an average of only 13 days off per year, whereas traditional plan employees average 15 days annually.

The data proves that on average employees with unlimited PTO plans do in fact take less time off than employees with a set amount of vacation days.

Does any "Unlimited Vacation" workplace even advertise the median amount of vacation time their workers receive?

comedyblissoption
Mar 15, 2006

Mega Comrade posted:

Wait...you have none?! Is it not at least one of those, in practise all the states have their own and it works out ok?
HEH

http://www.bbc.com/capital/story/20141106-the-no-vacation-nation

quote:

Though many American companies gift their workers between five and 15 salaried days off per year, a recent study from the US-based Center for Economic and Policy Research found that nearly one in four private-sector workers doesn’t receive any paid vacation time.
...
An eye-opening survey released by careers website Glassdoor.com in April found that the average American employee who received paid time off last year had used only half of it.

https://www.cnbc.com/2018/07/05/heres-how-many-paid-vacation-days-the-typical-american-worker-gets-.html

quote:

Americans used to understand the importance of getting away from the office. From 1976 to 2000, the average working American took off more than 20 days a year. Starting in 2000, workers have been taking fewer days off. In 2015, American worked took an average of just 16 days off.

comedyblissoption
Mar 15, 2006

Pie Colony posted:

Points are a measurement of work/effort. Do you work when you fix bugs? Then you should track the amount of work you did.
The entire point of points is to help you estimate. If you start doing things that hurt your ability to estimate, then you're going to be worse at estimating.

Estimating points on bugs can also be very difficult when you don't even know what the cause of the bug is.

Estimating points on bugs can be helpful to help figure out timelines for stuff in the short-term, but you shouldn't use bug fixes as credit toward velocity.

Fixing bugs contributing toward increasing your velocity could maybe be justified if you estimated work by also estimating the number of bugs and effort you were going to generate out of every story you do, but I think that's just starting to over-complicate it. You can already build this into velocity by not getting extra points for fixing bugs.

comedyblissoption
Mar 15, 2006

BaronVonVaderham posted:



There was an argument in retro today: Devs have had nothing to do for almost a week because of an abrupt change of priority that invalidated our project and there was nothing written up about the new one we're supposed to shift to (wasn't supposed to happen for months). One dev brought this up in retro saying, "Well, we should just grab some of the infinite bugs in the backlog or that we've noticed on our own. Or start on stuff for next sprint and get ahead of the game."

There was major pushback because THE POINTS! THE POINTS WON'T BE ACCURATE! We won't "capture" that work that way!

What I heard: "But guys, you can't just do WORK without me facilitating it....otherwise why am I here?!"

Exactly :fuckoff:

It made my realize how top-heavy we are.....we have FIVE layers of management: Team Lead, Feature Teams Manager, Scrum Masters/BAs, Engineering Manager, Technology Department Manager (/CTO). We're a bit shorthanded on devs, we were outnumbered by people whose entire job is justifying its existence (and QA sides with them, since it makes their jobs easier).

It's just gotten to such a ridiculous point now.....we're literally blocking productivity for the sake of a process that is supposedly helping increase productivity? This is insane to me. Also, once again, arbitrary 2 week sprint deadlines being eliminated would take care of 90% of the problem here since we could just constantly move on to the next thing and keep moving. We're down to like 4 actual coding days in a 2 week sprint thanks to a growing "code freeze" period (QA demand).

I've just given up, though. Whatever, gently caress it, you want to pay me to read or go take a nap, that's your choice I guess.
I've personally had the displeasure of working under a milder version of this failure. If you finished working on stuff early in a sprint, you were encouraged to find a tiny (often low value) story you could squeeze into the sprint instead of getting started early on the next big thing. We'd miss deadlines working on stupid bullshit instead of high priority items because of this foolishness.

Sprints are a really stupid loving way to organize work, especially when you start getting insane management decisions hyper-focused on these X-week windows. I think it's a misguided management perception that you can get extra work out of workers with constant short-term deadlines. Work really should just be organized around taking poo poo off a priority queue.

comedyblissoption
Mar 15, 2006

hailthefish posted:

Regular blue-collar factory laborers fought and loving died for the 40 hour week and the 8 hour day.

And now it's p much dead lol :911:
Every day the productivity of workers has decreased since the 1930s though since the 40 hour work week was instituted by federal law. Economists were predicting that we should be at 80 hour work weeks by now to make up for the continued loss in technology, and only by the grace of our bosses has this calamity not transpired yet.

comedyblissoption
Mar 15, 2006

Code coverage as a metric can be objectively useful as a way to catch if someone accidentally forgot to test a branch or area of code. Annotate any code that shouldn't or can't be covered in tests for whatever reason and make sure you have 100% code coverage everywhere else.

Adbot
ADBOT LOVES YOU

comedyblissoption
Mar 15, 2006

necrobobsledder posted:

American business always seems to have standard practices border upon near-criminal and completely rear end in a top hat practices. I’m not particularly convinced that it’s efficient beyond what it looks like on paper.
Capitalism is a Paperclip Maximizer

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