KoRMaK posted:

raminasi posted:

timelines four months in the future

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.

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.

Bruegels Fuckbooks posted:

I have about seven years worth of scrum experience. I think the problem is, ironically, "individuals and interactions over processes and tools" - if you are on a team consisting of relatively solid contributors and hands off management, your project is going to succeed regardless of the methodology you choose.

I believe that scrum proponents are actually inverting cause and effect - my suspicion is that rather than improving or hindering team success, scrum itself has nothing to do with the actual productivity and performance of the the team - scrum just fails so badly in situations with poor people/poor management that it acquits itself because everyone involved in the failure goes away thinking it wasn't implemented correctly, so people don't chalk up the failure as a "scrum" failure because people "weren't doing it correctly", so you end up with survivorship bias - the people who were on projects with good people who were using scrum attribute the success to scrum rather than being on projects with good people, and then go around evangelizing the virtues of scrum when they're really just saying "previously, I worked on projects with good management and good coworkers. You should try doing that everywhere."

My intuition is that process either doesn't matter, or if does matter, than there is probably a process more optimal for non-sunny day situations than scrum.

Bruegels Fuckbooks posted:

I think the problem is, ironically, "individuals and interactions over processes and tools" - if you are on a team consisting of relatively solid contributors and hands off management, your project is going to succeed regardless of the methodology you choose.

Bruegels Fuckbooks posted:

"previously, I worked on projects with good management and good coworkers. You should try doing that everywhere."

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.)

Keetron posted:

You are very correct, I tip my noise-cancelling headphones to you.

This thread is leading to a bunch of wisdoms, it is rather fun to read.

- if you are on a team consisting of relatively solid contributors and hands off management, your project is going to succeed regardless of the methodology you choose
- when working remote, act like you got an office job but without the travel.
- Doing things well is hard, not many people, teams or organisations are capable of this.
- Clueless people get in the way and cause damage

Pollyanna posted:

Is writing code to normalize an arbitrary float-like string

rt4 posted:

There's no right way to construct a wrong program

Skandranon posted:

The only winning move is not to play.

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.)

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:

How do you lot decide what levels you log information at? I'm standardizing our server logs and finding it fairly difficult to come up with even a vague standard for what goes in error/warn/info/debug/trace, especially clarifying boundaries for the latter three.

So far I've settled on:

ERROR: soft/hard workflow failures. Something that was supposed to happen did not.
WARN: recoverable problems and indicators that something is wrong with external flows/internal data validity
INFO: basic "server is doing a thing", endpoint logging, SQL query logging, job health checks, aggregate stats
DEBUG: specific "server is doing a thing", specific stats, reporting non-exceptional exceptions
TRACE: method entry/exit, data dumps


obviously there's no One True Logging Standard, different strategies are applicable for different log consumers, etc - just looking for some wider feedback than the two people that provided input in my office

Volguus posted:

If SQL query logging means for you what it means for me (logging every SQL query made by the application) then I would put that in DEBUG or TRACE not in INFO. But other than that ... yea, it looks reasonable enough.

Portland Sucks posted:

Would you actually write out every SQL query made by the application to a log file? I've also been trying to work out a logging scheme and questioning what is even worth keeping. Is there any point in logging all of my SQL queries if I'm going to be generating hundreds of thousands of them per day? At what point is that just noise.

Portland Sucks posted:

Would you actually write out every SQL query made by the application to a log file? I've also been trying to work out a logging scheme and questioning what is even worth keeping. Is there any point in logging all of my SQL queries if I'm going to be generating hundreds of thousands of them per day? At what point is that just noise.

Portland Sucks posted:

Would you actually write out every SQL query made by the application to a log file? I've also been trying to work out a logging scheme and questioning what is even worth keeping. Is there any point in logging all of my SQL queries if I'm going to be generating hundreds of thousands of them per day? At what point is that just noise.

Portland Sucks posted:

Would you actually write out every SQL query made by the application to a log file? I've also been trying to work out a logging scheme and questioning what is even worth keeping. Is there any point in logging all of my SQL queries if I'm going to be generating hundreds of thousands of them per day? At what point is that just noise.

CPColin posted:

We need to store a value that's eleven character long in a database column that's only ten characters wide. The same column is in a handful of tables, so it's time to make a bunch of ALTER TABLE statements! No problem, because we can select the tables we need and have the result set create the statements for us.

Well, remember when I mentioned that this place learned some hard lessons about databases and created stored procedures for a bunch of their table accesses? Yep, each of these tables has four stored procedures, one for each of the CRUD operations. And each of those has a parameter whose name matches this column we need to change. And they're all declared to be ten characters wide. So now we need an ALTER PROCEDURE statement for twenty-five procedures.

Can we learn this lesson about databases? I mean, what the hell is the point of a stored procedure that takes a bunch of parameters that exactly match the types of the actual columns and just passes them to an UPDATE statement (in a different order, for some reason)? I guess it does increment a version column and set a timestamp column, but a trigger could do that, too, right?