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 »

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

Cicero posted:

But why does it sound half as complicated? Because to me, when I think something sounds half as complicated, that's because it feels like it'll take half as long. I guess to me "complexity of a task" and "how long it will take" are effectively the same thing.

Tossing around terms that we've probably all heard before from Brooks way back in the '80s, software has two kinds of complexity: inherent complexity and accidental complexity. We're pretty good at measuring the inherent complexity of things, but as software systems grow, so does the amount of accidental complexity. Features don't exist in isolation; they need to be integrated somewhere, which usually necessitates some kind of refactor or new abstraction in some unrelated part of the system. These cascade down the line. As the software system gets bigger and more complex, the time taken to add any particular feature will invariably get longer. One thing that story points accomplishes is decoupling the time estimate from a story at the beginning of a project from a similar story at the end of the project. If your velocity is falling even though your assessed complexity is staying the same, it shows whoever cares about these metrics that accidental complexity/technical debt in the system is beginning to hamper the team's throughput at delivering features, and time should be reallocated for refactoring or culling things that don't matter anymore.

# ? Apr 18, 2016 23:05

Adbot: ADBOT LOVES YOU

# ? May 9, 2024 23:16

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

HFX posted:

The problem is, that no one outside of a dev team ever wants to operate that way. They want everything done in number of hours with firm deadlines 3 months in advance.

There's no benefit to shoehorning a couple of Agile buzzwords into a waterfall development process to pull the wool over the dev team's eyes. If the business is going to insist on waterfall, they're going to get waterfall.

# ? Apr 18, 2016 23:15

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

Vulture Culture posted:

There's no benefit to shoehorning a couple of Agile buzzwords into a waterfall development process to pull the wool over the dev team's eyes. If the business is going to insist on waterfall, they're going to get waterfall.

The terrible thing about the hybrid processes is if somebody doesn't like what you're doing, they can try to shoot it down as either being too agile or too inagile. Set up some work to go through Agile? Wait a minute, we need to talk about this and plan it out first. Give them a plan? Wait a minute, this isn't Agile.

# ? Apr 18, 2016 23:26

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

smackfu posted:

I mean, the whole point is that if you add a specific amount of points to the two week sprint, you can evaluate how you did at the end. Didn't finish all those stories? Then do less points in the next sprint. Finished early? Add more points to the next sprint. It's pretty natural in its adjustment.

Yes, you can do the same exercise with hours, but once you start saying you can do 70 hours of work in 80 hours, you might as well call those 70 hours 70 points.

JawnV6 started to get to this, and it's something that's obvious but needs to be explicitly stated: it's equally important to actually review problematic estimates in your retrospectives. Was something much easier than you expected because some of the plumbing was done for some unrelated story some number of weeks ago? Was it much harder because the interaction flow for this feature was incompatible with the flow through the rest of the product and substantial portions had to be completely redesigned? These are qualitative lessons that the team should be learning, that should be part of the oral history of your team. Like Lean, Agile is beyond useless if you're not constantly learning. Moving the goalposts to make yourselves feel better about your estimates isn't learning.

# ? Apr 18, 2016 23:39

Jo: Jan 24, 2005; Soiled Meat

Vulture Culture posted:

JawnV6 started to get to this, and it's something that's obvious but needs to be explicitly stated: it's equally important to actually review problematic estimates in your retrospectives. Was something much easier than you expected because some of the plumbing was done for some unrelated story some number of weeks ago? Was it much harder because the interaction flow for this feature was incompatible with the flow through the rest of the product and substantial portions had to be completely redesigned? These are qualitative lessons that the team should be learning, that should be part of the oral history of your team. Like Lean, Agile is beyond useless if you're not constantly learning. Moving the goalposts to make yourselves feel better about your estimates isn't learning.

I very much agree that it's important to look back at estimates, but I also have to wonder if the variability in performance for single developers is high. I'd imagine the natural variance in a single person's performance contributes about as much as a bad estimate.

