Ithaqua posted:

Kanban isn't a project management methodology. It's an apples-to-tractors comparison.

ratbert90 posted:

What is wrong with gant charts and a simple research -> implementation setup?

Why do companies think they need to reinvent everything?

Pollyanna posted:

I'm a little worried about my current workplace's project methodology.

We had a...spring planning-like-thing today for deciding what to do about our new project that spun out of an existing one. Here's a few things I heard and learned in the ~2hrs of meeting time:

• I heard the phrase "I'm thinking 4-5 versions out" more than once.
  
  
• No one could agree on what the MVP was, or even understood that an MVP is meant to be minimal. The original attempt at it was easily an 8-12 month job.
  
  
• We've planned out the entire UI before writing any code, speaking with our users, or even starting our first sprint.
  
  
• The entire wireframe for the app was drawn up last Friday by a designer we borrowed from another team. For the fully-featured, detailed and bedazzled with extra features version of the app. By the end of the meeting, we decided to ditch all but two of the wireframes. The designer was not happy.
  
  
• That doesn't mean we're not going to use the wireframes, no sirree. The wireframes are still gonna be forwarded to the UI/UX team 3 hours away, which isn't the same team as the UI/UX team where I work and their role in the project is ??????????????, and once a month the team will sit some users down and demo them the wireframes, and get some feedback, which they pass back to us eventually. Tight iteration loop, this ain't.
  
  
• Endless bikeshedding and arguing over the fields on a data model we don't even know is valid yet.
  
  
• Awful communication issues and Waterfall out the wazoo.
  
  
• Terrible scoping for features that we came up with ourselves, with no input or requests from the users.
  
  
• In the database we're factoring out into a separate API (maybe, none of us are clear on if we will or not), the default Postgres primary keys were disabled for the people table and replaced with strings. These strings represent ID numbers for real world people. Real world people change these numbers often. People can have more than one of these ID numbers. The call for finding a person by ID looks like this:
  
  

  code:

  person = Person.find('AA######')
  

  
  
  

I was told by another engineer a few days back that part of the reason I was brought on was to help drive the team closer to agile and to improve our process. I genuinely don't know if I can do this all myself. I'm still learning the basics of agile and even though I'm reading as fast as I can about creating user stories and making tight iteration loops, I still am not the Expert Team Fixer they clearly need.

I'm torn between scrambling to save this project, or just sitting back and letting it go off the rails, distancing myself from worry. I feel too bad doing the latter, but I don't know if I can take on the responsibility of the former.

dividertabs posted:

I can't convince my team to loosen the PMD rules that enforce Javadoc. So 95% of our public methods look like:

code:

/**
 * get the user name.
 * @param accountId the account ID
 * @return the user name
 */
public String getUserName(final String accountId)

IAmKale posted:

Do you guys have any suggestions for finding recruiters who might help with an upcoming job search? I want to get into Python/Django development but I'm not all that eager to enter my resume a dozen different ways for just as many application systems. I'm hoping that getting a real human involved this time around will help streamline the search process.

Edit: Oh hey, apparently Cybercoders is a lovely company, go me

KoRMaK posted:

Serious question - when does it matter? When is NoSQL better over SQL?

Cuntpunch posted:

It's funny you should mention branching!

We have *constant* issues with merge issues while working in a single branch. We're on TFS, and the team doesn't compulsively Get Latest and then *review* the diff before checking in. So especially when two different devs have added files, we just have stuff randomly get dropped from the project, etc.

Dude's solution? Clearly every single dev should create a brand new branch every single sprint for every single slice of every single story they're working on! More branches, less problems!

My Rhythmic Crotch posted:

Medical software by any chance?

Pollyanna posted:

