|
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?
|
# ¿ Dec 23, 2015 04:50 |
|
|
# ¿ Apr 27, 2024 15:30 |
|
Ithaqua posted:Kanban isn't a project management methodology. It's an apples-to-tractors comparison.
|
# ¿ Dec 23, 2015 05:38 |
|
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. 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.
|
# ¿ Feb 3, 2016 04:03 |
|
smackfu posted:What's so hard about SVN and branching for every story? Not as lightweight as git but seems workable. 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...
|
# ¿ Jul 24, 2016 20:02 |
|
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 |
# ¿ Jul 26, 2016 13:45 |
|
if theyre savvy/lucky they'll get promoted or receive a windfall before the consequences of their decisions can be realized
|
# ¿ Jul 27, 2016 04:38 |
|
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
|
# ¿ Sep 17, 2016 03:30 |
|
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? 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.
|
# ¿ Nov 1, 2016 23:00 |
|
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
|
# ¿ Apr 15, 2017 12:57 |
|
this is a superior way to develop even if you're literally just a 1-man dev team
|
# ¿ Apr 15, 2017 13:08 |
|
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.
|
# ¿ Oct 11, 2017 10:10 |
|
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.
|
# ¿ Dec 5, 2017 22:24 |
|
ratbert90 posted:Yeahhhhhh that interview. I'm asking b/c getting someone to reveal this information would help me out whenever I interview.
|
# ¿ Feb 7, 2018 15:28 |
|
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.
|
# ¿ Feb 19, 2018 05:22 |
|
baquerd posted:Because they can get bigger yachts that way. 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? comedyblissoption fucked around with this message at 02:19 on Feb 20, 2018 |
# ¿ Feb 20, 2018 02:05 |
|
KoRMaK posted:Elaborate. Assume I know as much as an 11 year old please. 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
|
# ¿ Feb 20, 2018 02:58 |
|
baquerd posted:Sounds like Holacracy, which fails horribly at scale: http://nslsfacts.org/2017/09/26/lost-utopia-why-did-holacracy-fail/ the world's largest worker-coop has scaled to 74k employees and has been around for over 60 years
|
# ¿ Feb 20, 2018 03:17 |
|
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? https://www.youtube.com/watch?v=87395oUPDR0 baquerd posted:That company does almost entirely labor and other physical goods and services. Not software. 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.
|
# ¿ Feb 20, 2018 03:35 |
|
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.
|
# ¿ Feb 20, 2018 04:14 |
|
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? comedyblissoption fucked around with this message at 04:38 on Feb 20, 2018 |
# ¿ Feb 20, 2018 04:36 |
|
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.
|
# ¿ Feb 20, 2018 04:43 |
|
I never said it was easy. Also, banks lend money to worker coops in a similar manner like traditional businesses.
|
# ¿ Feb 20, 2018 05:18 |
|
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.
|
# ¿ Feb 21, 2018 01:19 |
|
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. 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
|
# ¿ Mar 6, 2018 11:15 |
|
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. are points assigned by the workers themselves in your organization? also lol @ trying to completely defeat points as an estimation tool
|
# ¿ Mar 22, 2018 23:41 |
|
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
|
# ¿ Mar 22, 2018 23:43 |
|
moving an office farther and reducing WFH time might intentionally be a policy to shed staff
|
# ¿ May 8, 2018 21:42 |
|
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).
|
# ¿ Jun 13, 2018 21:29 |
|
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
|
# ¿ Aug 4, 2018 09:40 |
|
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.
|
# ¿ Aug 6, 2018 06:36 |
|
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
|
# ¿ Aug 9, 2018 16:59 |
|
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? I suspect unlimited vacation is a Uniquely American 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.
|
# ¿ Aug 10, 2018 08:39 |
|
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
|
# ¿ Aug 10, 2018 08:54 |
|
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. Does any "Unlimited Vacation" workplace even advertise the median amount of vacation time their workers receive?
|
# ¿ Aug 10, 2018 12:16 |
|
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? 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. 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.
|
# ¿ Aug 10, 2018 12:23 |
|
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. 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.
|
# ¿ Aug 30, 2018 21:06 |
|
BaronVonVaderham posted:
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.
|
# ¿ Aug 30, 2018 21:13 |
|
hailthefish posted:Regular blue-collar factory laborers fought and loving died for the 40 hour week and the 8 hour day.
|
# ¿ Sep 26, 2018 14:30 |
|
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.
|
# ¿ Nov 13, 2018 21:18 |
|
|
# ¿ Apr 27, 2024 15:30 |
|
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.
|
# ¿ Nov 30, 2018 04:15 |