8 answers
Jaiden
Student
5
Questions
Asked
713 views
As a software developer how do you balance meeting tight deadlines with maintaining good quality work?
I'm in 10th grade and I'm doing a project on software developers which is a career I'm interested in going into in the IT field.
Login to comment
8 answers
Fred Rosenberger
Data Analyst
481
Answers
St. Louis, MO
Updated
Fred’s Answer
Planning.
This requires buy-in from all levels and groups. Everyone from executives to management to sales to marketing to customer liaisons to development and more all need to agree on realistic deadlines and projects. If the sales team is promising everything to customers by next week, you're screwed no matter what. However, if everyone comes together, discusses upcoming projects, needs, current state, an so on, then a realistic set of expectations can be agreed upon.
We use a SCRUM methodology here. Every feature is broken down into smaller stories. Those are then assigned 'points' which essentially represent how long they will take to finish. Each team has its own cadence - we know team "A" can complete 15 points worth of work in a two week cycle, while team "B" can do 20 points. Then stories are assigned out to each team and then developer, until the team has their correct number of story points.
There are daily check-ins to see how projects are going. If there are blockers preventing a story from moving along, someone steps in and help remove that obstacle.
Each story must also be well defined. What needs to happen? What tests need to pass for this to be considered done? Who needs to sign off that the project is done? and so on.
And finally, test, test, test. While each developer tests their own changes, every change must be tested once it is integrated into the larger system in case there are unknown dependencies. We have entire teams of testers who run specific scenarios, and that is on top of all our automated tests that are constantly being run.
This requires buy-in from all levels and groups. Everyone from executives to management to sales to marketing to customer liaisons to development and more all need to agree on realistic deadlines and projects. If the sales team is promising everything to customers by next week, you're screwed no matter what. However, if everyone comes together, discusses upcoming projects, needs, current state, an so on, then a realistic set of expectations can be agreed upon.
We use a SCRUM methodology here. Every feature is broken down into smaller stories. Those are then assigned 'points' which essentially represent how long they will take to finish. Each team has its own cadence - we know team "A" can complete 15 points worth of work in a two week cycle, while team "B" can do 20 points. Then stories are assigned out to each team and then developer, until the team has their correct number of story points.
There are daily check-ins to see how projects are going. If there are blockers preventing a story from moving along, someone steps in and help remove that obstacle.
Each story must also be well defined. What needs to happen? What tests need to pass for this to be considered done? Who needs to sign off that the project is done? and so on.
And finally, test, test, test. While each developer tests their own changes, every change must be tested once it is integrated into the larger system in case there are unknown dependencies. We have entire teams of testers who run specific scenarios, and that is on top of all our automated tests that are constantly being run.
Robyn Schwartz
Cybersecurity
11
Answers
Chicago, Illinois
Updated
Robyn’s Answer
It is always a balance - but - prioritize those things that deliver to your users and to the business objectives. Often we try to just meet some arbitrary request, but focus on what will deliver the most impact based on your stated goals and metrics - and always focus on the needs of your end users.
Patrick Meyer
Executive - Data Analytics and AI
780
Answers
Naperville, Illinois
Updated
Patrick’s Answer
To strike a balance between meeting strict deadlines and delivering top-notch software, you need to manage your time well and prioritize tasks effectively. Start by breaking your projects into smaller, manageable parts. Then, create a practical schedule that includes time for testing and fixing any issues. From the beginning, keep open lines of communication with all involved parties. Address any complex issues early on and adopt flexible, agile methods. This approach will help you adapt to changes more easily and ensure you deliver a strong, high-quality product on time.
Jyoti Beedi
Share Happiness!
35
Answers
Hyderabad, Telangana, India
Updated
Jyoti’s Answer
-Break down your tasks into smaller and manageable steps, and assign a realistic deadline and duration for each one. Use a calendar, a to-do list, or a project management tool to keep track of your progress and deadlines.
Also, make sure to allocate some buffer time for unexpected issues, revisions, or feedback.
~ Bharti Mehta
Also, make sure to allocate some buffer time for unexpected issues, revisions, or feedback.
~ Bharti Mehta
Dave Wiard
Software Engineer | DevOps Engineer
7
Answers
Updated
Dave’s Answer
We follow a very similar process to what Fred describes...with some differences.
During our planning phase our Product teams determine the features they'd like Engineering to produce. Product creates product requirement documents (PRDs) which Engineering uses to create requests for comment (RFCs). Engineers roughly sketch out how long the project will take to complete and get buy-in from Product, Management, etc. Engineers then create our stories, refine them, point them, and get them into the funnel for future sprints. It's at this point we can give a more concrete estimated delivery date. Our Product team does not determine delivery dates. They ask Engineering when a project can be delivered to set expectations.
In our company each team determines their capacity every sprint based on a formula that accounts for each team member's full capacity (adjusted to account for unknown interruptions, production support, etc.), time off, on-call days (if any), and a few other factors.
This seems like a lot of overhead but the larger the company and product the larger the ecosystem that needs to be involved for a project to be truly successfully delivered.
Quality can be maintained in a number of ways, each of which helps. Your story points need to include time to write unit and integration tests. Static code analyzers can be used to help improve quality with well-defined quality gates that must be met before delivery. Code reviews from your peers can be very valuable in catching potential errors and poorly written code.
During our planning phase our Product teams determine the features they'd like Engineering to produce. Product creates product requirement documents (PRDs) which Engineering uses to create requests for comment (RFCs). Engineers roughly sketch out how long the project will take to complete and get buy-in from Product, Management, etc. Engineers then create our stories, refine them, point them, and get them into the funnel for future sprints. It's at this point we can give a more concrete estimated delivery date. Our Product team does not determine delivery dates. They ask Engineering when a project can be delivered to set expectations.
In our company each team determines their capacity every sprint based on a formula that accounts for each team member's full capacity (adjusted to account for unknown interruptions, production support, etc.), time off, on-call days (if any), and a few other factors.
This seems like a lot of overhead but the larger the company and product the larger the ecosystem that needs to be involved for a project to be truly successfully delivered.
Quality can be maintained in a number of ways, each of which helps. Your story points need to include time to write unit and integration tests. Static code analyzers can be used to help improve quality with well-defined quality gates that must be met before delivery. Code reviews from your peers can be very valuable in catching potential errors and poorly written code.
Lydia Parziale
Project Manager
4
Answers
Fishkill, New York
Updated
Lydia’s Answer
How to eat an elephant - One bite at a time.
Building on Fred's advice:
* Split your tasks into the tiniest possible parts and write them down in a list. Also, make a note of your estimated time to complete each task, keeping in mind the overall deadline. With each task, you'll improve at estimating the time it takes.
* Focus on one task at a time.
* Mark each task as done once you've completed it.
Building on Fred's advice:
* Split your tasks into the tiniest possible parts and write them down in a list. Also, make a note of your estimated time to complete each task, keeping in mind the overall deadline. With each task, you'll improve at estimating the time it takes.
* Focus on one task at a time.
* Mark each task as done once you've completed it.
Vince Dickinson
Director of Engineering
1
Answer
Orlando, Florida
Updated
Vince’s Answer
Prioritization and focus. What is the most important thing to be doing NOW? Take care of that first.
Urgent + Important = do it now
Not urgent but Important = do it next
Urgent but Not Important = do it next
Not urgent and not important = defer or do it when you have time.
Being able to balance lots of things while being able to focus on what's currently your priority is difficult, but really important. Keep track of "all the things" but just focus on the one thing you need to do now.
Be aware that estimation is difficult, and you WILL be wrong. Work will sometimes slip or take longer than you estimate. That's okay, it will happen. The main things are 1) communicate when this is happening, BEFORE it's too late to get help or correct course and 2) learn from it.
Urgent + Important = do it now
Not urgent but Important = do it next
Urgent but Not Important = do it next
Not urgent and not important = defer or do it when you have time.
Being able to balance lots of things while being able to focus on what's currently your priority is difficult, but really important. Keep track of "all the things" but just focus on the one thing you need to do now.
Be aware that estimation is difficult, and you WILL be wrong. Work will sometimes slip or take longer than you estimate. That's okay, it will happen. The main things are 1) communicate when this is happening, BEFORE it's too late to get help or correct course and 2) learn from it.
James Hart
Software Architect
3
Answers
Winchester, England, United Kingdom
Updated
James’s Answer
Hi Jaiden,
You've had some great answers here already. I'd agree with all the points about planning. We also use a scrum methodology, breaking down each story or epic into small, discrete tasks.
The nirvana here is to have teams that are pretty autonomous, do the right things, in the right way, and in the right order. As long as priorities are clear, and frequently revalidated with stakeholders, the idea is that you ship capability when it's ready, without arbitrary deadlines.
However, there are inevitably times where outside pressures, business commitments etc. mean that hard deadlines are applied.
As others are said, this generally comes down to prioritisation.
But there are other tools at your disposal too.. I've found it useful to apply some "design thinking" concepts, around revalidating the user requirement. Often, stepping back and looking at what the user actually needs, and how you can satisfy this, can result in something more achievable/containable.
You've had some great answers here already. I'd agree with all the points about planning. We also use a scrum methodology, breaking down each story or epic into small, discrete tasks.
The nirvana here is to have teams that are pretty autonomous, do the right things, in the right way, and in the right order. As long as priorities are clear, and frequently revalidated with stakeholders, the idea is that you ship capability when it's ready, without arbitrary deadlines.
However, there are inevitably times where outside pressures, business commitments etc. mean that hard deadlines are applied.
As others are said, this generally comes down to prioritisation.
But there are other tools at your disposal too.. I've found it useful to apply some "design thinking" concepts, around revalidating the user requirement. Often, stepping back and looking at what the user actually needs, and how you can satisfy this, can result in something more achievable/containable.