I've learned that it is actually possible to be completely paralyzed by regression testing and thoroughness. I have at least three PRs that have been up for over a month now that haven't budged because one or my co-workers insists on writing regression tests for every single possible result, i.e. "happy" and "sad" paths, such that it's taken about 10 times longer to deploy a feature than it should. I have no issue with regression tests, and in fact I'm trying to port the regression team's tests to Capybara so us developers can write our own tests, but it's gone way off the testing deep end without really accomplishing anything. She's seriously slowed down development due to overthinking everything and has been rather difficult to work with recently (which might be due to the fact that she's manually pulling the branch for each PR and running the manual clicky-clicky regression test on each one). The weirdest part is that she's very reluctant to let me look into establishing Capybara tests for our app so that we devs can write and run feature specs ourselves, instead preferring that we continue to write manual tests and click through everything on any PR we make, even for one-liners.

I genuinely don't know what to do with her, but I'm getting frustrated enough that I'm just taking on tech debt tickets to alleviate her need to manually regression test everything solely because I'm sick of her holding everything up. I recognize the need to ensure correctness of your app, but there's a loving limit to it and automation relieves a buttload of issues yet is still being resisted by her. Driving technical change is balls.

Docjowles posted:

I see you've met my coworker, who views the world in two buckets:

1) things he wrote himself, which are cool and good

2) all other code, which is worthless garbage written by idiots for idiots and you should be fired for using it because it's awful

Pollyanna posted:

That is the broken down version. What I end up doing is looking at the parent story and writing down the requirements/my own breakdown in the ticket before I work on it, just so people aren't like "BUT I EXPECTED THIS" because I constantly run into that problem and am extremely sick of it.

I have a question. When is it appropriate to use a Scrum-like approach, and when is it more appropriate to use a Kanban-like approach? I've found that for projects that aren't super heavily structured and are kind of pick-things-up-and-work-on-them like ours, Kanban works way better than Scrum because nobody really knows how much is gonna be worked on and when things will be done. vv (But we still do Scrum because management is absolutely terrified of not having numbers and estimates and things to judge worth, value, and performance with.)

smackfu posted:

How do you deal with people being late to standup?

Steve French posted:

How the gently caress is that an entire job?

Colonel J posted:

I've been working in development for a few months now (love it) but I noticed that programmers, at least the ones I interact with, tend to use phrasing like "oh yeah, I'm a dumbass" and various other self-insults a lot. I think it's pretty annoying as these people are clearly not stupid, and it's just self-defeating for nothing, pessimism and focusing on the negative. I hate it. Anybody else see this trend/feel this way? Should i just chill out and it's just a turn of phrase, or a window into a problematic part of working in dev?

revmoo posted:

The Linux kernel needs like 8 minutes on decent hardware. 37 minutes is either a neural algorithm designed for HFT, modeling the human genome, or poo poo loving code.

redleader posted:

In scrum, everyone on the team is known as a 'developer'. Is this because:

1. Scrum was created for software development, and therefore teams are composed almost entirely of software developers?
   
2. Everyone on a scrum team is so cross-functional that everyone is equally useful as a software developer, no matter what their original skillset was?
   
3. Team members are 'product developers', not software devs as such, and develop a product as opposed to software? Therefore it's still correct to call them developers, regardless of their actual job (design, test, dba, etc)?
   

I'd always assumed it was the cross-functional bit, but someone sent a scrum master on a course and now he's bringing up questions.

baquerd posted:

At a previous position, I just told my manager we'd get him whatever numbers he needed. I then created a class with 10k loc and 100% coverage that did nothing and wasn't connected to anything. His bosses loved the code coverage numbers our team consistently delivered.

Carbon dioxide posted:

How do you deal with CHAOTIC programmers?

I had to work with this guy for a while. He's very knowledgable about a lot of the more complex programming principles, frameworks, all that. And overall he's not a bad programmer either, quite experienced.

But he's always running around dealing with 5 different tasks at once, like I ask him a question, he's halfway through explaining it, someone walks by and he just drops the explanation and runs after that other person because he has something to discuss with them.

