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.
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.
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.
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.
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.
Also, make sure to allocate some buffer time for unexpected issues, revisions, or feedback.
~ Bharti Mehta
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.