This is purely hypothetical and looking for some additional input.
Let's say you have a game that is approaching the release deadline and a developer is stuck on one particular issue. The size of the bug has not been identified, but you feel this may put you off course and the dev needs assistance.
Thanks ahead of time.
It fully depends on the size of the bug. So the first thing that should be done is research into how big the bug is and what it effects.
If you can't extend the deadline: If it is a small bug, then release and patch is possible with some harm to the software reputation. If it is a large bug then either find a way to work around it or fix it.
If you can extend the deadline: Then extend it, if you can add some extra time then do, simple as that. Any time spend polishing helps rise the quality.
I've actually been in a situation similar to the one you described. The software was a joint venture and my partner was having issues with the end part of their code, which obviously we wouldn't be able to release the program like that. Unfortunately, pushing the release date back wasn't an option as we already invested a decent amount of money into advertisement and already had a buzz going around for said release date. In the end we had to hire an on demand freelancer and pay a substantial amount to have him work out the issue as it was beyond both me and my partners scope a day we had already invested too many hours into trying to fix it. This isn't the ideal way to solve the issue, but at times you have to do what is necessary to meet deadlines.
T. Hill - JS Development
40 minutes ago, EnergizerOne said:we had to hire an on demand freelancer
That's one solution I was about to suggest.
Another way to attack the problem is with a 3-way meeting: you (Chris, the project manager) should set up a meeting between the major stakeholders - you, perhaps your direct supervisor if there is one, the developer, and your client (the party providing the funding - if there is one that's separate from your employer), and talk over the problem. Deadline extension, budget extension (extra crunch pay, for instance), feature reduction, or bringing in a "fireman" (as Energizer suggested) are some of the things you can all discuss - as well as other possibilities you might find in a 3-way meeting. Mythical man-month and evil triangle are problems every producer/project manager run up against all the time.
-- Tom Sloper -- sloperama.com
Potential option: Cut the feature that the bug affects and release the feature later when you've fixed the bug.
If you're close to a deadline with a large project, a freelancer may take too long to get familiar with your project to help. It may actually cause even more delays.
Great! These are all really good answers and I can tell its a situation that is all too familiar. I've run up against this with tech projects before, but they were always minimal.
In terms of steps to make sure this doesn't happen again:
- Talk to the developer about escalating issues in a stand-up if they feel stuck or need help. Foster communication in an environment they feel encouraged to achieve the best outcome for the team.
- Look into the estimation process for the bug. Where did the under estimation occur and was the risk of spending extra time attributed for? Advise to relatively size the problem based on similar issues (fibonacci sequence or sizing) if we saw day/hour estimations were not working.
- If it's discovered this issue was assigned to a developer without the proper experience, assign a resource to provide guidance next time.
In terms of preventing the issues, there are several:
1. Allow more time for testing and correction at the end, if you're still adding features close to release you've either got an extremely short schedule or you've done something horribly wrong.
2. Have QA who play the game continuously. QA should be built in with negotiating the job.
3. Have source control and automated builds that are kept around. Coupled with #1 and #2 above, this means you can look back to before a problem started and see where it was introduced, then look for the changes near that time. It also means you can have "safety builds" before milestones that you know are tested and solid but don't have the latest stuff. The costs for these should be built in as basic equipment to do the job.
Your own suggestions about talking earlier is always true, daily meetings should discuss what a developer is doing that day, what they did the day before, and anything they're struggling with. When it appeared the second day in a row it should have been noticed by somebody and escalated. If it is around for another day it should be escalated higher. If it is still a blocker at the end of a week or so everybody on the team ought to be aware and on the lookout.
And for estimation process for bugs, the common metric for that is MTTR, Mean Time To Repair. That's how long it takes before a developer starts looking at a bug until they find a solution. When it's the developer who originally wrote the code, or a developer who is actively maintaining that segment of code, repair time should be hours or even minutes. If a repair is taking days then you've got bigger problems than the specific bug, at that point you likely have systemic issues where large systems are flawed or not understood.
Get more people working on it. Either from the team itself or by getting it outsourced or both.
On 9/1/2018 at 8:32 AM, frob said:1. Allow more time for testing and correction at the end, if you're still adding features close to release you've either got an extremely short schedule or you've done something horribly wrong.
This. If you are fixing stop ship bugs that close to release, this is a management failure, not a developer failure.
Software development creates bugs, plan for it. Failing to plan for this is planning to fail.
You should have a releasable version (RC) *way* before the release date (months). In fact in an ideal world, you don't even consider a release date until you have a releasable version. The work on this feature complete version should be on things that will not break the current version, and if something does break, you should be able to roll back.
If someone agrees on a release date before it is possible to give a release date, they should accept blame when things (inevitably) go wrong.
2 hours ago, waipowrectdeapr1976 said:Get more people working on it.
Look up "Mythical Man-Month." This is almost never a solution when "approaching the release deadline" (as per OP's hypothetical situation).
-- Tom Sloper -- sloperama.com