Or he comes up with a good idea, I get assigned to actually code it, and just when I'm about done he decides the implementation should be entirely different and I can start over.

Or he's in a hurry, we need to make a bugfix release, he's got a solution, but puts the line on the wrong side of an if or for bracket, making the situation even worse.

I'm a very ordered person and others have told me I'll just need to learn to deal with people like that but it annoys me SO MUCH.

Volguus posted:

There are ways:

Nested if/else to hell and back
Return checks that will free whatever has been initialized until then (and pray you don't forget something)

Or you can choose to keep your sanity, don't adopt blanket rules (such as never use goto) , and just use the thing and not behave like a child.

Keetron posted:

On linkedin I changed my title to "Software Engineer in Test", I think it will save everyone a lot of time and frustration during the interview process.

CPColin posted:

Well that's what I get for turning off that feature because I didn't like the spacing, I guess! Still would rather see the "unused code" warnings show up without having to fart around with the Code Analysis settings.

Edit: poo poo, that's ugly. And it fades in? Turning it back off.

Messyass posted:

If she's talking about the LINQ query syntax I kinda agree. That stuff is nasty. The method syntax is much nicer.

Also, there's no reason that deploying a new version of the code should be harder than changing the database, but you probably know that already.

Sagacity posted:

Are you serious? How do you deploy and version control this clown car of a development strategy? How do you even pass arguments and receive results in your code if you have to assume the database code can change at any time?

I mean, I'm all for DBAs being able to write decent queries but this seems...unideal.

Carbon dioxide posted:

I'm currently in my second job as a developer, and at both companies, Scrum was implemented as intended instead of half-assed and we didn't take it too strictly, as in we diverted from the guide when we discussed that doing so would help us out. The management left us alone to run it as we saw fit and/or actively took part in discussions about how to make Scrum work even better.

In both places, Scrum as a method works. We got poo poo done in a much more efficient way than would otherwise have been the case.

So, reading this thread, I can come to a couple conclusions:
- Scrum works perfectly fine for development teams when implemented as intended and when the specific implementation is decided and then supported by the whole team.
- Scrum is an active impediment when implemented incorrectly.
- Most people posting here work for the wrong companies.

I probably wouldn't hire anyone who'd dismiss Scrum out of hand. It either means they're shaded beyond repair by companies who got it wrong, or they are just unable to work in a team. On the other hand, having strong reservations about it is fine, especially if it leads team members to take the initiative to improve the way of working.

Doom Mathematic posted:

This drills down into the core question: does there exist a methodology by which mediocre developers can produce good software? (Defining "good software" is left as an exercise for the reader.)

ChickenWing posted:

I feel like your av is extremely relevant

quote:

1st Bob: So you physically take the specs from the customer?
Tom: Well... No. My secretary does that... or they're faxed.
2nd Bob: So then you must physically bring them to the software people?
Tom: Well... No. ah sometimes.
1st Bob: What would you say you do here?
Tom: Look I already told you, I deal with the @#$% customers so the engineers don't have to. I have people skills! I am good at dealing with people, can't you understand that? WHAT THE HELL IS WRONG WITH YOU PEOPLE?!

Doom Mathematic posted:

It shouldn't be necessary to understand the entire codebase in order to fix any single bug.

Ither posted:

When a fixing a bug, when do you band aid and when do you burn everything down and start from scratch?


Asking for a friend.

Votlook posted:

I work at a small company with a few other devs, the CEO just informed us that the CTO (my direct manager) will be devoting all his time on completely rewriting our core product completely on his own, and no longer manage the dev team.

I should start sending out resumes, right?

Rubellavator posted:

Reminds me of trying to convince some developers on the other-side of the house to use E2E tests. Talking about, set up database with empty schema, insert some data, run a test. They kept trying to make the point that the application HAD to be tested with production data, because real world data blah blah blah. I kept trying to tell them that they as they found more bugs from their real world data, they could add test cases to cover them. Nope, I just didn't understand how wacky and crazy their data could be, there was no point in even trying cause you're bound to miss something! To be fair, I don't even know what their application did besides handle large amounts of questionable data as part of some kind of pipeline process.

Pedestrian Xing posted:

After keeping my projects independent and "off the board" for a year I finally had to start using scrum/TFS and it is the biggest waste of time. Takes more time to write stupid loving first person task descriptions than it does to do half of them. Also love 4+ hour weekly meetings and 40 minute standups every day.

KoRMaK posted:

Fundamentally, I don't know how you can't see that the current things that companies chase lead to exploitation of their workforce and that unions help the workforce push back against that exploitation.

Pedestrian Xing posted:

I learned today that apparently management wants to start using TFS to compare our performances against one another. How big of a red flag is this?

Ape Fist posted:

Senior management is fully aware of the absolute dogshit that offshoring has brought about. We're months behind on a major project for a Government client and it's largely in part due to our Indian office literally sitting on their hands and doing loving nothing. I have 3 outstanding issues in my user-stories right now that require back-end fixes for bugs I was assigned like 2 weeks ago. I had to go to my project Manager on Friday and sit down with him and explain why poo poo has been sitting in my VSTS list for loving ages and it looks like I'm not loving doing anything. This is only going to get loving worse.

ChickenWing posted:

Shirec posted:

Blood, sweat, and tears, we got 1.0 ready to go, rickety and buggy, by mid December. Boss presents it to CEO, CEO says he wants the ability to pause this and that, do some other things that make multi tenant completely infeasible. So we have to re-do all of it. We get a week and a half of blissful vacation and come back to this news.

Shirec posted:

No, we’re a messaging platform. We take uploaded information from whatever health care facility and perform some sort of messaging action with it. Payment reminders, surveys, reminding people to get their H1C1 levels checked, etc etc.

Keetron posted:

When I invent a time machine, I will first go and kill the grandparents of the guy who invented SAFe and only after I will go after the guy who killed Hitler.

Munkeymon posted:

It sounds like the 'magic error translator' is actually i18n which is a valid use case for magic number translations on the front-end. Or course, you can send a magic number and an error message in the team's common language just as easily most of the time.

Che Delilas posted:

Welp, big ol' priority shift with a laughably short deadline for the requirements that we heard about late last week (with no input from the devs before the deadline got set, naturally) got shortened again by 25% today (yeah that's indeed about 2 business days between those two events). Meanwhile, interrupted with "hey can you look at this bug" all day.