# ? Apr 19, 2016 00:59

JawnV6: Jul 4, 2004; So hot ...

baquerd posted:

I'm all on board with points, and the Fibonacci numbers have built in ranges and can convey uncertainty. I just object to people who can't handle it when someone points out that a 3 point story is typically e.g. 2-4 days worth of work, or that 1 point story should generally be completed within a day. It's helpful to baseline things in reality, and comparing stories to stories can be useful, but so can comparing stories to actual time.

Consider two stories, one has been sized at 3 points. The next story is being talked about, and everyone agrees it's substantially larger and sizes at 5 points. If you look at actual time anticipated, maybe 5 points at a week's worth of time minimum (for example) doesn't actually make sense because no one thinks it will take that long, and instead the earlier story should be re-sized down, or explored further.

Sure, if it comes up in the context of a planning meeting and leads to a productive discussion about the team's goals and internal metrics it's hard to disagree with your cooked example. But the real takeaway is that we should fire anyone who's under 6 points a sprint. I mean, if an IC is spending less than 50% of their time being productive,

# ? Apr 19, 2016 01:12

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

Jo posted:

I very much agree that it's important to look back at estimates, but I also have to wonder if the variability in performance for single developers is high. I'd imagine the natural variance in a single person's performance contributes about as much as a bad estimate.

Beyond real suspected competency problems, my take is that looking at velocity for an individual developer is a counterproductive disincentive. But you're of course right that people's individual productivity will wax and wane based on what's going in their lives, phases of the moon, butterflies in China, etc. Competent leaders should be clued into these things, but making predictions based on any human-based model is really, really hard. My general take is that small variations aren't worth obsessing over until they become data points along a trendline.

# ? Apr 19, 2016 01:42

cheese eats mouse: Jul 6, 2007; A real Portlander now

revmoo posted:

I'm sure we know people in the same circles, it's a pretty small industry. I've worked @ TLH/Ooh/Ind if you know what any of those places are. Currently work for an Infosec company out of state (thank GOD. A lot of the local companies are poo poo).

Ooh is becoming like UPS pretty much everyone has worked there. I interviewed but never hired. It was weird to me to not see any women in design or dev roles there. All the local agencies are crap. None of them pay at all and expect you to work 50-60 hours. Never touching it again.

# ? Apr 19, 2016 02:20

revmoo: May 25, 2006; #basta

cheese eats mouse posted:

Ooh is becoming like UPS pretty much everyone has worked there. I interviewed but never hired. It was weird to me to not see any women in design or dev roles there. All the local agencies are crap. None of them pay at all and expect you to work 50-60 hours. Never touching it again.

Its not a BAD place, just really segregated and cliqueish. I think that was when I realized that I am simply getting too old for some of the more childish elements in this industry. I hit my limit on a Friday and put my two weeks in on Monday morning. Didn't even have a job lined up.

And yes, all the agencies are pretty crap, just churn and burn, with both product and talent.

# ? Apr 19, 2016 02:25

ultrabay2000: Jan 1, 2010

I have a friend who worked at Ind but he jumped ship when they got bought out. It seemed pretty cool before then but I only know from his account. I applied to a few things around Louisville over the years but none of them ever panned out.

# ? Apr 21, 2016 16:27

revmoo: May 25, 2006; #basta

ultrabay2000 posted:

I have a friend who worked at Ind but he jumped ship when they got bought out. It seemed pretty cool before then but I only know from his account. I applied to a few things around Louisville over the years but none of them ever panned out.

I had a few friends who worked there (and at least one goon). One made it up until just a couple months ago before he had enough.

The company had potential but it was not managed well imo. They actually fired me because I told them emphatically I was done working weekends. lol.

E: Oh yeah, almost forget, they contested my unemployment claim and lost. Fuckers. I only used it for like a week it was really just the principle of the thing. Also I know of at least one Christmas they ruined for a previous employee's family due to their (imho again) EXTREMELY vindictive and litigious nature.

