I'd say it's gotta be development effort estimation. In an Agile workflow, this would involve planning poker during sprint planning, where each member goes about assigning story points for various tasks. The results can be widely subjective. Here are some reasons in my experience:
Firstly it can depend on who's picking up the particular feature and their working style.
Often in planning stage, there are these little gaps in our current understanding of the code-base, which can either delay or speed up the feature development - and the only way to find out is when you actually start working on it.
Also depends on the understanding of the overall product feature. Sometimes during actual development you tend to discover these edge cases that haven't been accounted for by the product team. So you kinda have to circle-back to them and wait for their response on what they think should be the expected behavior, which can introduce further delays.
Development could also potentially get delayed if some key member of the team who has a more in-depth understanding of something essential is unavailable. Maybe they're too busy, or maybe they're on a holiday.
Most activities in software development can be solved to a degree, but this one seems so subjective that it almost feels like rolling a dice. Other than just adding extra time to the estimate (which raises the question - how much time?) to account for contingencies, I don't know if there is any strategy for this. Would love to hear other's thoughts. 😃
I worked in a setting where estimates were not essential to business. The founder came up with a system like the following for communicating what work was being done and raising awareness of blockers:
create Asana project for each major effort (a product line, a consulting project, ...)
define some high level milestones along with any known tasks
each developer, in increments of about one hour (potentially logged at end of day), defines micro tasks which spanned an hour or a few hours, as they start the work or as they come close to completing the micro tasks
mark milestones complete when they are completed
You get very detailed visibility about blockers, direction of tasks, and choice of approach. Tech leads can daily or weekly provide feedback and steer in a different direction if choice of tasks or milestones are not leading to delivered results that will continue to accomplish overall project goals. There is no estimation, but you can look back and see gantt charts or calenders of microtasks.
This is an interesting approach to work! Would love to know more on what was the business domain that you worked in, where estimates were not super essential.
The company was a mixture of custom scientific consulting (writing running long, expensive batch jobs), custom application development, and a long term SaaS product, still in development. The projects that I worked on were for custom application development, and our clients were very flexible about delivery dates.
We had four experienced engineers using this workflow on four solo projects and they each loved it. I especially liked the visuals that Asana produces once you enter the microtasks. We also did a weekly report to summarize our feelings on how the project was going.
I see! I think more companies should adopt this working style. From what I've seen, many of them just want you to keep grinding sprint after sprint, insisting on deadlines even when there isn't any actual pressure from clients to ship a certain feature.
It actually is agnostic about how hard you work. For example, I put a lot of pressure on myself in that system to deliver a lot each day. I just like that it focuses on recording as you go and looking back, rather than spending lots of time on estimation, velocity, etc, and excessive time specifying tasks so that you can estimate them. I like deep requirements gathering though. I just don't like an obsession with estimation. My ideal system is something between the described system and kanban with bi-weekly retros.
The worst job that I ever worked (worked for about 10 different development shops), at a "best employer in healthcare" and "best employer in region", shoved this top down quarterly planning process on all the developer teams and had us spend 15% of our time in backlog grooming, task creation, scrum ceremonies, etc. Mostly well meaning people, just horrible experience for developers, no ability to focus or reach flow, task creation and grooming was a constant nightmare.
After that experience, I shudder whenever I see a tech company that has won "best employer" awards. I also don't trust Glassdoor anymore. I think the only way to learn about these problems is to experience a company first hand for a few weeks.
Also, if I see someone is using Jira, I start to ask very probing questions in interviews to try to understand why they arrived at heavyweight, clumsy jira.
Estimation is definitely a challenge that requires a team effort to get right. I recently shared a guide that I wrote for my own teams, perhaps there are insights that can help? A Guide to Story Point Estimation
One extreme way to solve this is to go with #noestimates but it's a highly polemic subject. Some people (mostly managers ?) really love estimating things beforehand.
It's frustrating, but also gratifying with the right mindset: When you spend hours on a problem, and the solution is some stupid typo.
It's literally the worst. Like— I just ruined my day for a typo.
The gratifying part is that these are usually the times where I read a lot of documentation, reach a lot of source code, and generally level up as a developer. Without that appreciation and acknowledgment, it's only frustration. 🥲
You have a nice idea, and then you checkout what the market offers to help, and it's either legacy solutions or not yet production ready.
Software development is all about making compromises. The smarter you are, the better the compromise is.
Should you go all in on AWS because their CDK supports all their services? This means you have to use something like DynamoDB, which is rather low-level for a DB, or a relational alternative that isn't billed on demand.
Want to use something more modern, like FaunaDB? Well, then good luck finding a IaC framework that supports it and doesn't kill your vibes with YAML.
this needs to be higher. my most recent job has been actually pretty good about this though telling the business that they have to deal with it until a new story can be brought in an completed in the next sprint
My frustrations typically stemmed from one of two sources:
Collaboration with Team Members
Because of my style as team lead, I worked hard to manage expectations, and that meant delivering promises on time. I actively worked to keep expectations conservative, but when team members would drop the ball, I was often times left being the one putting in the long hours to make good on the promise.
This ranged from PMs not getting hands on with a MVP scheduled to launch, to Direct Reports quitting because they over promised and under delivered while refusing to be transparent on the actual progress of the work.
Tier 0 Support
Our engineering org doesn't have a dedicated support team, instead engineers are rotated weekly with the responsibility of handling support requests. It's often times a disruptor to planned work, and you can easily find your days being derailed by one support issue. I quickly became frustrated with these duties in part to my past experience. Unlike most engineers in my org, I had a 10 year background in helpdesk support. I don't mind providing support, but I paid my dues handling requests that haven't been triaged. My purpose in support should be to train others, and only get involved when tickets get elevated to the top tier.
Business. It dictates everything. No matter how cool and ambitious your ideas are, if you cannot sell them properly, they’re useless. No matter how sure you are that doing “A” is wrong, if it’s requested by a major customer, just do it silently.
Jack of all trades (Full-stack engineer).
Navigating my way through the world of tech.
Writing about my journey here.
Focusing on Java, Databases and Python.
Checking if the software works as expected, also known as Software Testing.
Since I'm a Solutions Architect at Endtest, I get to talk to a lot of customers and I hear their stories.
The typical situation I hear about is that the devs from a company started using all sorts of libraries and 3rd party components in the last years (React, Tailwind, Gatsby, etc).
And they didn't really follow the best practices when it comes to Software Testing (there a reason why the ISTQB certificate exists).
And at some point, they realize that they can't really predict what will break, and the only solution is to have functional automated tests (from the perspective of a real users, in real browsers).
And no one really wants to write code for tests, so using our platform is the easiest way for them to get cross-browser automated tests up and running in a few hours.
But if someone wants to build a career out of writing code for automated tests, they just go for Selenium or Playwright.
Niels is a software engineer, a content creator at Twilio, and a Microsoft MVP. Get in touch with Niels on Twitter @RealSwimburger and follow Niels’ personal blog at swimburger.net.
Dependency hell, annoying in a lot of programming stacks, but especially in NodeJS where you have to choose between being fully patched and secure vs. having a working app :(
Usually we have to accept that we can't patch a handful of vulnerable dependencies.
A collection of articles on subjects in technology, focusing on systems engineering, Cloud Computing, SDLC processes, and more. Support my writing by following me.
i feel it changes job to job. in the past its been management/ownership or customer who don't know what they want. more recently its been supporting a "high priority" application which involves essentially being on call for a period of time. my time is my time
Ingo has developed websites for more than 20 years. A creative web developer focused on creating and improving websites to make the web more accessible, sustainable, and user-friendly.
Graduated in Digital Media M.Sc. now developing the next generation of educational software. Since a while I develop full stack in Javascript using Meteor. Love fitness and Muay Thai after work.
I gave my kids 7 pencils for painting. Each color meant a musical note. Then I played simple chords on the guitar with the colors they picked. Now they got paintings with soundtracks.
I'd say it's gotta be development effort estimation. In an Agile workflow, this would involve planning poker during sprint planning, where each member goes about assigning story points for various tasks. The results can be widely subjective. Here are some reasons in my experience:
Most activities in software development can be solved to a degree, but this one seems so subjective that it almost feels like rolling a dice. Other than just adding extra time to the estimate (which raises the question - how much time?) to account for contingencies, I don't know if there is any strategy for this. Would love to hear other's thoughts. 😃
I worked in a setting where estimates were not essential to business. The founder came up with a system like the following for communicating what work was being done and raising awareness of blockers:
You get very detailed visibility about blockers, direction of tasks, and choice of approach. Tech leads can daily or weekly provide feedback and steer in a different direction if choice of tasks or milestones are not leading to delivered results that will continue to accomplish overall project goals. There is no estimation, but you can look back and see gantt charts or calenders of microtasks.
This is an interesting approach to work! Would love to know more on what was the business domain that you worked in, where estimates were not super essential.
The company was a mixture of custom scientific consulting (writing running long, expensive batch jobs), custom application development, and a long term SaaS product, still in development. The projects that I worked on were for custom application development, and our clients were very flexible about delivery dates.
We had four experienced engineers using this workflow on four solo projects and they each loved it. I especially liked the visuals that Asana produces once you enter the microtasks. We also did a weekly report to summarize our feelings on how the project was going.
I see! I think more companies should adopt this working style. From what I've seen, many of them just want you to keep grinding sprint after sprint, insisting on deadlines even when there isn't any actual pressure from clients to ship a certain feature.
It actually is agnostic about how hard you work. For example, I put a lot of pressure on myself in that system to deliver a lot each day. I just like that it focuses on recording as you go and looking back, rather than spending lots of time on estimation, velocity, etc, and excessive time specifying tasks so that you can estimate them. I like deep requirements gathering though. I just don't like an obsession with estimation. My ideal system is something between the described system and kanban with bi-weekly retros.
The worst job that I ever worked (worked for about 10 different development shops), at a "best employer in healthcare" and "best employer in region", shoved this top down quarterly planning process on all the developer teams and had us spend 15% of our time in backlog grooming, task creation, scrum ceremonies, etc. Mostly well meaning people, just horrible experience for developers, no ability to focus or reach flow, task creation and grooming was a constant nightmare.
After that experience, I shudder whenever I see a tech company that has won "best employer" awards. I also don't trust Glassdoor anymore. I think the only way to learn about these problems is to experience a company first hand for a few weeks.
Also, if I see someone is using Jira, I start to ask very probing questions in interviews to try to understand why they arrived at heavyweight, clumsy jira.
Estimation is definitely a challenge that requires a team effort to get right. I recently shared a guide that I wrote for my own teams, perhaps there are insights that can help? A Guide to Story Point Estimation
Yes, this is one of the problems why I left a company.
this cannot be the reason why would you leave a company. perhaps suggest a process that would work with you or the entire team?
I would shorten this reply to "Agile generally"
Haha, i guess with the planning poker activity you can certainly say it's generally Agile.
But, planning poker or not, estimates are still hard wouldn't you say? 😅
They're a waste of time, so I don't do them
Interesting! Is it because your workplace doesn't really need you to calculate estimates one way or another? Or perhaps they're flexible enough?
I just gave up doing them. Maybe the PO filled them in for me, who knows?
The happiest, most productive teams I've worked on we're ones where we were allowed to self organise, and not estimate
Explain development estimation to sudo technical manager is frustrating.
One extreme way to solve this is to go with #noestimates but it's a highly polemic subject. Some people (mostly managers ?) really love estimating things beforehand.
It's frustrating, but also gratifying with the right mindset: When you spend hours on a problem, and the solution is some stupid typo.
It's literally the worst. Like— I just ruined my day for a typo.
The gratifying part is that these are usually the times where I read a lot of documentation, reach a lot of source code, and generally level up as a developer. Without that appreciation and acknowledgment, it's only frustration. 🥲
Endless meetings about nothing..
Non-technical managers
Reality.
You have a nice idea, and then you checkout what the market offers to help, and it's either legacy solutions or not yet production ready.
Software development is all about making compromises. The smarter you are, the better the compromise is.
Should you go all in on AWS because their CDK supports all their services? This means you have to use something like DynamoDB, which is rather low-level for a DB, or a relational alternative that isn't billed on demand.
Want to use something more modern, like FaunaDB? Well, then good luck finding a IaC framework that supports it and doesn't kill your vibes with YAML.
Reality usually sucks.
When I want to code, and I'm stuck on problems with my tech.
Yesterday I spent an hour solving wrong DNS setting in Ubuntu as I was cut from my remote repository, instead of finishing feature.
Finally solving this, my battery died out without warning.
Then I couldn't continue working in a bus as my ntb charging got stuck on 4%.
Configuring AWS IAM policies lol
Requirement change after completing 90% task 😂
this needs to be higher. my most recent job has been actually pretty good about this though telling the business that they have to deal with it until a new story can be brought in an completed in the next sprint
My frustrations typically stemmed from one of two sources:
Collaboration with Team Members
Because of my style as team lead, I worked hard to manage expectations, and that meant delivering promises on time. I actively worked to keep expectations conservative, but when team members would drop the ball, I was often times left being the one putting in the long hours to make good on the promise.
This ranged from PMs not getting hands on with a MVP scheduled to launch, to Direct Reports quitting because they over promised and under delivered while refusing to be transparent on the actual progress of the work.
Tier 0 Support
Our engineering org doesn't have a dedicated support team, instead engineers are rotated weekly with the responsibility of handling support requests. It's often times a disruptor to planned work, and you can easily find your days being derailed by one support issue. I quickly became frustrated with these duties in part to my past experience. Unlike most engineers in my org, I had a 10 year background in helpdesk support. I don't mind providing support, but I paid my dues handling requests that haven't been triaged. My purpose in support should be to train others, and only get involved when tickets get elevated to the top tier.
Business. It dictates everything. No matter how cool and ambitious your ideas are, if you cannot sell them properly, they’re useless. No matter how sure you are that doing “A” is wrong, if it’s requested by a major customer, just do it silently.
But no matter what, this industry is the best ❤️
Unrealistic expectations. Often those expectations come from the outside, but they can of course also originate from the inside.
Sometimes I think "oh I did this in the past already, this should be easy".
If the task then takes longer than expected it feels very frustrating.
Handling those expectations properly is not always trivial in my opinion.
Checking if the software works as expected, also known as Software Testing.
Since I'm a Solutions Architect at Endtest, I get to talk to a lot of customers and I hear their stories.
The typical situation I hear about is that the devs from a company started using all sorts of libraries and 3rd party components in the last years (React, Tailwind, Gatsby, etc).
And they didn't really follow the best practices when it comes to Software Testing (there a reason why the ISTQB certificate exists).
And at some point, they realize that they can't really predict what will break, and the only solution is to have functional automated tests (from the perspective of a real users, in real browsers).
And no one really wants to write code for tests, so using our platform is the easiest way for them to get cross-browser automated tests up and running in a few hours.
But if someone wants to build a career out of writing code for automated tests, they just go for Selenium or Playwright.
P.S. Even we had cross-browser issues, Safari is unpredictable, wrote a blog post about one of those issues:
What Happens when You Don't Test in Safari
Dependency hell, annoying in a lot of programming stacks, but especially in NodeJS where you have to choose between being fully patched and secure vs. having a working app :(
Usually we have to accept that we can't patch a handful of vulnerable dependencies.
Diva developers with very fragile egos. Unfortunately for me, I have worked with a lot of them.
i feel it changes job to job. in the past its been management/ownership or customer who don't know what they want. more recently its been supporting a "high priority" application which involves essentially being on call for a period of time. my time is my time
Talking about software development with people who are either stupid or stubborn or can't think outside the box of their corporate environment.
Working with colleagues that don't like to share knowledge.
Edit: I don't do right know but I did work with that kind of colleagues and it was awful.
It’s actually the most frustrating part of like everything
The humans.
for me it's dealing with clients who don't know what they want! And of course time estimates...
Interviewing at most companies.
fending my code - don't touch my garbage!
Avoidable waste of effort caused by people without skin in the game.
Communication
2 things.
Naming variables,
Scoping variables,
Off by one errors
The software development.
Imposter syndrome....😰😰
Disagreements. My way is the right way and I don't really want to hear otherwise. 😂
I've dealt with that my fair share, I find it best to ask people "why is this way better"
This is it. :)