ChickenWing posted:

eclipse is actually useable now!

ratbert90 posted:

But hey, at least I have put everybody on MS Project. We tried a bunch of other programs (both web based and desktop based) and Project with Project server is the only one that works for everybody.

Before that they had no project management at all!

comedyblissoption posted:

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?

Cuntpunch posted:

Here's a general question that's somewhat an inversion of my previous statement:

How *do* you make Agile work when there are drastic skill discrepancies amongst the development team? It seems like that's the other thing somewhat inherent to development is that you will have strong talent on one end of the team's spectrum, and dead weight on the other - whether it's for "coast until retirement" career folks or just "if it isn't something I learned in school then it will take me 9 hours to do basic things" or any of the other usual bad-dev tropes.

My experiences repeatedly is that you either end up in a situation where the better devs turn into tacit janitors - let the bad devs write horrendous code, come in as mentors/reviewers/whatever and clean it up. Or you end up with the better devs just getting the work done super quick and the bad devs sit on their hands 40 hours a week feeling left out.

I mean obviously "only hire talented people" is a great answer, but that's not realistic at all, so what's the real-world solution?

Axiem posted:

In the groups I've been in, we've always read that as "given an option between just turning around and talking to each other vs. establishing a formal process for something, pick just talking to each other". For example, if someone needed to do something that meant no one else should push for thirty minutes, instead of building up some process of notifying people through a tool and things like that, just loving turn around and say "Hey, no one push for thirty minutes, okay?" and everyone says "Cool" and turns back around and gets back to work.

If you read that as "more meetings" or "more tools", then you're doing agile wrong.

Cuntpunch posted:

I've met way too many people with Masters of Comp Sci. on their resume who will shout all day about 'Separation of Concerns!', 'Dependency Injection!', and the like, but then ask them to *implement* anything and it turns into a muddled mess because they spent more time memorizing abstract flowcharts describing good patterns, rather than learning the HOW to implement them and WHY to use them in practical terms. "You must unit test!" they cry - then write a unit test where they mock the method-under-test to return string.Empty, then assert that it returns string.Empty - at which point they pat themselves on the back about 'Good code coverage.'

Finster Dexter posted:

They asked me what the Big O was of the LINQ OrderBy method. I guessed polynomial time. I was wrong. It was logarithmic. But they didn't seem to care and I don't care either.

piratepilates posted:

My current workplace uses a time tracking thing, but I only work on one project so I just put 8 hours in to the project each day, very easy.

My last workplace though had a time tracking thing (two actually, for some dumb reason) and had you working on multiple things, and wanted you to make sure to log time in the projects each day. There was also never quite enough work to do for the whole day. What everyone ended up doing was just inflating the time they worked on things or finding projects with lots of slack to just throw time in. No one seemed to care or check that the time made that much sense. Just keep making the time work even if it's not fully accurate and don't worry until someone makes you worry about it.

baquerd posted:

Just want to point out that Agilefall is a really awkward system because it doesn't roll off the tongue. If you switch to Scrummerfall, things go much more smoothly.

Pollyanna posted:

so we just plan the sum total of the tickets' hours to be (2 weeks/sprint * 40 hrs/week * 2 people per ticket) = 160hrs.

CPColin posted:

I hadn't heard of it before now, but I know one of the main reasons my team switched from Scrum to Kanban was because we all (mostly me) complained so much during sprint planning that certain issues were impossible to estimate. We always had stuff like "figure out how we can use technology X" and "tear down this architecture we've been using for years and build a new one." My answer was always, "I won't know until I get in there."

We finally started doing stuff like agreeing to spent X hours/days on initial investigation and filing follow-ups, as necessary. The better fix was to use Kanban, where the most important stuff is always at the top and we can abort out of it if everything starts to snowball.

Axiem posted:

On my previous team, we had a weekly estimating meeting on new stories in our pipeline. To do the actual estimating, we'd all read the card, then raise our hand (or otherwise indicate) when we'd made an internal estimate. We'd then go around in a circle and say our own estimates.

I think the highest ended up being what we put on the card, but that never really mattered to us. It was more about seeing "are we all on the same page regarding the scope of this story?" If one person said 8 hours and another said 40, we'd go "whoa, why so high/low?" It often led to good conversations about what actually needed to get done with a little bit of how, and meant everyone knew something about each story, so they wouldn't go too far off the beaten path if they ended up pulling it.

I liked it well enough, though I thought it was stupid to use hours and we should have done a sizing system (< day, 1-3 days, 1 week, longer, or something like that).

In terms of actually using estimates for planning or communicating with management, I thought they were worthless, and I don't think we should have been sharing those estimates outside of that room, because they just lead to unrealistic expectations.

CPColin posted:

So a pile of people were laid off yesterday and one of them was celebrating her birthday. Good planning, management.

CPColin posted:

This is not the first time it's happened!

pigdog posted:

There are tons of companies doing Scrum wrong or half-assedly. Why pay anyone money when you can read Wikipedia yourself?

386-SX 25Mhz VGA posted:

I've been on three different teams now "making the transition to Agile," and every one was a poo poo show. I'm curious to know whether anybody has witnessed "a transition to Agile" being accomplished successfully.

Khisanth Magus posted:

Apparently the leads of our development teams at my current employer had a meeting the other day and they decided to have a vote on whether any source control other than vanilla TFS was going to be allowed to be used by the teams. The vote was "TFS FOREVER!" I hate TFS. I've used multiple source controls at previous employers, and TFS is inferior to them in so many ways.

Cuntpunch posted:

TFS is a 'scary' thing to move away from when you have a pile of developers who have spent most of their careers on TFS(which tends to be combined in a .NET shop, so tight IDE integration + GUI) and try to put them on not just a jump to DVCS(which itself already requires a bit of re-education) and ALSO lose a lot of that integration. I'm hoping Visual Studio trying to tighting up Git integration will end up making this an easier sell to Management. Right now it's "We are going to have to send the entire development team to a multi-day class to learn this new tool, and we have to migrate projects with years of commit history over to a new repo, and....that's around the point where risk outweighs reward in management's eyes.

Munkeymon posted:

The places I've been the guideline was always roughly 1pt/hour, probably max out to 6-8 for a very productive day with no meetings

My Rhythmic Crotch posted:

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?

Vulture Culture posted:

The problem with using Slack for anything important is that chat is even easier than email to declare bankruptcy on.

Dr. Stab posted:

Did they not know that you can have multiple channels?

Gounads posted:

I honestly don't know what a full time DBA does.

Dirty Frank posted:

Code review at my place has almost no common characteristic with meetings. There's no group discussing things, its one senior developer (which ever one got assigned to that changeset*) handing down judgment on a changeset. Whats it like everywhere else?

*Sorry for the TFS centric vocab

CPColin posted:

Like how I finally snapped after the whatever-th consecutive annual review where the assessment was, "You're a great developer, but you're going to need to improve, if you want to be promoted to Architect."

Pollyanna posted:

I feel a little bad saying that I'm neutral on him staying or not - he doesn't really bother me even if he sucks at his job.

ChickenWing posted:

Depends on the supervisor. If you have an old-school-work-ethic sort of supervisor ("if I'm not actually dying, I'm coming in to work because that's the right thing to do!") then you probably just have to resign yourself to suffering. If you have a reasonable, normal supervisor, then just talk to them and explain the situation. In most non-retail, non-food-service jobs I've experienced, people tend to be understanding and okay with it if you're not doing too hot, especially if you're in visible distress and aren't just calling in because you have the sniffles.

ChickenWing posted:

Bragpost: by the end of today, I will have completed 7 story points (which are estimated at about 1 story point per dev day) in the space of two afternoons.

I wonder if my tech lead will be okay with me taking a couple vacation days for an impromptu long weekend.

ChickenWing posted:

Yeah we tend to estimate worst-case, plus we're still honing down from what we used to have, which was fairly ludicrous. It's been better since we've started on a lowest-bidder story point system rather than consensus-based

ChickenWing posted:

Gounads posted:

That doesn't describe any methodology I've heard of, but any system where someone commits to doing work that they themselves estimated is better than most systems in the past.

Rocko Bonaparte posted:

I end up having to use reflection when doing something with plugins. It looks like the right thing to do then. Is there a better general approach?

Volguus posted:

OSGI is massive and it itself is using reflection too, although is very capable. Use it if you need its features.
At the end of the day, for plugins you pretty much are forced to use reflection either via a library or custom code. Most likely .NET uses reflection too. Since java 1.6 one can use ServiceLoader for simple plugin support and maybe in Java 9 with the new module system there will be easier ways. But, dynamically loading a class at runtime, instantiating an object and calling methods from it, that most definitely is using reflection of some kind.

PT6A posted:

Yeah, there are certain things I'd write tests for after the fact, but doing it to hit an arbitrary level of code coverage is not good. Coverage can be a useful tool, but only so you can see what's not covered and judge if it's something that actually should be covered (in which case there will be a reason for writing that test, and the test can be designed with a motivation other than "hit the target amount of code coverage").

My Rhythmic Crotch posted:

I hesitate to post this, because I actually like working here. But my boss is just ... so weird. He's amazing at SQL tuning and linux hacking, but he hates any kind of structure or organization. This has led to all kinds of interesting situations.
...
instead of having a column for first_name and a column for last_name, he just has one column called "name" and you store "Jane:Doe" in it. How do you get data out you may ask?

code:

select unnest(string_to_array(butts::text,',')) from (
    select unnest(string_to_array('A,1:B,2:C,3'::text,':')) as butts
) as doody;

This example is simple compared to some of our queries, which have unnest(string_to_array()) nested 4 layers deep, plus more joins, cases, etc, than you've ever wanted to see.

- Fun side effect of replication is that it really hurts insert performance. Especially in our case, since we are replicating across large distances with really bad latencies.

rt4 posted:

What's the deal with microservices? Sounds like a good way to end up with an incoherent, fragmented codebase

smackfu posted:

Do you point bugs or not? We have not but our new product owner wants to because they can't get a sense of what will actually be delivered if people work on bugs and that delays stories.

Sagacity posted:

But if you have zero-point bugs and your velocity goes down because of that, isn't that then a valid metric as well? I mean, it shows you're spending more and more time fixing bugs than actually working on stories, which seems like a very useful indication that somewhere in the development process (not necessarily development) something is not going as planned.

You shouldn't be chastised for the drop in velocity obviously, that makes little sense.

Pollyanna posted:

I've been denied short term disability for a total of seven work days for recovery from a medically necessary surgery. Companies can be really poo poo about this sort of thing.