revmoo fucked around with this message at 17:36 on Apr 21, 2016

# ? Apr 21, 2016 17:33

B-Nasty: May 25, 2005

Is there any place to find semi-regional chats/forums for development? I'm thinking like a Glassdoor forums broken out by metro area. I feel like having the anonymity behind a computer might be really valuable to hear people bitching about lovely workplaces or bosses.

# ? Apr 22, 2016 00:47

Axiem: Oct 19, 2005; I want to leave my mind blank, but I'm terrified of what will happen if I do

B-Nasty posted:

Is there any place to find semi-regional chats/forums for development? I'm thinking like a Glassdoor forums broken out by metro area. I feel like having the anonymity behind a computer might be really valuable to hear people bitching about lovely workplaces or bosses.

St. Louis has a "tech industry" Slack, though it's not really anonymous.

# ? Apr 22, 2016 04:37

Drythe: Aug 26, 2012

Yesssssss

It finally happened guys

My bosses just made a new process for accepting applications. It starts with the users have to define and make a completely clear set of requirements at the start. Then three people need to sign off on these requirements. Then the project gets 'architechted' by my boss. Then we develop it and pass it to the user to test at the end and have them sign off on the testing. If the requirements change at any point we send them back to the beginning to do it all over again.

We call this magical new process "Agile"

# ? May 2, 2016 14:40

Infinotize: Sep 5, 2003

As long as you call it Agile and have lots of meetings it's working.

# ? May 2, 2016 15:31

Drythe: Aug 26, 2012

There's a meeting to discuss the idea of a new app, one for the requirements, one for agreement of the requirements, one for the design, one for assigning it to the developer, one for the implementation strategy, one for giving it to them to test, and I'm sure there's a few I forgot.

I asked what happens when users don't know what they want at the start and was told "we are working towards getting them there" :psyduck:

# ? May 2, 2016 15:40

Messyass: Dec 23, 2003

As long as your projects never take longer than two weeks you'll be fine.

# ? May 2, 2016 15:55

cheese eats mouse: Jul 6, 2007; A real Portlander now

Really tired of designing with no strategy or direction or clear user research. We are suppose to make a design based on a consensus of 3 designers on our team, have it developed and test it against the current one instead of testing several prototypes.

So I'm spending months making stuff that will probably never see the light of day due to business (and whatever design one guy likes best).

But yes we are Agile.

cheese eats mouse fucked around with this message at 15:27 on May 3, 2016

# ? May 3, 2016 15:25

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

Messyass posted:

As long as your projects never take longer than two weeks you'll be fine.

I'm pretty sure that's guaranteed given that model.

# ? May 3, 2016 15:40

FlapYoJacks: Feb 12, 2009

Awesome stuff I am architecting right now:

I am currently working on the new generation of products for my company, and they will all be running embedded Linux. I was able to convince management to let me take a extra two months to integrate a complete HAL layer into the Linux Kernel pertaining to our hardware that will work in conjunction with our future DTB files. This will allow us to have a single build among all of our new products going into the next generation, and it's going to be awesome.

# ? May 3, 2016 17:20

ChickenWing: Jul 22, 2010

Landed the consulting job. Oh god what are all these technologies how does this work aaaaaaaaaa why isn't this my rigidly organized 100% boring tech banking platform :psyboom:

# ? May 3, 2016 17:49

Khisanth Magus: Mar 31, 2011; Vae Victus

ChickenWing posted:

Landed the consulting job. Oh god what are all these technologies how does this work aaaaaaaaaa why isn't this my rigidly organized 100% boring tech banking platform

Hmph, some consultant you are, not being a god level developer on every modern technology?

# ? May 3, 2016 18:00

No Safe Word: Feb 26, 2005

ChickenWing posted:

Landed the consulting job. Oh god what are all these technologies how does this work aaaaaaaaaa why isn't this my rigidly organized 100% boring tech banking platform

