|
OMG, when agile meets an entrenched DBA group, so painful. "Ok, you want some columns added to a table. That's pretty simple. Let's have a meeting to discuss the purpose of the columns. Then we will add them to the logical data model once you provide descriptive names for each. Then the other DBAs will translate that to a physical data model and then they will provide the SQL and you can submit a request to get it implemented. You do have funding, of course?" That process has been going on for almost a month now. And this is blocking a ton of stories of course, that are only waiting on final column names.
|
#
?
Jun 1, 2016 23:56
|
|
|
|
| # ? May 10, 2024 10:36 |
|
|
smackfu posted:OMG, when agile meets an entrenched DBA group, so painful. I viscerally know that pain 
|
|
#
?
Jun 2, 2016 13:58
|
|
|
We have a little agile training game thing. One of the events during the game is that a card gets blocked waiting for the DBA. I think it's the golden example. I honestly don't know what a full time DBA does.
|
|
#
?
Jun 2, 2016 14:27
|
|
|
Gounads posted:I honestly don't know what a full time DBA does. Aggressively preventing people from ever changing the database schema or executing queries against the database.
|
|
#
?
Jun 2, 2016 14:34
|
|
|
I've worked at some pretty decent sized companies and only ever dealt with a DBA at one of the smaller ones. The dude had no clue what he was doing and wasn't even as good with SQL as the developers.
|
|
#
?
Jun 2, 2016 15:11
|
|
|
On the other end of the spectrum, I've seen some pretty terrifying things that resulted from developers using ORMs to indirectly define or modify schemas without someone around to nanny them.
|
|
#
?
Jun 2, 2016 15:35
|
|
|
Steve French posted:On the other end of the spectrum, I've seen some pretty terrifying things that resulted from developers using ORMs to indirectly define or modify schemas without someone around to nanny them.
|
|
#
?
Jun 2, 2016 16:03
|
|
|
Khisanth Magus posted:Basically gently caress the people who took in documented the requirements for this. Aren't regular checkins with the client a part of agile?
|
|
#
?
Jun 2, 2016 16:51
|
|
|
Vulture Culture posted:This is why not doing code review makes baby Jesus cry. I once had a guy under me that was instructed to add the current time (with seconds) to a call center display screen. So he wrote a function that made an AJAX call to the server every second to find out the current time. I didn't chew him out but I did mock him mercilessly and make him go back and redo it.
|
|
#
?
Jun 2, 2016 17:01
|
|
|
Gounads posted:I honestly don't know what a full time DBA does. Maintain the gordian knot of undocumented ETLs that keep the reports reporting and disparate databases in sync. They require constant 'maintenance' because they're constantly confronted with data they didn't expect because the whole thing lacks any definition outside of the ETL code.
|
|
#
?
Jun 2, 2016 17:06
|
|
|
rt4 posted:Aren't regular checkins with the client a part of agile? Actually doing agile would be pretty awesome! It is a bit of a fight I'm currently having with the Project Management group here. One thing I will say that is good about this place is good DBAs. They are competent, know their stuff pretty well, and are very responsive when we need things.
|
|
#
?
Jun 2, 2016 17:19
|
|
|
Vulture Culture posted:This is why not doing code review makes baby Jesus cry. You're making an assumption that there was no code review, rather than several people being oblivious to the underlying implications of their ORM usage.
|
|
#
?
Jun 2, 2016 18:38
|
|
|
Steve French posted:You're making an assumption that there was no code review, rather than several people being oblivious to the underlying implications of their ORM usage.
|
|
#
?
Jun 2, 2016 18:43
|
|
|
Code review among programmers is not all that different from meetings, and we all know what happens in meetings:
|
|
#
?
Jun 2, 2016 21:42
|
|
|
necrobobsledder posted:Code review among programmers is not all that different from meetings, and we all know what happens in meetings: 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
|
|
#
?
Jun 2, 2016 22:21
|
|
|
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?
|
|
#
?
Jun 2, 2016 23:58
|
|
|
I assign code reviews to whomever has responded to previous code reviews the least often. It has not been entirely successful.
|
|
#
?
Jun 3, 2016 00:11
|
|
|
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? I worked at one place with infrequent "code review" meetings where someone presented a feature they worked on long after it would have been possible to implement any meaningful changes as a result of the code review. It was dumb. I worked at another place where we did code review on every commit. It didn't matter who on the team did the review, as long as the review was done. This resulted in people buddying up to let awful poo poo slide, so we changed it that one person was the code reviewer each sprint. FWIW the "code review" experience in TFVC is awful and Microsoft is well aware of it being awful. They are working on fixing it.
|
|
#
?
Jun 3, 2016 01:49
|
|
|
Vulture Culture posted:I was responding specifically to the "without someone around to nanny them" part, which is something to which code review is exceptionally well-suited. But if your entire development team has no idea what they're doing, you need to do something else I guess? Yeah, code review is the solution, but the who is an important part. I was just highlighting the opposite extreme from having a DBA micromanaging everything: where there is nobody taking ownership over such things and you just have one web dev reviewing another web dev's changes. Where I'm at now we ensure that any change that touches database schemas is reviewed and approved by the folks that maintain said databases. It's not some onerous approval process, just making sure that people with expertise and responsibility in a particular area are consulted.
|
|
#
?
Jun 3, 2016 03:35
|
|
|
Our code review process is anyone/everyone is encouraged to check out and comment on a pull request and it doesn't get merged until at least 2 people sign off on it. Some approvals are worth more than others, of course, but it tends to work pretty well. If your code reviews are at all like meetings, you're doing something terribly wrong.
|
|
#
?
Jun 3, 2016 13:28
|
|
|
metztli posted:If your code reviews are at all like meetings, you're doing something terribly wrong. Seriously. Code reviews should be asynchronous, with a direct chat if something cannot be easily agreed upon. Code reviews should happen through a tool dedicated to it if at possible. If you're having Code Review Meetings then something is hosed up. Of course, nothing can solve incompetent coworkers.
|
|
#
?
Jun 3, 2016 13:43
|
|
|
Also, junior developers code-reviewing senior developers is a good thing. They'll learn, especially if they ask questions.
|
|
#
?
Jun 3, 2016 13:56
|
|
|
Code review meetings are a really good idea once in a while, especially when you're introducing something new or particularly complex. They shouldn't be the norm, though.
|
|
#
?
Jun 3, 2016 14:57
|
|
|
good jovi posted:Code review meetings are a really good idea once in a while, especially when you're introducing something new or particularly complex. They shouldn't be the norm, though. That's what design documents are for. You should design the thing ahead of time, instead of doing it and saying "ok this is how it's going to work, hope no one is confused or disappointed."
|
|
#
?
Jun 3, 2016 15:30
|
|
|
Volmarias posted:That's what design documents are for. You should design the thing ahead of time, instead of doing it and saying "ok this is how it's going to work, hope no one is confused or disappointed." I've also been experimenting with holding a design sign-off with marketing to assure it's correct.
|
|
#
?
Jun 3, 2016 15:34
|
|
|
Volmarias posted:That's what design documents are for. You should design the thing ahead of time, instead of doing it and saying "ok this is how it's going to work, hope no one is confused or disappointed." I don't know if you've just been really lucky, but if all the clients I've dealt with actually knew what they wanted ahead of time and didn't change their mind repeatedly, my life as a developer would be much, much easier. There's also the issue that, if your client isn't familiar with development in general (or is a stubborn idiot who doesn't learn), they will become frustrated at all the time you spend trying to coax the necessary details out of them to write a design document, instead of actually doing anything 
PT6A fucked around with this message at 17:43 on Jun 3, 2016 |
|
#
?
Jun 3, 2016 17:38
|
|
|
The correct solution is to charge them for each change they request with changes getting more and more expensive towards the day of a deliverable / end of a sprint. It's worked alright for IBM... for maybe 10 years-ish. However, this is almost never how consulting can bill I've found because people that hire consultants want people that will just do whatever the people with money say to do instead of talking about such nonsense like "product quality and stability" or avoiding "death marches."metztli posted:If your code reviews are at all like meetings, you're doing something terribly wrong.
|
|
#
?
Jun 3, 2016 18:14
|
|
|
we do whole team code review. so if a feature spans three teams (data, services and api, let's say) all members of all three teams will be tagged on the code review. generally it's obvious whose approval you need but the ultimate arbiter is the team lead of the team that owns the component in question. no one is expected to review every pr tho. i skip tons that aren't relevant to me
|
|
#
?
Jun 3, 2016 18:18
|
|
|
Volmarias posted:That's what design documents are for. You should design the thing ahead of time, instead of doing it and saying "ok this is how it's going to work, hope no one is confused or disappointed."
|
|
#
?
Jun 3, 2016 18:26
|
|
|
Gounads posted:I've also been experimenting with holding a design sign-off with marketing to assure it's correct. Don't bother, the answer is always no, no matter what they say or sign.
|
|
#
?
Jun 3, 2016 18:38
|
|
|
smackfu posted:OMG, when agile meets an entrenched DBA group, so painful. I hear you. It's an organisatorial problem, though. The DBAs in such case have completely different goals and frankly don't give a gently caress about the work the developers are trying to accomplish.
|
|
#
?
Jun 3, 2016 19:04
|
|
|
Let's put it this way, if there is any job title ending with "Administration" in your company, you are in a bureaucratic culture and your ability to succeed and deliver in technical matters will have a lot more to do with how well you can plan around and accommodate bureaucratic processes and politics that you have little control over than whether you know how to write a random data structure off the top of your head.
|
|
#
?
Jun 3, 2016 19:20
|
|
|
Speaking of code-reviews, just did my last one for one guy. The feature went something like this: "When you're on Page X, make this icon bold". There was already a constant defined to tell what page you were on. The icon already existed on the page, it was font-awesome, so you just had to apply bold if a variable was set. Literally add this to the tag and you're done: ng-class="{::bold: ctrl.page=='mypage'}" What I got instead.. was.. well... wow There were 3 method calls involved two of which set side-effects on the controller to get several brand new flags set. Those 2 methods were called from other tags in the template, so the order of execution would have mattered, but luckily like I mentioned, it was a constant that never changed so the first time through always set it correct. This was our second code review on this feature. The first time I told him exactly what he had to do. This probably represents a full week of work. After going through it, I calmly told the CEO he wasn't working out (he's been on probation). Deleted the pull request. Deleted the branch it was for. He's a remote overseas developer who started 3 weeks ago. The interview went fine. I seriously think they stuck some other dude on the other end of the phone.
|
|
#
?
Jun 3, 2016 20:48
|
|
|
Remember when the huge talent pool of overseas developers was going to put first-world developers out of work with their super intelligence and willingness to work for next to nothing? That was pretty funny.
|
|
#
?
Jun 3, 2016 21:23
|
|
|
PT6A posted:Remember when the huge talent pool of overseas developers was going to put first-world developers out of work with their super intelligence and willingness to work for next to nothing? Some oversees developers are pretty good at their work though. We have one who was a contractor who used to work in our office until the US wouldn't renew his work visa, so he had to go back to India. He is still working for us there. He is drat good at his job, and we all dread when his contracts ends. Which was going to be at the end of this month, but we got it extended for another couple months.
|
|
#
?
Jun 3, 2016 21:34
|
|
|
One trend I see is that a lot of the top overseas talent quickly leave their countries to come to the US if they're younger, and then they start to displace US workers that are, gosh, not as good as them. Secondly, because nobody does off-shoring without being super price conscious wages are suppressed like they are in the US with small-time recruiting companies that have clientbases most decent developers avoid like the plague. I have some decent experiences with oversea developers in multiple continents but I've never been able to say that my best coworkers have been overseas.
|
|
#
?
Jun 3, 2016 23:09
|
|
|
Overseas coders who are actually good can ask for rates that are comparable to US developers, so price-concious companies hire people who are not them.
|
|
#
?
Jun 3, 2016 23:18
|
|
|
Yeah, we have definitely lost good overseas programmers because we wouldn't pay them enough.
|
|
#
?
Jun 4, 2016 02:30
|
|
|
Oh yeah, we definitely have to compete with developers worldwide, since location really doesn't make a big difference in a lot of cases (also an advantage for me because I can take month-long trips to wherever I like, and provided there's a broadband connection, no one gives half a gently caress). Still, the good developers overseas are roughly as rare as the good developers onshore, and they can justifiably demand similar compensation. The panic was about all these low-paid workers taking our jobs away and such. These companies wouldn't have hired you in the first place anyway, but now that they have an abortion of an application that they overpaid for even at low rates, they'll hire you at full price to unfuck it for them! If anything, these cut-rate operations (and the $1 website operations) are a boon to my business. People get stuck up poo poo creek without a paddle and they're way more willing to pay for the rescue than they were to pay for it to be done properly in the first place.
|
|
#
?
Jun 4, 2016 05:59
|
|
|
|
| # ? May 10, 2024 10:36 |
|
|
I'm working on a project for the marketing division at work in an internal contractor-like setup. Meaning, I have demos and requirements meetings with my contact in marketing, and I work on the application on my own (work) time. I've learned that I am completely miserable at managing a project on my own, both for requirements and for time  The project is not at the level of completeness I had hoped for by the next demo (tomorrow), there's no wiki or project page or anything, and I feel like I have no idea what I'm doing. I'm worried for the long term health of this project, even with it being relatively small.Is this just due to inexperience/me being an rear end in a top hat, or is there some particular way I should be approaching a project like this? Is this what I would use some form of agile project management methodology for?
|
|
#
?
Jun 5, 2016 18:24
|
|
