project-management
Suppose your team writes a software system that is (quite surprisingly) running fine.
One day one of the engineers mistakenly runs some SQL queries that change some of the DB data, then forgets about it.
After some time you discover the corrupted/erroneous data and everyone scratches their heads as to which part of the code caused this and why, to no avail. Meanwhile the project manager insists that we find the part of the code that caused it.
How do you deal with this?
The answer to this question depends heavily on the business goals, as well as the client.
Enterprise:
If you are doing business with an enterprise level client who is well established in the marketplace, they are less flexible and cannot adapt to changes as quickly. Therefore, stability is an absolute requirement in most cases. There are exceptions for research and development and entering new verticals. Faster finishes first in some cases.
These types of clients generally understand that good software takes time to develop, and will work with you to try and meet the goals.
Startups:
For a new startup, the rules are drastically different. As a startup, you need to know right away if the product that you are building will indeed fulfill a need as your marketing research predicted. For a startup, getting a prototype out in the market as fast as possible can garner lots of valuable feedback about the direction the product should go.
It can also establish you as the market leader, helping you gain valuable market share in a new vertical before it becomes saturated with competition.
Since startups are small, flexible, and can rapidly adapt to change, this model works out best for them.
In summary, there are other factors to consider, but the main idea is that every project is different and will have different quality and time to market goals. It's up to executive leadership to determine an effective business strategy that includes thorough analysis of the opportunity costs of choosing one method over another.
Long reply, but hey, I’ve got a summary on the end, so just skip to summary if you can’t be bothered reading the entire thing!
As a developer I had to deal with the situation literally every other project, but it's not until I moved into project management that I learned how to deal with it effectively. For me dealing effectively is about two things: managing expectations and understanding how estimation works.
Start with a premise that it is unethical to provide an estimate, commit to an estimate or give any other indication of estimate accuracy without being able to carry some due diligence first. Other people rely on your professional ability to predict an amount of work required, giving a false indication will hurt them and their business.
But you have to give something, in real life you dragged into an impromptu meeting or a late project and your superior will probably make it clear they expect you to come up with some figure straight away or comment on the estimate they provided. This is where expectations management comes into play.
Explain that it would be wrong of you to give any figure or any indication without understanding the problem and working the numbers out for yourself. Say that their figures might be quite correct, you just don’t know before you went through the estimation exercise yourself. And even though you might have a good picture of what is needed there and when, say that you still need some time to work the numbers out. There is only one estimate they might expect you to give: when you going to be able to provide an estimate. By all means do provide that figure.
As a developer never take responsibility for (or give indication that can be interpreted as acceptance of) other people estimates without being able to review them first. As a project manager it is a totally different matter, because then you actually have some control over the estimation process: the way an estimate is derived and reviewed and you have to rely on other people to get the actual work done and you need to make sure they are committed.
Never even comment on estimates without being able to do the due diligence. This is ethical. A lawyer or a doctor will make it absolutely clear they cannot give any advice unless a client (or patient) plays by their rules and goes through an assessment procedure first. You similarly have a right to satisfy your questions before giving professional opinion.
The second part is about how estimation works. I suggest researching various approaches to doing estimates and how estimation process works, including industries other than software development (manufacturing, financial markets, construction). This will give you idea what can be reasonably expected from you by your boss or client and, strangely, will help making more accurate predictions about the amount of work. It will improve your ability to defend your estimates and you will need to defend the figures every time they are different from the ones provided by an architect or a sales person.
Normally, the way it works, is that your estimate is first scanned for odd looking or relatively large items. Hence be prepared to defend anything with “non-standard” name. Also split larger tasks so that all tasks have same order of magnitude, i.e. if most tasks take 2 days and one single task is 10 days be prepared to get drilled.
Be clear about what is included in each task, its best to split dev and unit testing instead of just having dev and having someone assume that it includes documentation as well. Obviously this way you’ll need to produce a fairly fine grained estimate.
Next the drilling comes. Since it is quite difficult to review a long work breakdown your client or boss is likely to adopt a different strategy: concentrate on a random bit they might know something about and drill down until they manage to discredit the entire estimate or will be satisfied with your answers. The credibility of entire estimate might depend on a random sample! Hence once again, you need time to prepare it carefully, include only relevant bits, exclude any extras or move them to a “nice to haves” section and think through how you going to defend the figures.
Obviously you can be either consistent in your approach, i.e. estimating on the basis of features, number of screens etc or have a mix of approaches, but in any case be prepared to defend why you selected a certain way of estimation. Be also prepared to explain why your figures are different from whoever else’s attempt at predicting the amount of work required.
Learn the obvious signs of weak estimates:
Filled with general run-of-the-mill tasks, copied from template (good estimates are specific to the task at hand).
Coarse grained estimates (i.e. tasks longer than couple of days).
Estimates done on early stage of a project or by someone who might not have actual knowledge of the requirements or work involved.
Estimates compiled by people other than actual doers
Vague estimates (not clear what is included and, equally important, excluded).
Substantial difference in the order of task magnitudes.
Practise in evaluating other people estimates and drilling the figures without actual knowledge of implementation detail. This will help to back your claim for some extra time when pressed with the request to confirm someone else’s estimate when you have no hard evidence.
To summarise:
Do not commit to an awful or any estimate for that matter, before you had an opportunity to do due diligence.
Make it clear on the outset, don’t let anyone assume it is any other way and interpret your silence as a sign of agreement.
Know how various estimation methods work, their practical application and merits, including these outside software development.
Be prepared to defend your estimate.
Learn how to evaluate other people estimates so you don’t have to commit yourself to vastly inaccurate figures.
Best Answer
It is obvious no project manager will invest an infinite amount of time into such a problem. They want to prevent the same situation happening again.
To achieve this goal, even if one cannot find the root cause of such a failure, it is often possible to take some measures to
For example, more detailed logging, more finegrained error handling, or immediate error signaling could help to prevent the same error striking again, or to find the root cause. If your system allows adding database triggers, maybe it is possible to add a trigger which forbids the inconsistency being introduced in the first place.
Think of what the appropriate kind of action might be in your situation, and suggest this to the team; I am sure your project manager will be pleased.
As mentioned by others, it is also a good idea to forbid such a procedure (if you have influence on how the system is operated). No one should be allowed to run undocumented ad-hoc queries which change database content. If there is a need for such a query, make sure there is a policy to store the query together with its execution date, the name of the person who executed it, and the reason why it was used, in a documented place.