Congrats, now you get to charge people while you learn how to fix their poo poo however you want.

# ? May 3, 2016 18:15

ChickenWing: Jul 22, 2010

Khisanth Magus posted:

Hmph, some consultant you are, not being a god level developer on every modern technology?

It's okay technically I'm not a "Consultant" yet, I'm whatever this company's entry-level "get a couple projects under your belt, *then* you get the real title" job is. I have lots of time to become fluent in every language and proficient with every bleeding-edge tech so that I can charge $10k a day to someone to stare ponderingly at their servers before telling them to install adobe reader.

# ? May 3, 2016 20:43

KoRMaK: Jul 31, 2012

Spent two hours today arguing with my boss in a loop about the stupid rear end way he is measuring metrics, and to stop doing the loving math of story points to hours.

He did do a senisble thing though and used our last sprints completed points and divided it up amongst developers amongst days, but god drat do I hate that math to.

# ? May 3, 2016 22:17

Hughlander: May 11, 2005

KoRMaK posted:

Spent two hours today arguing with my boss in a loop about the stupid rear end way he is measuring metrics, and to stop doing the loving math of story points to hours.

He did do a senisble thing though and used our last sprints completed points and divided it up amongst developers amongst days, but god drat do I hate that math to.

Just wait. He'all look at the story points in the backlog and muse, "If each developer just stayed two more hours a day for this sprint look at all the additional stories we can squeeze in!"

# ? May 4, 2016 05:53

necrobobsledder: Mar 21, 2005; Lay down your soul to the gods rock 'n roll; Nap Ghost

KoRMaK posted:

Spent two hours today arguing with my boss in a loop about the stupid rear end way he is measuring metrics, and to stop doing the loving math of story points to hours.

At my last job I tried to introduce Agile story points as a rough measure of anticipated effort, not hours, and because we're contractors and everything is about billable hours as a fundamental unit of output, I was pretty much forced into some arbitrary conversion of 1 story point = 2 hours. Because we were all constantly interrupted by other teams repeatedly even though there's a designated interrupt handler engineering work took far, far longer than normal teams of any competency level should do. So in the end I basically gave up on productivity, my metrics to the customer (that never actually read our reports that I spent at least $30k+ in effort to try to generate because of how terrible software integrations were) became 1. "we did N support tickets, they averaged this much time in our queue while we sat and waited for almost all of it" 2. "we completed 12 stories of maybe 3 points each in a month translating to a team of 6 FTEs accomplishes 300 total hours of work in a month roughly." The most chilling thing I found out was that when managers in the company compared project management notes, it turned out my team was among one of the most productive in the entire company of over 400k+ people - our duty cycle on tickets was averaging about 10% - each ticket spent 90% of its time in blocked status that is (waiting for approvals). There was 0 way any of us were going to get paid more for that level of performance either, of course.

Even if the metrics from Agile sprints are complete and utter poo poo the sliver of remaining value to managers may be more about comparing relative performance over time to justify good or bad feelings about certain projects and teams than about making release dates more predictable (it's all really fuzzy, they get that if they're not pantshitting retarded). After all, a lot of program / product management is about cherry-picking data and charts to support a political position. "Work" for managers in control of dollars is more about politics and emotions once the dollars get high enough, not actually about whether the data is accurate or even valid. Case in point - Donald Trump.

