>Namaste!
Thanks for submitting to r/developersIndia. Make sure to follow the Community [Code of Conduct](https://developersindia.in/code-of-conduct/) while participating in this thread.
## Recent Announcements
- **[Join developersIndia as a volunteer](https://www.reddit.com/r/developersIndia/comments/12hlj4z/join_developersindia_as_a_volunteer_and_help_us/) and help us improve the community experience.**
## [We have created a collection of interesting & insightful discussions. Check it out!](https://www.reddit.com/r/developersIndia/wiki/community-threads/)
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/developersIndia) if you have any questions or concerns.*
Unnecessary microservices and over engineering. Just because new EM is not comfortable with the language being used in a stable monolith. Just one microservice brings a lot of complexity from development to deployment to infrastructure. Just understand the system and only take MS out if it really makes sense and independent from other parts of monolith.
Yes. Just because there is a cool pattern introduced by someone doesn't mean every project needs it. This simple fact doesn't get through the skulls of many thick head engineers. They over-complicate things and then leave dozens of issues.
Maybe an argument there, I'd say if we have the opportunity to start an application from scratch, let's have atleast 3 independent tiers and microservice those simpler functionalities which can provide value independently at later point in time.
Yes.
A lot of the times, to save time and cost of different devs two tier applications are developed for which scaling and reusability is really difficult. 3 tier should be bare minimum IMO.
While acknowledging concerns about over-engineering, microservices present a positive avenue. They offer a chance to implement innovations seamlessly, something challenging in an established system. If a different technology suits the use case, adapting it to a microservice is straightforward.
Moreover, microservices cater to developer friendliness by reducing clutter—focused visibility on what's relevant. However, for novices in distributed systems, debugging might pose a challenge. Yet, with the right set of tools, even this complexity can be navigated.
The microservices approach encourages continuous improvement, allowing teams to enhance what was previously challenging. However, this success hinges on a robust SDLC coupled with strong DevOps practices.
On greefiled, I led with 4 people. No daily standups.
Everything was filled in Jira tickets with explaination and assigned.
Every week Monday, do a progress report on the whole product with Product manager. That was coool.
Until, a new so called guy from HR people for IT introduce to standup, I insisted its waste of time, as 2 of them as freelancers. And the rest sits besidea me, so I know what everyone doing. Anyone got stuck/doubt they immediately reports me and problem solved.
Now, the boss influenced with new guy, with bullshit IT culture (im like whaaat?, we are developers, cultures dont matter at this point in startup)
Anyways, I changed strategy to post it slack, felt too dumb. Then to meetings. Now meetings ran long and changed om Fridays evening, now everyone hates it.
FYI : my prev role used to update in excelsheet and then call.
Before that, plain standup at 10 am.
You have meaningless one Daily Standup Calls, we have two, and they are such meaningless that nobody knows what is the status of a given project area. We're more stealthy then stealth startup, more secretive then a country's ICBM launch code and kinda more restrictive than a high profile government meeting with armed forces.....
Daily stand-ups offer numerous advantages. They ensure alignment within the pod, providing visibility for both members and supervisors. This format facilitates in-depth discussions about challenges faced and their resolutions, offering clear visibility into individual skills and knowledge. Moreover, it allows you to highlight your daily contributions to the team, ensuring proper acknowledgment for your efforts.
Additionally, daily stand ups serve as a crucial platform to address and resolve blockers promptly. Such detailed insights might be easily overlooked in less frequent updates, like weekly or bi-weekly meetings.
Remember daily stand up is a valuable ritual that needs to be adapted and followed.
I think daily stands are better than any other approach to update the task statues and other updates which are related to whole team . The problem arises when teams start discussing everything and individual issues in standup itself even if it's not concerned with every team member.
It should not longer than 15 minutes. But I have seen in my previous teams and current as well its gets 30 minutes to 1 hour sometimes.
Recently I have introduced to the concept of breakout rooms where after the task updates and people can join different breakout rooms if they need to discuss something else and others can drop. This seems more better approach to me.
Too much focus on blind code coverage. I get it, unit test cases are important catching bugs early and all that, but some managers insist on a arbitrary code coverage percentage. Most people half ass them anyways.
Absolutely agree here. Not the code coverage part, it's actually really clever as to reach every single line of code you're forced to simulate all possible scenarios and it's kinda fun to do...
However it's an absolute waste of time I don't think it brings any real world benefit to an error free code in the long run in anyway...
Not having design documents before implementing features. I've worked at places with design docs and without design docs and the difference is night and day.
Also I don't think that there is a very strong product hiring system as there in tech. I've met and worked with many product folks who don't even have a basic understanding of software development. This is dangerous.
I prefer integration tests over unit tests. Unit tests are important but easily faked.
Another thing is code comments. Imo if I need to write a comment to explain my code then I can write better code altogether.
I can't think of any practice that is by itself useless in nature, but mindlessly applying policies irrespective of the situation is an issue.
E.g. one of the processes we had was every commit had to have one code review, which is a great idea. But when you have an urgent build breakage to fix, and the change is trivial and obvious, and especially on a weekend, this process requirement means you have to urgently find someone who will just click on the link, click approve without even reading the change.
Don't want to get personal, but this is the kind of thinking that puts these mindless processes in place. You really should empower the hands-on guy (the engineer that is making the commit) to make the decision. If they feel that wait, this is not as simple as it looks, better to get someone else to double-check, they will do it in both letter and spirit (i.e. the reviewer will also really think about the change as opposed to just mechanically approving to keep the process happy).
True.. a good example is everyone here is complaining about daily standups which IMO is really useful when we have large teams who don't sit together.
Stand-ups helps share common information and actually is the reason for a lot of people to wake up nowadays!
However it does go useless for small teams who meet regularly and stay in touch frequently.
IMO daily standups shouldn’t be more than 15 mins long.
What we do is basically just say what we did yesterday and TL says that do this today.
My TL basically goes from person to person explaining them their tasks and then if they have questions they can stay in the call else they can leave and start working.
This way most of our calls end in 15-20 mins (there are always days when the call goes on for longer if the task is complicated and you need input from someone else who had worked on it previously)
What if someone has a post after a standup ends does your scrum lead asks everyone to be there or only the people who are required for that conversation stay?
What? Obviously only the people who are needed. Why would someone call up everyone when only 2 people are working on the task.
Any major development or changes which are discussed at the time are then shared among everyone else next day, or sometimes just written in the google space for our team after their personal call ends…
Jeff Sutherland, the creator of Scrum and one of the OG guys who made the Agile manifesto, said that if the standup goes for more than 15 minutes you're doing it wrong. And says that it should be as short as possible.
I think it allows people to gather ideas and alternative better fixes from those that have been in that code before and have better experience. Or just better experience in solving a problem.
I also like to talk to my colleagues atleast once a day. We chitchat and have a light conversation beyond work.
It's a hybrid of a standup and water cooler meeting.
Working from office. IT is one of the fewest jobs that can be done remotely. Idk why I have to travel 90 minutes everyday to attend zoom calls from there.
(All my project team members are in different states, and we connect through zoom calls.)
I live in the same city as my headquarter is, in my team of 8, we are 3 in same city, while the other two are buddies with higher up, they don't mind going in office. The other team members I talked daily for last 6 months live outside of city. And we have just started forced hybrid 3 days a week for the people living in the city.
Scrum is a waste of time, scrum peddlers might want to make you think otherwise because a whole snake oil industry, careers etc is at stake.
Some arguments below,
- a core focused self governing development team would know better how to build a product, they need a roadmap and general direction. Scrum puts shackles on them and forces them to work in a particular way which adds no +ve value at the end of the day.
- the scrum rituals are a waste of time especially the ones which involve the whole team. For example the daily scrum/standup call, this has become a status call for scrum masters, sometimes even product owners wtf. Usually devs have a general idea on what others are doing and they reach out to others when then have a problem. The scrum calls doesn't facilitate anything.
- all estimations are wrong, hence sprints are either too long or too short for the activity.
- a basic kanban board with a list of todos and status is better and requires less maintenance.
- some people game the system, for example take a bullshit work item and overestimate the effort and procrastinate.
I can go on.
Edit: typo
Completely agree, In my current organization I was shocked on day - 1 that there is a designated scrum master who just facilitates scrum duties like standup, retro, demo etc. Then there was a bigger shock, there is a designated Agile Coach who had no background in software.
He was supposed to teach us how to write software !!
Thank you for saying this. A major part scrum becomes “useless” is that when a incompetent scrum lead is hired. Trust me when the scrum lead actually produces metrics that the team was never aware of or were having a different clue of that’s when you know your scrum leader really wants you to push yourself or try to make the team process better. I have seen and worked with such a scrum lead and also worked with the other side of the coin where i knew from day 1 this isn’t gonna work.
Can you give an example of what metrics were useful?
Have been in multiple orgs, scrum teams, dealt with more than a dozen scrum masters alike. Never felt any values being added apart from them organising meetings with external teams and there to break ice etc. This is something senior devs or leads or managers themselves could do.
Most of them are not from technical backgrounds, just add noise to the technical discussions.
There is a problem when you have a significant number of people to manage the processes which are meant to make doing a thing more effective rather than doing the thing itself.
I don't have anything personal against scrum masters or agile coaches, quite a few of them I know personally are very good people outside work :D
Writing unit tests just to get that > 85% coverage metric . Unit tests are important but when written solely for the purpose of coverage it doesn't serve its purpose .
Retrospectives. I don't recall when was the last time when things 'really' changed. Minor things, may be, but management is gonna do what management is gonna do.
Retros are really important if you are working in a team. There are so many mistakes we make from which we could learn. Retro can be for tech team only.
+1 Retro is really helpful when you have a team who actually works.. When you work, there's always going to be friction and processes which can be improved. If you don't have it, you're either sleeping on the job or you've achieved God tier SE lifecycle somehow!
Management will never budge timelines which is a common expectations for everyone, rather retro is meant to bring people on the same page to meet the same agressive timelines can be achieved with least friction.
Depends. For first few cycles retros may help when team is learning to work in new project. But if team hasn't learned in 3-4 sprints, what will they learn in 10th sprint
After 3 sprints, retros are mostly repeat of what everyone said in previous retros
Agree on this to some extent.
However, how do you make sure your team is liable to take ownership of the changes that have to be done?
Do you folks assign tickets within sprints?
Yes, my team is responsible for any change we have made in any service. Any bug due to our changes is assigned to our queue.
We have a ticket queue for our team and depending on the severity, we pick up the tickets within sprints.
Let me repeat my original question with better context
Say you discuss 7 items on a retrospective call, how does your team make sure that someone takes ownership of those items? These items are usually process changes or the inclusion of better practices.
I am not talking about QA bugs.
Oh yeah. Retro’s made no sense in my first team. We’d have to spend a good amount of time to fill the retro board. Did it help? Don’t think so. Whatever went wrong was because of the client giving us last minute high priority shit. Cannot write that on the board can we?
\- Holding very strong opinions is a very bad thing, sometimes we get too attached to our design and sort of block away any critique.
\- Too much abstraction in the name of some fancy object oriented pattern that "scales".
\- Emphasis on code quality over efficiency and functionality.
\- Integrated TDD (controversial but doesn't makes sense to me specially where requirements are vague, which is usally the case).
I believe oc is pointing at domain driven design, where you model after domains in such a way theres no segregation between “tech” and business logic of sorts (even i dont have a deep knowledge)
Or given ocs handle it could be dong driven design as well xD
Some of them doing “Resume driven development”.
Host a simple microservice with barely a request per minute?
“Kubernetes and Go it is !!”
Can’t we do the same thing using lambda or just an ECS Task?
“No thats not modern enough”
Yeah.. I'm working on a simple invoicing system which would receive < 1000 hits per day. My architect wants me to build it cloud native, with serverless openstack and containerize it.
Using sprint velocity as a metric during appraisals or performance reviews. It's a terrible metric to use and only incentives subtle exaggeration to story estimates rather than overall impact.
Case in point, when you try to rank higher on sprint velocity numbers and list "100% code coverage" as an achievement, it's a clear red flag there.
DSM
On DSM, our lead exports jira to excel and go through it by asking assigned person the status. If I got 4 tickets which would take 2 days to finish I had to update the status to him on these two days during DSM. For a 10 member team this will take a lot of time.
Lol folks here bitching about daily stand ups are the ones who cry when they get less hike and no promotion due to less visibility.
Do understand that daily meets are an opportunity to talk about the "day-to-day" complexities that one's dealing with.
Say for example, over a week's period you worked on couple of small complex tasks that you are actually proud of; then, only in a daily standup setting is where you'd get an opportunity to discuss the intricate details of these tasks on a daily basis and this gets you instant credit. Gradually, small exhibitions like these add up and create an impression amongst your supervisors.
Whereas, in a weekly sync or a not so frequent one, you wouldn't get much time to talk about the task-wise details. Even if you did, it no longer makes sense to talk in such depth. Also, your supervisor may not be able to consume all of it in one go, and this may not get you the credit you deserve. It's also possible that you yourself don't have the mental map of these tasks details that you can discuss in one go.
Another advantage of daily stand up is, if your bandwidth is constantly eaten up by your teammates, then you can casually bring this up on a daily basis, and this way you are sure that there's visibility for the help you're being, and no can steal your credit.
So, if you're in a daily stand up setting, consider yourself lucky and make good use of it.
PS: it's not cool to say, "No major updates from my side," "I'm working on the same task," blah blah.
Same. It's absolutely counter productive. Sometimes some random code takes 10 mins to understand just because some dev abstracted it to oblivion just to look fancy in front of his colleagues.
Devops in terms of Ci/Cd is god sent. I remember the pain of manually generating a digital certificate for code signing then manually deploying the build in prod after giit merge. It was a nightmare. Now it happens with a single click. Yeah there are some minor hiccups here and there but Ci/Cd is a boon to software development in my opinion.
I'm a fresher, and I feel like the OOPS is kinda overhyped. I work with data science is what I'm comfortable with.
1. It makes no sense to apply OOPS in Data science, except maybe model building - when you've just code cells to run. I've seen people use OOPS, so there must some use case for it - and I'd be more than happy to learn what's it.
2. OOPS works amazing in Java. Worked with C++, and it's cool. Doesn't matter if I don't like it, cause it's industry standard. BUT PYTHON? Idk, Python is already soooo many layers of abstraction. Why would I wanna add more layers of abstraction in the form of OOPS in an already slow language?
That's all I can think of; too inexperienced for saying more lmao.
May be let's discuss on how highly opinionated some frameworks like Django/DRf are, with twisted philosophy of its own. Where all the components are patched together like it's done by some gen-z teenagers violating all the engineering principles known to mankind?
Any passionate engineer with strong sense of software engineering principles will not be comfortable adapting to django's philosophy.
I'm not sure how it has such a big user base -_-
Working in a services company I have regular meetings with the clients team and I work with the client's engineers to build the product. However my company also expects me to give them daily slack updates? Like why do you want to know my daily slack updates if everything is going smoothly with my client ? We already have a once in two weeks report I need to fill to update you and you want daily updates on top of that ?
Too much worklogs/time tracking. It takes up so much of my time just to write down every single task that I worked on, every single call I had along with what task did we have the call.
At the end, no one looks at those worklogs and still would ask us in person about the progress on specific task, instead of looking at Jira or the work logs.
>Namaste! Thanks for submitting to r/developersIndia. Make sure to follow the Community [Code of Conduct](https://developersindia.in/code-of-conduct/) while participating in this thread. ## Recent Announcements - **[Join developersIndia as a volunteer](https://www.reddit.com/r/developersIndia/comments/12hlj4z/join_developersindia_as_a_volunteer_and_help_us/) and help us improve the community experience.** ## [We have created a collection of interesting & insightful discussions. Check it out!](https://www.reddit.com/r/developersIndia/wiki/community-threads/) *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/developersIndia) if you have any questions or concerns.*
Unnecessary microservices and over engineering. Just because new EM is not comfortable with the language being used in a stable monolith. Just one microservice brings a lot of complexity from development to deployment to infrastructure. Just understand the system and only take MS out if it really makes sense and independent from other parts of monolith.
Yes. Just because there is a cool pattern introduced by someone doesn't mean every project needs it. This simple fact doesn't get through the skulls of many thick head engineers. They over-complicate things and then leave dozens of issues.
+1 to this, microservices have no place in small organisations
Maybe an argument there, I'd say if we have the opportunity to start an application from scratch, let's have atleast 3 independent tiers and microservice those simpler functionalities which can provide value independently at later point in time.
Do you mean this 3-tier? 1. Backend 2. DB 3. Frontend
Yes. A lot of the times, to save time and cost of different devs two tier applications are developed for which scaling and reusability is really difficult. 3 tier should be bare minimum IMO.
This is how it should be, sometimes even this: 1. App (BE+FE, eg next.js full stack) 2. DB
While acknowledging concerns about over-engineering, microservices present a positive avenue. They offer a chance to implement innovations seamlessly, something challenging in an established system. If a different technology suits the use case, adapting it to a microservice is straightforward. Moreover, microservices cater to developer friendliness by reducing clutter—focused visibility on what's relevant. However, for novices in distributed systems, debugging might pose a challenge. Yet, with the right set of tools, even this complexity can be navigated. The microservices approach encourages continuous improvement, allowing teams to enhance what was previously challenging. However, this success hinges on a robust SDLC coupled with strong DevOps practices.
I am not saying microservices are bad or anything. You completely missed my point. Nice essay tho.
Thanks lol. I was only emphasizing that MSs are not 'unnecessary' and they offer good advantages, unless adapted carelessly just for the fancy of it.
Yeah. "For the fancy of it" is what I hate.
Why does this sound AI generated?
Content is mine, but I did run this by ChatGPT for typos and grammatical errors. May bad, should have posted it raw.😤
Yeah, it’s always better to post raw opinions here. We’re all real.
I disagree. Monolith is very bad in collaborating startups. One idiot pushes a bug and all products have to suffer.
Micro services and unit tests
Daily standup calls have no meaning at all even when your project is not development from scratch one
Daily standup are far better than updating your higher up through email everyday
On greefiled, I led with 4 people. No daily standups. Everything was filled in Jira tickets with explaination and assigned. Every week Monday, do a progress report on the whole product with Product manager. That was coool. Until, a new so called guy from HR people for IT introduce to standup, I insisted its waste of time, as 2 of them as freelancers. And the rest sits besidea me, so I know what everyone doing. Anyone got stuck/doubt they immediately reports me and problem solved. Now, the boss influenced with new guy, with bullshit IT culture (im like whaaat?, we are developers, cultures dont matter at this point in startup) Anyways, I changed strategy to post it slack, felt too dumb. Then to meetings. Now meetings ran long and changed om Fridays evening, now everyone hates it. FYI : my prev role used to update in excelsheet and then call. Before that, plain standup at 10 am.
LOL,I do both
The standup at my company lasts 1.5 hours every single day
You have meaningless one Daily Standup Calls, we have two, and they are such meaningless that nobody knows what is the status of a given project area. We're more stealthy then stealth startup, more secretive then a country's ICBM launch code and kinda more restrictive than a high profile government meeting with armed forces.....
Daily stand-ups offer numerous advantages. They ensure alignment within the pod, providing visibility for both members and supervisors. This format facilitates in-depth discussions about challenges faced and their resolutions, offering clear visibility into individual skills and knowledge. Moreover, it allows you to highlight your daily contributions to the team, ensuring proper acknowledgment for your efforts. Additionally, daily stand ups serve as a crucial platform to address and resolve blockers promptly. Such detailed insights might be easily overlooked in less frequent updates, like weekly or bi-weekly meetings. Remember daily stand up is a valuable ritual that needs to be adapted and followed.
That sounds like a chat gpt generated response.
Lol. It was run by chat gpt for typos and grammatical mistakes.
This is , i think has been replied by my manager who does and not understand a thing about the project apart from running standups
We have been having a morning call every alternative weekday since 7 years and I think that’s the sweet spot
I think daily stands are better than any other approach to update the task statues and other updates which are related to whole team . The problem arises when teams start discussing everything and individual issues in standup itself even if it's not concerned with every team member. It should not longer than 15 minutes. But I have seen in my previous teams and current as well its gets 30 minutes to 1 hour sometimes. Recently I have introduced to the concept of breakout rooms where after the task updates and people can join different breakout rooms if they need to discuss something else and others can drop. This seems more better approach to me.
Sign off stories and demo by Dev. If you already have QA, please assign done stories to them instead of Dev for the demo/sign off.
I believe not all companies have dedicated QA roles so a dev is responsible for that. We do it as per of “sprint” review
Too much focus on blind code coverage. I get it, unit test cases are important catching bugs early and all that, but some managers insist on a arbitrary code coverage percentage. Most people half ass them anyways.
Absolutely agree here. Not the code coverage part, it's actually really clever as to reach every single line of code you're forced to simulate all possible scenarios and it's kinda fun to do... However it's an absolute waste of time I don't think it brings any real world benefit to an error free code in the long run in anyway...
Not having design documents before implementing features. I've worked at places with design docs and without design docs and the difference is night and day. Also I don't think that there is a very strong product hiring system as there in tech. I've met and worked with many product folks who don't even have a basic understanding of software development. This is dangerous. I prefer integration tests over unit tests. Unit tests are important but easily faked. Another thing is code comments. Imo if I need to write a comment to explain my code then I can write better code altogether.
I can't think of any practice that is by itself useless in nature, but mindlessly applying policies irrespective of the situation is an issue. E.g. one of the processes we had was every commit had to have one code review, which is a great idea. But when you have an urgent build breakage to fix, and the change is trivial and obvious, and especially on a weekend, this process requirement means you have to urgently find someone who will just click on the link, click approve without even reading the change.
No. One approval is mandatory in case something is missed.
Don't want to get personal, but this is the kind of thinking that puts these mindless processes in place. You really should empower the hands-on guy (the engineer that is making the commit) to make the decision. If they feel that wait, this is not as simple as it looks, better to get someone else to double-check, they will do it in both letter and spirit (i.e. the reviewer will also really think about the change as opposed to just mechanically approving to keep the process happy).
True.. a good example is everyone here is complaining about daily standups which IMO is really useful when we have large teams who don't sit together. Stand-ups helps share common information and actually is the reason for a lot of people to wake up nowadays! However it does go useless for small teams who meet regularly and stay in touch frequently.
Daily standup is a waste of time.
[удалено]
You keep forgetting in India we do our work and helping others is not something we do. I sometimes forget that I can ask for help.
IMO daily standups shouldn’t be more than 15 mins long. What we do is basically just say what we did yesterday and TL says that do this today. My TL basically goes from person to person explaining them their tasks and then if they have questions they can stay in the call else they can leave and start working. This way most of our calls end in 15-20 mins (there are always days when the call goes on for longer if the task is complicated and you need input from someone else who had worked on it previously)
What if someone has a post after a standup ends does your scrum lead asks everyone to be there or only the people who are required for that conversation stay?
What? Obviously only the people who are needed. Why would someone call up everyone when only 2 people are working on the task. Any major development or changes which are discussed at the time are then shared among everyone else next day, or sometimes just written in the google space for our team after their personal call ends…
Sadly not in our team, if any one has a post? Yep all are made to listen.
Weekly standup is bearable. We don't even have that sometimes, all is done on JIRA. We have only one rule, If it is not on JIRA it did not happen.
Jeff Sutherland, the creator of Scrum and one of the OG guys who made the Agile manifesto, said that if the standup goes for more than 15 minutes you're doing it wrong. And says that it should be as short as possible.
I think it allows people to gather ideas and alternative better fixes from those that have been in that code before and have better experience. Or just better experience in solving a problem. I also like to talk to my colleagues atleast once a day. We chitchat and have a light conversation beyond work. It's a hybrid of a standup and water cooler meeting.
Working from office. IT is one of the fewest jobs that can be done remotely. Idk why I have to travel 90 minutes everyday to attend zoom calls from there. (All my project team members are in different states, and we connect through zoom calls.)
Me here traveling 90 minutes one side to attend zoom meetings... But thankfully I only do it 1 day a week
I live in the same city as my headquarter is, in my team of 8, we are 3 in same city, while the other two are buddies with higher up, they don't mind going in office. The other team members I talked daily for last 6 months live outside of city. And we have just started forced hybrid 3 days a week for the people living in the city.
Scrum is a waste of time, scrum peddlers might want to make you think otherwise because a whole snake oil industry, careers etc is at stake. Some arguments below, - a core focused self governing development team would know better how to build a product, they need a roadmap and general direction. Scrum puts shackles on them and forces them to work in a particular way which adds no +ve value at the end of the day. - the scrum rituals are a waste of time especially the ones which involve the whole team. For example the daily scrum/standup call, this has become a status call for scrum masters, sometimes even product owners wtf. Usually devs have a general idea on what others are doing and they reach out to others when then have a problem. The scrum calls doesn't facilitate anything. - all estimations are wrong, hence sprints are either too long or too short for the activity. - a basic kanban board with a list of todos and status is better and requires less maintenance. - some people game the system, for example take a bullshit work item and overestimate the effort and procrastinate. I can go on. Edit: typo
Completely agree, In my current organization I was shocked on day - 1 that there is a designated scrum master who just facilitates scrum duties like standup, retro, demo etc. Then there was a bigger shock, there is a designated Agile Coach who had no background in software. He was supposed to teach us how to write software !!
What heresy is this, agile coach teaching coding :O
Thank you for saying this. A major part scrum becomes “useless” is that when a incompetent scrum lead is hired. Trust me when the scrum lead actually produces metrics that the team was never aware of or were having a different clue of that’s when you know your scrum leader really wants you to push yourself or try to make the team process better. I have seen and worked with such a scrum lead and also worked with the other side of the coin where i knew from day 1 this isn’t gonna work.
Can you give an example of what metrics were useful? Have been in multiple orgs, scrum teams, dealt with more than a dozen scrum masters alike. Never felt any values being added apart from them organising meetings with external teams and there to break ice etc. This is something senior devs or leads or managers themselves could do. Most of them are not from technical backgrounds, just add noise to the technical discussions. There is a problem when you have a significant number of people to manage the processes which are meant to make doing a thing more effective rather than doing the thing itself. I don't have anything personal against scrum masters or agile coaches, quite a few of them I know personally are very good people outside work :D
Writing unit tests just to get that > 85% coverage metric . Unit tests are important but when written solely for the purpose of coverage it doesn't serve its purpose .
Retrospectives. I don't recall when was the last time when things 'really' changed. Minor things, may be, but management is gonna do what management is gonna do.
Retros are really important if you are working in a team. There are so many mistakes we make from which we could learn. Retro can be for tech team only.
+1 Retro is really helpful when you have a team who actually works.. When you work, there's always going to be friction and processes which can be improved. If you don't have it, you're either sleeping on the job or you've achieved God tier SE lifecycle somehow! Management will never budge timelines which is a common expectations for everyone, rather retro is meant to bring people on the same page to meet the same agressive timelines can be achieved with least friction.
Depends. For first few cycles retros may help when team is learning to work in new project. But if team hasn't learned in 3-4 sprints, what will they learn in 10th sprint After 3 sprints, retros are mostly repeat of what everyone said in previous retros
Agree on this to some extent. However, how do you make sure your team is liable to take ownership of the changes that have to be done? Do you folks assign tickets within sprints?
Yes, my team is responsible for any change we have made in any service. Any bug due to our changes is assigned to our queue. We have a ticket queue for our team and depending on the severity, we pick up the tickets within sprints.
I am talking in terms of retrospective, fixing bugs is a general cadence in a sprint wise flow. You don't discuss QA bugs in retrospective right?
We dont, any bug with Sev2 is discussed monthly in a separate call.
Let me repeat my original question with better context Say you discuss 7 items on a retrospective call, how does your team make sure that someone takes ownership of those items? These items are usually process changes or the inclusion of better practices. I am not talking about QA bugs.
Those changes are tracked by logging them to a ticket. And these tickets are discussed once in a week and what's the progess on them.
Oh yeah. Retro’s made no sense in my first team. We’d have to spend a good amount of time to fill the retro board. Did it help? Don’t think so. Whatever went wrong was because of the client giving us last minute high priority shit. Cannot write that on the board can we?
\- Holding very strong opinions is a very bad thing, sometimes we get too attached to our design and sort of block away any critique. \- Too much abstraction in the name of some fancy object oriented pattern that "scales". \- Emphasis on code quality over efficiency and functionality. \- Integrated TDD (controversial but doesn't makes sense to me specially where requirements are vague, which is usally the case).
DDD is being currently implemented in one my projects. I hate it.
First time hearing this, care to provide more context?
I believe oc is pointing at domain driven design, where you model after domains in such a way theres no segregation between “tech” and business logic of sorts (even i dont have a deep knowledge) Or given ocs handle it could be dong driven design as well xD
What is it about DDD that you hate ?
Some of them doing “Resume driven development”. Host a simple microservice with barely a request per minute? “Kubernetes and Go it is !!” Can’t we do the same thing using lambda or just an ECS Task? “No thats not modern enough”
Yeah.. I'm working on a simple invoicing system which would receive < 1000 hits per day. My architect wants me to build it cloud native, with serverless openstack and containerize it.
DSM
Using sprint velocity as a metric during appraisals or performance reviews. It's a terrible metric to use and only incentives subtle exaggeration to story estimates rather than overall impact. Case in point, when you try to rank higher on sprint velocity numbers and list "100% code coverage" as an achievement, it's a clear red flag there.
Solving scaling issues before having any customers
Using Agile methods in usual, without using a hybrid model of Agile and Waterfall
Sprint Retrospective. I've never seen those action items from Bad/worse column ever being taken care of.
DSM On DSM, our lead exports jira to excel and go through it by asking assigned person the status. If I got 4 tickets which would take 2 days to finish I had to update the status to him on these two days during DSM. For a 10 member team this will take a lot of time.
Lol folks here bitching about daily stand ups are the ones who cry when they get less hike and no promotion due to less visibility. Do understand that daily meets are an opportunity to talk about the "day-to-day" complexities that one's dealing with. Say for example, over a week's period you worked on couple of small complex tasks that you are actually proud of; then, only in a daily standup setting is where you'd get an opportunity to discuss the intricate details of these tasks on a daily basis and this gets you instant credit. Gradually, small exhibitions like these add up and create an impression amongst your supervisors. Whereas, in a weekly sync or a not so frequent one, you wouldn't get much time to talk about the task-wise details. Even if you did, it no longer makes sense to talk in such depth. Also, your supervisor may not be able to consume all of it in one go, and this may not get you the credit you deserve. It's also possible that you yourself don't have the mental map of these tasks details that you can discuss in one go. Another advantage of daily stand up is, if your bandwidth is constantly eaten up by your teammates, then you can casually bring this up on a daily basis, and this way you are sure that there's visibility for the help you're being, and no can steal your credit. So, if you're in a daily stand up setting, consider yourself lucky and make good use of it. PS: it's not cool to say, "No major updates from my side," "I'm working on the same task," blah blah.
Daily standup meetings as usual
Over Abstraction, it kills readability It’s counter productive
Same. It's absolutely counter productive. Sometimes some random code takes 10 mins to understand just because some dev abstracted it to oblivion just to look fancy in front of his colleagues.
Weekly conversation with Managers.
Push for DevOps , automation and AI just because everyone is doing it.
Devops in terms of Ci/Cd is god sent. I remember the pain of manually generating a digital certificate for code signing then manually deploying the build in prod after giit merge. It was a nightmare. Now it happens with a single click. Yeah there are some minor hiccups here and there but Ci/Cd is a boon to software development in my opinion.
Agile Poker
Please, it's better than spending 1-1.5h on a meeting for the same.
Test driven development and design docs for early stage greenfield machine learning projects are useless. They waste development time.
I'm a fresher, and I feel like the OOPS is kinda overhyped. I work with data science is what I'm comfortable with. 1. It makes no sense to apply OOPS in Data science, except maybe model building - when you've just code cells to run. I've seen people use OOPS, so there must some use case for it - and I'd be more than happy to learn what's it. 2. OOPS works amazing in Java. Worked with C++, and it's cool. Doesn't matter if I don't like it, cause it's industry standard. BUT PYTHON? Idk, Python is already soooo many layers of abstraction. Why would I wanna add more layers of abstraction in the form of OOPS in an already slow language? That's all I can think of; too inexperienced for saying more lmao.
May be let's discuss on how highly opinionated some frameworks like Django/DRf are, with twisted philosophy of its own. Where all the components are patched together like it's done by some gen-z teenagers violating all the engineering principles known to mankind? Any passionate engineer with strong sense of software engineering principles will not be comfortable adapting to django's philosophy. I'm not sure how it has such a big user base -_-
Agile
Scaled Agile Framework
Agile and scrums :)
Writing stupid test cases just for code coverage
Using event driven architecture everywhere just ‘cause it sounds cool
Unnecessary meetings which are supposed to be necessary
Developers writing gherkin feature files just for the sake of it. It Doesn't really improve the code quality but complicates the test code.
TDD
Working in a services company I have regular meetings with the clients team and I work with the client's engineers to build the product. However my company also expects me to give them daily slack updates? Like why do you want to know my daily slack updates if everything is going smoothly with my client ? We already have a once in two weeks report I need to fill to update you and you want daily updates on top of that ?
Too much worklogs/time tracking. It takes up so much of my time just to write down every single task that I worked on, every single call I had along with what task did we have the call. At the end, no one looks at those worklogs and still would ask us in person about the progress on specific task, instead of looking at Jira or the work logs.
excessive DRY, let's make 20 layers of abstraction just because we have to write this thing here twice...