Deadlines are lawn dart thrown with a blindfold on at best, and that's when devs have input on the amount of work before they're decided. These guys are dreaming, and no we aren't going to be putting in unpaid overtime for any of this poo poo. This is years and years of picking the cheapest dirtiest hacks every single goddamn time and never letting us pay off any of that debt. Well it's come due now motherfuckers and the interest is going to make you cry and I'm going to sit here laughing at you while you do.

I had hope earlier this year. They made some hires that made me think they were willing to change direction, and those new hires have been trying, but like clockwork, as soon as the pressure is on they go back to the only method they really understand: pressure us for the cheap and dirty hacks and start lecturing about the "realities of business" when we try and push back. My favorite reason, the reason they go to most by far, is "But it's <whatever customer is shrieking loudest at this moment>. We HAVE to!"

I need to find a place to work where they don't do this 100% of the time. 80% of the time would be fine, seriously. I don't expect management to fully grasp what technical debt does or why it matters that we spend time coming up with a good (note: not necessarily perfect) solution. I just want them to trust me when I tell them that we REALLY NEED some maintenance programming or that we REALLY NEED to not go with the first bullshit hack the junior devs come up with, and then back me up when I make that decision. I'm not going to do it all the time and I'm not going to randomly refactor something on a whim just because I learned a cool new programming thing.



Sorry for the rant. I like a lot of the things about my job and I don't want to leave for those reasons. But this poo poo is starting to eclipse it all.