I really do have to emphasize that waterfall or maybe spiral is sometimes the Correct Way for lots of big organizations to do projects because the strengths and even goals of Agile are not what they want or are even capable of executing - you either deploy this stuff "correct" enough or your $50M+ project is cancelled because you couldn't make a good enough demo for an exec to be impressed. Agile cannot fix or refactor your bureaucracy that's choking yourself - it can only show or maybe somewhat enforce what you're doing with all the wasted human effort. There is no pivoting the world's largest aircraft carriers, you don't get a second sprint after the Titanic hits the iceberg, there is no "backup plan" when your company is dying, and you have a MVP framework for everything with a dependency graph that is a 500 node linked list or a digraph with lots of cycles and the vertexes are extremely unreliable humans with edges with time cost in the weeks - Gantt charts don't help you with that at all either (also because they're incomplete planning documents just like an Agile sprint plan). Developer productivity hardly matters when you have enough bureaucracy because developers are a fractional part of the full cost of the project in an enterprise software project now. It's just embarrassing to see massive bureaucracies try to address their bureaucracies by... adding more bureaucracy like structured Agile / SAFE. But I guess that's why the whole Agile software consulting industry is what it is.

Who remembers Six Sigma? Anyone remember the companies that have had success after they adopted it? It's because their stock performance almost always tanked after they announced adoption. Agile reminds me a whole heck of a lot about it in how it's sold like a silver bullet to enterprise companies that suck at software. Six Sigma may work to some degree for some companies that truly are choking under bureaucracy and are getting really bad output on existing lines of business, but most places have neither of those problems even in the Fortune 500. And after having worked at a place that does Six Sigma pretty drat religiously, I can't say that it was part of reducing bureaucracy to any degree itself despite all the emphasis upon self reflection. Hell, just go the Toyota approach with what Demings came up with nearly a hundred years ago and you'll do a lot better than the BS of Six Sigma - good tech companies with great growth and market presence have managed to stick with that at least. It's not like GE has been some hot poo poo company in the past 40 years, right?

# ? May 6, 2016 18:06

revmoo: May 25, 2006; #basta

You. I like you.

# ? May 6, 2016 19:16

baquerd: Jul 2, 2007; by FactsAreUseless

A company I worked for adopted a waterfall front-end process complete with quality gates, reviews, and approvals, with an agile development process complete with dedicated scrum masters and product owners. The entire system was overseen by ISO, SPICE, LEAN, and Six Sigma, all at the same time.

# ? May 6, 2016 20:40

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

Our company has a home-baked version of LEAN/Six Sigma that nobody really understands but that everyone at corporate has to stick to. I have no idea how it works and don't care to find out.

# ? May 7, 2016 00:38

Volguus: Mar 3, 2009

Pollyanna posted:

... I have no idea how it works and don't care to find out.

If you value your sanity, you would probably want to keep it that way.

# ? May 7, 2016 02:31

necrobobsledder: Mar 21, 2005; Lay down your soul to the gods rock 'n roll; Nap Ghost

I've cared enough about how these methodologies and processes work specifically to reverse and exploit them to actually get work done... and proceed to demonstrate how the processes never helped me do anything better or ever prevented actually legitimate problems besides manufactured problems. In fact, it's kind of necessary to do "devops" right - empathize with the paper pushers enough to understand and they may be able to give you some reprieve or shortcuts, and everyone can learn a little to improve stuff closest to the source of the problem (if anyone can remember the name of the famous, published military leader that wrote a bunch about how giving as much authority as possible to those closest problem is the most effective use of resources, I'll gift you plat. I've been going nuts for like half a year trying to remember him and Google and my search history is failing me). That approach is unfortunately one effective management tactic in a bureaucracy soaked work environment asides from making alliances and commitments that make Game of Thrones' plot about as simple as a Spot book.

Every time I try to crack one of those process, collaboration, and workflow optimization systems I stay somewhat sane by treating it all like it's a distributed system problem and everything starts to make sense more and you can spot the really useless fluff easier (and swiftly skip over them). The problems only really happen when you get process pedantic people that have never actually had to implement any of these things and want strict adherence to all these theoretical constructs (they're the business equivalent of useless academicians - you may be smart but you're completely wrong to even be here).

# ? May 7, 2016 02:45

Storysmith: Dec 31, 2006

necrobobsledder posted:

if anyone can remember the name of the famous, published military leader that wrote a bunch about how giving as much authority as possible to those closest problem is the most effective use of resources,

D. Michael Abrashoff?

# ? May 7, 2016 16:16

Doc Hawkins: Jun 15, 2010; Dashing? But I'm not even moving!

There's also David Marquet, the sub commander. He's got a book and a TED talk.

This is a bit embarrassing to admit, but I don't know of any organizational method/system/wtf-ever that addresses this issue more fully than Holacracy. The folks behind it are first-degree lolbertarians (source: I worked for them), it bills itself as all-or-nothing and fixes-everything, and is probably wrong in all its hyper-specific details, but it does try to give every cluster of workers the power to make a system that makes sense to them. I long for a more sane and incremental version of it.

# ? May 7, 2016 18:07

necrobobsledder: Mar 21, 2005; Lay down your soul to the gods rock 'n roll; Nap Ghost

Storysmith posted:

D. Michael Abrashoff?

Name doesn't sound familiar, same for Marquet. The guy I'm thinking of wasn't in charge of a ship as his prime example, although he may have been in the Navy. The person I'm thinking of had a career long before the recent Iraq war. I think I first heard of this guy from reading a bunch of HBR papers.

# ? May 7, 2016 19:43

baquerd: Jul 2, 2007; by FactsAreUseless

Why does it seem like the vast majority of remote work dev jobs are for Ruby?

# ? May 8, 2016 18:05

FamDav: Mar 29, 2008

Story points are awful. You are creating a silly proxy for time in the name of consistency, and when you do planning/estimation you end up throwing out everyone's opinions in favor of a single homogenized answer. Rather than attempting to measure uncertainty, you stick your head in the sand and pretend it's unmeasurable.

An alternative way I've done is have developers give a 5th, 50th, and 95th percentile guess for each task and assume your pdf is normal. Then use that data to randomly sample time estimates for your project. You end up capturing developer uncertainty in your model and can surface that to other groups to figure out things like features vs release date.

# ? May 8, 2016 19:10

necrobobsledder: Mar 21, 2005; Lay down your soul to the gods rock 'n roll; Nap Ghost

Yeah... that's probably more correct, but it requires more capability of mental processing than integer units (unless it comes to dollars, but even then very limited precision) so that's beyond the scope of most software development managers at scale.

baquerd posted:

Why does it seem like the vast majority of remote work dev jobs are for Ruby?

Complete guess: backend work needs a lot less back-and-forth interaction with product designers than frontend work as a really broad rule, and I've seen a lot of places opt for paying the obscene Bay Area / NY salaries for frontend folks when backend people are all over and in far greater supply so therefore probably easier to just pay less. I think Java dev is second for remote jobs behind Ruby which is a little surprising considering how insanely popular Java is, but I think this supports my point of company engineering priorities - most big companies want traditional job sites because they don't know how to manage remote workers well at all. For example, a former coworker quit because our company refused to increase our pay (rate to the client, really) unless we moved to one of our (Fortune 10) client's cities of operation - nobody in engineering has met our client face-to-face for 8 years and we have no building access to our client and therefore wouldn't be able to see our client-side colleagues normally either. The irony is that it would be a lower cost of living to move to one of them.

The Oldie programming thread is probably a better place to ask I'd imagine.

# ? May 8, 2016 20:18

CPColin: Sep 9, 2003; Big ol' smile.

The uncertainty factor is a good point to bring up against single point values. In the past, whenever my team had been estimating points and all agreed it could be anywhere between a couple hours of work and several weeks of cans of worms, we ended up using the high estimate and running the risk of way undercommitting. That was one of the main reasons we got our team switched to Kanban.

# ? May 8, 2016 20:19

Adbot: ADBOT LOVES YOU

# ? May 9, 2024 23:16

My Rhythmic Crotch: Jan 13, 2011

I have a question... I don't practice Agile with a capital 'A' so I have never used any of the project management tools or bug trackers out there that have Agile features baked in.

Is there anything out there that allows bunches of different estimates from different developers to be entered, then magics out a best guess for a real estimate? Or is that something that leads or managers are expected to do on their own?

# ? May 8, 2016 20:32

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

«‹›434 »