Related
After my last question, I want to understand when an optimization is really worth the time a developer spends on it.
Is it worth spending 4 hours to have queries that are 20% quicker? Yes, no, maybe, yes if...?
Is 'wasting' 7 hours to switch a task to another language to save about 40% of the CPU usage 'worth it'?
My normal iteration for a new project is:
Understand what the customer wants, and what he needs;
Plan the project: what languages and where, database design;
Develop the project;
Test and bug-fix;
Final analysis of the running project and final optimizations;
If the project requires it, a further analysis on the real-life usage of the resources followed by further optimization;
"Write good, maintainable code" is implied.
Obviously, the big 'optimization' part happens at point #2, but often when reviewing the code after the project is over I find some sections that, even if they do their job well, could be improved. This is the rationale for point #5.
To give a concrete example of the last point, a simple example is when I expect 90% of queries to be SELECT and 10% to be INSERT/UPDATE, so I charge a DB table with indexes. But after 6 months, I see that in real-life there are 10% SELECT queries and 90% INSERT/UPDATEs, so the query speed is not optimized. This is the first example that comes to my mind (and obviously this is more a 'patch' to an initial mis-design than an optimization ;).
Please note that I'm a developer, not a business-man - but I like to have a clear conscience by giving my clients the best, where possible.
I mean, I know that if I lose 50 hours to gain 5% of an application's total speed-up, and the application is used by 10 users, then it maybe isn't worth the time... but what about when it is?
When do you think that an optimization is crucial?
What formula do you usually apply, aware that the time spent optimizing (and the final gain) is not always quantifiable on paper?
EDIT: sorry, but i cant accept an answer like 'untill people dont complain about id, optimization is not needed'; It can be a business-view (questionable, imho), but not an developer or (imho too) a good-sense answer. I know, this question is really subjective.
I agree with Cheeso, the performance optimization should be deferred, after some analysis about the real-life usage and load of the project, but a small'n'quick optimization can be done immediatly after the project is over.
Thanks to all ;)
YAGNI. Unless people complain, a lot.
EDIT : I built a library that was slightly slower than the alternatives out there. It was still gaining usage and share because it was nicer to use and more powerful. I continued to invest in features and capability, deferring any work on performance.
At some point, there were enough features and performance bubbled to the top of the list I finally spent some time working on perf improvement, but only after considering the effort for a long time.
I think this is the right way to approach it.
There are (at least) two categories of "efficiency" to mention here:
UI applications (and their dependencies), where the most important measure is the response time to the user.
Batch processing, where the main indicator is total running time.
In the first case, there are well-documented rules about response times. If you care about product quality, you need to keep response times short. The shorter the better, of course, but the breaking points are about:
100 ms for an "immediate" response; animation and other "real-time" activities need to happen at least this fast;
1 second for an "uninterrupted" response. Any more than this and users will be frustrated; you also need to start think about showing a progress screen past this point.
10 seconds for retaining user focus. Any worse than this and your users will be pissed off.
If you're finding that several operations are taking more than 10 seconds, and you can fix the performance problems with a sane amount of effort (I don't think there's a hard limit but personally I'd say definitely anything under 1 man-month and probably anything under 3-4 months), then you should definitely put the effort into fixing it.
Similarly, if you find yourself creeping past that 1-second threshold, you should be trying very hard to make it faster. At a minimum, compare the time it would take to improve the performance of your app with the time it would take to redo every slow screen with progress dialogs and background threads that the user can cancel - because it is your responsibility as a designer to provide that if the app is too slow.
But don't make a decision purely on that basis - the user experience matters too. If it'll take you 1 week to stick in some async progress dialogs and 3 weeks to get the running times under 1 second, I would still go with the latter. IMO, anything under a man-month is justifiable if the problem is application-wide; if it's just one report that's run relatively infrequently, I'd probably let it go.
If your application is real-time - graphics-related for example - then I would classify it the same way as the 10-second mark for non-realtime apps. That is, you need to make every effort possible to speed it up. Flickering is unacceptable in a game or in an image editor. Stutters and glitches are unacceptable in audio processing. Even for something as basic as text input, a 500 ms delay between the key being pressed and the character appearing is completely unacceptable unless you're connected via remote desktop or something. No amount of effort is too much for fixing these kinds of problems.
Now for the second case, which I think is mostly self-evident. If you're doing batch processing then you generally have a scalability concern. As long as the batch is able to run in the time allotted, you don't need to improve it. But if your data is growing, if the batch is supposed to run overnight and you start to see it creeping into the wee hours of the morning and interrupting people's work at 9:15 AM, then clearly you need to work on performance.
Actually, you really can't wait that long; once it fails to complete in the required time, you may already be in big trouble. You have to actively monitor the situation and maintain some sort of safety margin - say a maximum running time of 5 hours out of the available 6 before you start to worry.
So the answer for batch processes is obvious. You have a hard requirement that the bast must finish within a certain time. Therefore, if you are getting close to the edge, performance must be improved, regardless of how difficult/costly it is. The question then becomes what is the most economical means of improving the process?
If it costs significantly less to just throw some more hardware at the problem (and you know for a fact that the problem really does scale with hardware), then don't spend any time optimizing, just buy new hardware. Otherwise, figure out what combination of design optimization and hardware upgrades is going to get you the best ROI. It's almost purely a cost decision at this point.
That's about all I have to say on the subject. Shame on the people who respond to this with "YAGNI". It's your professional responsibility to know or at least find out whether or not you "need it." Assuming that anything is acceptable until customers complain is an abdication of this responsibility.
Simply because your customers don't demand it doesn't mean you don't need to consider it. Your customers don't demand unit tests, either, or even reasonably good/maintainable code, but you provide those things anyway because it is part of your profession. And at the end of the day, your customers will be a lot happier with a smooth, fast product than with any of those other developer-centric things.
Optimization is worth it when it is necessary.
If we have promised the client response times on holiday package searches that are 5 seconds or less and that the system will run on a single Oracle server (of whatever spec) and the searches are taking 30 seconds at peak load, then the optimization is definitely worth it because we're not going to get paid otherwise.
When you are initially developing a system, you (if you are a good developer) are designing things to be efficient without wasting time on premature optimization. If the resulting system isn't fast enough, you optimize. But your question seems to be suggesting that there's some hand-wavey additional optimization that you might do if you feel that it's worth it. That's not a good way to think about it because it implies that you haven't got a firm target in mind for what is acceptable to begin with. You need to discuss it with the stakeholders and set some kind of target before you start worrying about what kind of optimizations you need to do.
Like everyone said in the other questions answers is, when it makes monetary sense to change something then it needs changing. In most cases good enough wins the day. If the customers aren't complaining then it is good enough. If they are complaining then fix it enough so they stop complaining. Agile methodologies will give you some guidance on how to know when enough is enough. Who cares if something is using 40% CPU more CPU than you think it needs to be, if it is working and the customers are happy then it is good enough. Really simple, get it working and maintainable and then wait for complaints that probably will never come.
If what you are worried about was really a problem, NO ONE would ever have started using Java to build mission critical server side applications. Or Python or Erlang or anything else that isn't C for that matter. And if they did that, nothing would get done in a time frame to even acquire that first customer that you are so worried about losing. You will know well in advance that you need to change something well before it becomes a problem.
Good posting everyone.
Have you looked at the unnecessary usage of transactions for simple SELECT(s)? I got burned on that one a few times... I also did some code cleanup and found MANY graphs being returned for maybe 10 records needed.... on and on... sometimes it's not YOUR code per se, but someone cutting corners.... Good luck!
If the client doesn't see a need to do performance optimization, then there's no reason to do it.
Defining a measurable performance requirements SLA with the client (i.e., 95% of queries complete in under 2 seconds) near the beginning of the project lets you know if you're meeting that goal, or if you have more optimization to do. Performance testing at current and estimated future loads gives you the data that you need to see if you're meeting the SLA.
Optimization is rarely worth it before you know what needs to be optimized. Always remember that if I/O is basically idle and CPU is low, you're not getting anything out of the computer. Obviously you don't want the CPU pegged all the time and you don't want to be running out of I/O bandwidth, but realize that trying to have the computer basically idle all day while it performs intense operations is unrealistic.
Wait until you start to reach a predefined threshold (80% utilization is the mark I usually use, others think that's too high/low) and then optimize at that point if necessary. Keep in mind that the best solution may be scaling up or scaling out and not actually optimizing the software.
Use Amdal's law. It shows you which is the overall improvement when optimizing a certain part of a system.
Also: If it ain't broke, don't fix it.
Optimization is worth the time spent on it when you get good speedups for spending little time in optimizing (obviously). To get that, you need tools/techniques that lead you very quickly to the code whose optimization yields the most benefit.
It is common to think that the way to find that code is by measuring the time spent by functions, but to my mind that only provides clues - you still have to play detective. What takes me straight to the code is stackshots. Here is an example of a 40-times speedup, achieved by finding and fixing several problems. Others on SO have reported speedup factors from 7 to 60, achieved with little effort.*
*(7x: Comment 1. 60x: Comment 30.)
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
Being relatively new to the software industry I have come across a question of deadline enforcement:
Back in the idyllic age of academia, the deadline was the end of the semester and the penalty was a well defined 'F' (or local equivalent). Out here in the real world we need to make code our current and future peers can work with, I face the situation where deadline comes, deadline goes, and the project is still not finished.
Now what? On one extreme we could fire everyone involved, on the other we could richly reward everyone involved.
What actions have you seen applied as 'penalty' for missed deadline, and which of these eventually resulted in more-good-code?
What project-management responses caused the project to fail outright,
What responses restored working order and resulted in code that could be maintained afterward?
What responses resulted in more-bad-code?
Deadlines are part of a fundamentally wrong idea about how to do software development. People new to, or outside of, the software development industry do not understand this:
Software is done when it is done, no sooner and no later.
If a developer has a task and a week to do it, and it looks like it will take more than a week, nothing can be done to change that. No matter how much harder the developer works, no matter how many people are added to the task, it will still take as long as it takes (in fact adding people usually makes it take longer).
Instead, read up on the agile development process. Software should be developed iteratively, and each iteration should be based on the results of the previous iteration, not on external requirements imposed.
Edit based on the extensive comments below:
I would never argue that developers cannot be held to some kind of delivery expectation. My point is in response to the specific hypothesis which the asker posed - that the nature of software development in business is somehow analogous to schoolwork, or any other kind of work for that matter. I contend that it absolutely is not. "Deadline" implies much more than a simple delivery date. It is a fixed point by which a fixed amount of work must be completed. Software simply does not work that way. I wrote a few more paragraphs explaining why, but honestly if you don't already believe that, nothing I say is going to convince you.
If you are working on a software project and it is clear you will not be able to reach your deadline, what can you do to rectify that? The answer is well-known by now: practically nothing. You can't add more people. You can't "work faster". It's just not going to get done on time. You tell the stakeholders, everyone adjusts, and keep working (or not). What, then, did the original date mean?
Anyone who claims software development is analogous to bridge-building or homework or that impending deadlines can still be met if the developers would just get their shit together and work their asses off, are deeply confused about their own profession.
Your first reaction should not be what to do in response to the missed deadline, but to analyse why you missed the deadline. The response to missing the deadline would then follow naturally from that as a consequence of the reason.
For instance, if everyone involved didn't do their job, fire them.
But if they did their job, and more, then why was it still missed? Too much other activities done by the same people? Too big a scope for the deadline (ie. unrealistic deadline). Or ... etc.
The top reason for missing a deadline in my experience is that people aren't allowed to work 100% on the project at hand, and thus any estimates you might have, although accurate on their own, aren't really useful at all. That, plus unrealistic estimates and deadlines.
Developers should never be penalized for Management's mistakes.
It's like a parent punishing a child because the parent had a bad day.
Reasoning:
Deadlines are a fact of life. People want to know how long something will take. The best we can do is estimate/guess. It is the role of management to try to figure this magical, never correct guess. When they create a deadline, they need to use the right tools (experience, ASKING FOR HELP FROM DEVELOPERS, lawyers, hr, etc)
However....
The penalty for missing a deadline should not fall back on the workers. It is the management's fault for missing deadlines. They should have said no, should have scaled back the project or should have motivated the workers better.
In a construction crew, if you piss of the workers, you start a fight. In my company, if we miss deadlines, the management gets in trouble. Not the workers. It's the manager's job to control the project and what is done. The workers are only doing what they can. The manager's are in charge of assigning roles and tasks.
I'm not saying the quality of workers isn't a factor, but the management should KNOW that! It doesn't take a genius to know that a project isn't well thought through or nicely controlled. Ask anybody if their manager has any idea what's going on and you'll find the problem.
We stopped missing as many deadlines when the managers realized it was their fault for setting/agreeing to the deadlines.
</rant>
Re: The questions:
1.What actions have you seen applied as 'penalty' for missed deadline, and which of these actually made things 'better'?
Manager has less responsibility. This person does not get promoted or publicly thanked. Most likely this person will be moved to a "less-critical' project.
2.What project-management responses caused the project to fail outright, and what responses restored working order and resulted in code that could be maintained afterward?
feature creep: manager keeps adding more stuff in the list. <- fight this off with a List of tasks ordered by priority. When you add things to the list, compare their priority with the things around it. Make new things harder to be set as "top priority."
too many bugs in the code: Manager need to require tests (atleast critical) and automation. Builds need to be standard and automatic. Real users need to see the code before it is "finished."
un-readable code: Institute peer code reviews. If someone has dirty code, ask someone to "help" them with a project.
If you have the salesman problem, where the salesman promises features that doesn't exist/work: Management needs to step in and explain the problem to that salesman. Also, not giving that salesman public affirmation for a job well done sometimes helps this.
Rather than a penalty, how about realistic estimates and rewarding on-time releases?
Inspired by the comments to my response
Maybe the question should be "How do I make realistic estimates?" For me, I use FogBugz estimation history and completion date plots. These give me data points of how long I estimated a task to take and how long it actually took. This has helped guide me to give realistic release dates in the long-run (it didn't happen overnight). I find estimating timelines to be an interative process: I
design
estimate
develop
find an shortfall in the design & iterate.
Death. Clean and simple.
Depends on whether developers set deadlines on each modification request, or whether these are set for them by management.
In the latter case, unless all your developers are sitting and playing Halo 3 all day, a missed deadline is often an indication of a mistake on the side of management or the team leads. So firing everyone wouldn't solve the problem. It might make sense to introduce better indicators into your software process so you could see that the deadline would be missed long before it happens.
If your developers do give time estimates, then I would be very careful about rewarding and penalizing developers for meeting deadlines or missing them. The result of doing this could be that they would adjust their "fudge factor" in time estimation. They would give themselves too much extra time (to reap the rewards), which messes things up if they are good at estimation. Your goal should be to get them to give good and reliable estimates, not to change the way they work to meet these estimates.
It depends on if the deadline was possible in the first place, maybe it was a fault with the planning and estimation of how long it would have taken. Make sure you know why the deadline was missed before deciding punishment
Oh, man...
First of all, there are external deadlines and internal deadlines, and they should be different.
What happens with an internal deadline is the frequency of activity increases as the deadline approaches, reaches a peak at the deadline, and then falls off as the deadline recedes. So plan the external deadline to follow the internal deadline by a couple weeks at least.
Then, make sure the deadlines are realistic. Partly you do that by involving the developers in setting them, and in deciding what will be accomplished.
Finally, I've mostly been a developer, but once when I took a stab at management, I would never want to take the latest-and-greatest version into a conference or presentation. I would want to take a version that was at least a few weeks old and that I knew where the problems were and that I could be sure would not contain unpleasant surprises.
In his wonderful book about project management - "Deadline" - Tom DeMarco tells us a story, about project manager from a western-world is managing a project in some fictional post-communist eastern European wild country (wild is a really good term, because the citizens are a bit.. uncivilized).
One day PM discovers, that something went wrong, some part of his project dramatically missed the unrealistic schedule. Previous PM established penalty for missing deadline simply by hanging responsible person on a butcher’s hook, but as schedules were unrealistic, one man already missed deadline.
So the story tells us about a day, when western-style PM is presented with a responsible person, and he should send him to be hanged on butcher’s hook. PM, as most people do, is terrified of vision of sentencing someone to cruel death simply because some was never able to finish his project in time. And – by all means – hanging this poor man does not advance the project. Since this is a fiction novel about project management, and not about tortures, our hero cancels the penalty.
But there is some big issue behind this story about hanging someone: if you set a deadline, and establish some kind of penalty for missing this deadline, the day will come, you will probably have to actually punish someone. And will you do it? No matter what the punishment will be: hanging, bonus loss, firing, breaking the deal or some fee – you may have to punish someone. Will this penalty do some good to your project? You have to answer it by yourself.
So: do not establish a penalty for missing the deadline, you will not want to execute…
As others have mentioned, before talking about penalties, start with "how do we determine whether these deadlines are realistic"?
Or as my boss once said, "We'll be happy to work a plan when you give us a plan that works".
I still think that should be on a t-shirt.
Once you've reached the point at which people have blown the deadline, you have to ask yourself (A) what the natural consequences of that are and (B) how you can best complete the task and maintain some kind of movement towards the business objectives (even if you're not running a business).
Explicitly penalizing people for blowing the deadline is unlikely to help unless they believe that they've earned it. This will not happen if the deadline was unrealistic, if there were elements of the team that were the primary points of failure, if there were serious problems with requirements, or if the majority of the team involved believes that the above factors are true.
In one case I was on a team that blew a deadline on a small deliverable by over three months - and the original deliverable due date was three months from start! We misunderstood the requirements, didn't sufficiently talk to the customer, and underestimated the time involved. Management was not at all interested in assigning blame. This was partially because it would have been counterproductive to finishing the deliverable, partially because none of us were "problem employees", and partially because management knew that we were all highly-motivated to fix the problem and satisfy the customer. So we got it done, the customer was as happy as could be expected, and we moved on with our lives, with some valuable lessons on how to avoid the situation in the future.
So far in my career I haven't seen any real penalties for missing a deadline (and I've missed plenty). I imagine it's different for companies building software or games to be sold in stores where the company has made promises to the public.
But in the custom software development realm, it's so hard to accurately estimate how long a project is going to take. And often times this fact is reluctantly accepted by companies everywhere.
No penalty. "Deadlines" and estimating have been and continue to be one of the hardest and most challenging parts of software development.
It is ridiculous to impose penalties on developers for this issue.
While I have never seen any disciplinary action or firings I have seen lots of "mandatory" overtime and peer pressure to work longer hours.
I almost got fired as a manager for telling the team that reported to me NOT to come in on weekends and work late. I know those things are detrimental to the project and to morale.
Generally the "punishment" is in the form of making people feel guilty or anxious, but I am sure there are places that do more "official" things.
The world is full of idiots. Management is no exception.
I think the question it self demonstrates a misunderstanding of the role of management and project management.
There is, unfortunately, a common perception in the minds of many with the word Manager in their title that management means putting the heal to/kicking the butts of lazy workers. It fits with those that believe in Parkinson's Law as well.
It's not. It's about making it possible for works to do their jobs - be it being the communication channel between them and some other part of the organisation, getting them resources, or running interference (moving the furniture out of the way).
To wit, the PM should already know the project/task is going to miss it's deadline. They should be asking questions, and know what's going on. They have the power to either cut tasks or increase/rebalance the resources to get the job done (or say to the sponsor, if you don't give the resources, it ain't getting done on time). And as such, the penalty goes to the PM, whether it is nothing, tongue lashing, demotion, or termination.
Sometimes the delay is unavoidable. This is why we build in contingency time. Sometimes, it's a known risk; and so long as you have a backup plan - you are OK.
As for the responses, you have four parameters: Scope, Time, Money, and Quality
Scope - you can cut to make the deadline.
Time - is fixed. You might be able to get your staff pull a week or two at 60hrs, but your productivity will begin to suffer after that. And it also costs more money if you are paying them fairly.
Money - You can buy pieces from someone else to speed up the process. You could even hire more people, if the work is disjointed enough that you don't have to have a lot of communication with the existing staff - see Brook's Law
Quality - Idealistic fools claim you can never skimp on quality. But you can. You don't have add bugs (one form of anti-quality); but you can put less quality in. Do you code your function so it can handle unlimited length strings, or is 100 characters good enough for this version? Do you make it easy for the next upgrade to bolt on a new module, or do you weld it shut and worry about adding a plug-in module when you do the next version.
Not doing these things aggressively enough (when required) will surely lead you to a failure.
It's certainly not a cut-and-dry answer. Here are some things which I weigh and things I do/encourage in order to make sure things get done on time.
1.) Set priorities properly. Projects will always have various degrees of completion. It's not a binary "done"/"not done" switch. If the highest priority things are done first, it's easier to swallow. Ideally, you should quickly get to the point where it works, but it doesn't do everything we need it to do and it doesn't look pretty. Once there, it can be released if it absolutely needs to.
2.) I've found that the best way to handle it is to make the releases as small as possible. This makes the estimates more accurate. If your boss or "the market" dictates that your estimate is unacceptable, consider assigning more developers to this task if possible. Sometimes a task can't really be divided up easily, or there's only one person familiar with the code. If it's not a high priority just tell the powers that be that it's going to take longer. Setting reasonable goals and managing expectations is key.
3.) As for motivation, rewards, and punishment... there are many doctors who have written entire books on these subjects. In my experience, giving programmers something which is challenging and letting them have some freedom to do it their way is a good start. Listening is something managers need to do well in order to succeed. If the developer is seasoned, you should be able to just explain the problem and let the developer come up with the solution. If their solution isn't as good as what you had in mind, you can suggest it and go from there. Just dictating how to do something, even for new programmers, is seldom effective. Making the developers think about things will help them be able to solve problems on their own. This is related to delegating, as that only works if the developers can do the work on their own.
4.) Reduce turnover by paying people well if they're doing well. It usually costs much more to find good people. It takes time to get familiar with a large code base and the hiring process can also help avoid spending time on people who can't cut the mustard.
5.) Ask (don't demand) if a developer can stay late/work weekends. Only do this when it's something very critical (for example a security flaw which gives user access to data they ought not be able to access; a new law/regulation passes which you must comply; etc.). If they say no, don't hold it against them. It's likely not their fault that things didn't get done; and even if it is, it's reasonable that they made plans for time when they aren't expected to be at work. If they are willing to come in, make sure they know your sincere appreciation. Compensate them well for helping out when they aren't obligated to, buying lunch doesn't cost much and it's a very nice gesture. Don't make a habit of expecting people to work late/weekends unless it's part of their contact/agreement (or if they like doing so).
6.) Understand why things are running behind schedule. Did you promise something which wasn't possible (given the people available, quality expected and time allotted)? Did some other project come up and take up resources and the deadline wasn't adjusted? Was the code just harder to do than expected? Giving time estimates is difficult. You need to plan everything out, have experience and know how long each developer will take for the task. Compensate for unexpected problems which will likely arise and give the programmer a sooner deadline than your boss or the client. It's always OK to be done early. And if you're almost always done early or on time, that one time that you missed your deadline will be more understandable if you have an explanation of some sort.
7.) Remember, it usually boils down to time, quality and money. You can generally pick any two, but the third one will need to balance the equation. So if it needs to be done quickly and on a shoestring budget, you can expect the quality to suffer. If you need it done quickly and of high quality, expect to pay a lot of money, and so on.
8.) I'd say the #1 thing which works for me is listening. If your too busy barking orders then you might not even know about problems with the company. Now just because a developer says "the code sucks, the design is terrible and we need to re-write everything if we want to get anything done in a timely manner" doesn't mean that it'll happen. But if you hear comments like that and explain that we can't afford to do this or we'll get killed in the marketplace, it'd be way too expensive. And ask what can be done to make sure things don't get much/any worse. Ask if there's a way we can clean it up over time. Can we just (re-)write one class and build new stuff based on that? Can we slowly migrate to a new design one feature/segment/module at a time? You understand where they are coming from and vice versa, you can probably solve at least some of the issues. Just remember that compromising works both ways.
9.) Negative re-enforcement seems to result in higher turnover, which is costly. Having a bunch of people who aren't familiar with your code doesn't help deadlines either. Money is one motivator, but I've quit a higher paying job to go to one where I'm happier before, and I know I'm not alone there. Free food when the team does a good job isn't really that expensive. I'm not too keen on group activities since they're either cutting into an employees time, or taking away from work time. It works sometimes, but cutting into an employees personal time so they can hang out with co-workers instead of being with their friends isn't that great of a reward. Having everyone stop working is also expensive... so it just depends on the company size, culture, etc.
Hopefully that helps answer your question. The other answers in this thread are also good suggestions... design plays a big part in how quickly code will be written.
Once a project is late, there is not much 'management' (good, bad, well meaning or malicious) can do, that will not result in the project being even later
... the only exception possibly being the removal/avoidance of exterior distractions.
If you're missing your deadlines, fix your estimates.
Taken from a corporate development standpoint...
If the deadline came from someone other than the person performing the work, review the situation to determine the cause of the overrun. In these cases, it is often related to incomplete requirements, scope creep, poor management, etc. No punishment should be given for missing a deadline that the person never provided in the first place.
If the deadline was provided or agreed upon by the individual performing the work, then that person needs to explain the factors that led to the delay. In addition, this person should be reminded to notify their supervisor, project manager, or other responsible party as soon as they are aware that a deadline may be missed. This information should not come to light after the deadline has passed. If this occurs repeatedly, your company's disciplinary process should be followed. This may involve write-ups, suspensions, or termination.
People tend to take real ownership of deadlines when they are the ones setting them. When deadlines are placed on them without their input, deadlines tend to become meaningless to the person performing the work.
Your question is inherently flawed: it assumes that punishment is the best way to manage people. In general, that people don't respond well to punishment or threats of punishment; it brings out the worst behaviors, make the motivation external, and distracts from internal motivation. Rewards and bribes (threats of reward) are the other side of the same coin, and do no better.
These forces are built in to work for hire, however, so you'll never get the best creative work out of your programmers, but you don't have to make it worse by punishing them when they miss a deadline.
Instead, meditate on the creative process, the chaos of multiple people doing creative work, and what tools are effective in managing chaos.
To manage any chaotic system, do lots of measurement and be ready to change course quickly. In the case of programming:
Take the smallest steps possible. Don't "break the task in to small steps", as you'll waste a lot time planning steps that won't work out like you planned. Chaos, remember?
Pick the smallest steps that deliver the most value.
after a short period, reevaluate your plan based on what you've learned
deliver working software to actual, real customers as soon as possible, so they can tell you what you should really be doing.
You may recognize this as the thinking behind SCRUM.
Flogging
There are two possibilities:
The deadline was missed because someone didn't do their job.
The deadline was unrealistic.
Rather than thinking in terms of penalties, I would suggest doing a post-mortem to determine what went wrong and finding ways to improve the next deadline estimate.
You ask "what should the penalty be...". It would appear you are asking from the perspective of "inside the company".
In real life, the penalties are often swift and severe - loss of business, lawsuits, bad reputation in the industry. These are the REAL penalties imposed by clients who were promised something by a certain date that was not fulfilled.
Internally, you can often do whatever you like. But once you start involving paying clients, then managing those clients becomes a critical part of the overall job.
Penalties such as I described can often be avoided (or lessened) by "on top" communication with the client. If the client wants something added (so-called feature creep), then this should immediately be answered with the impact these changes will have on the project (costs more, delivered later, whatever). The client should be encouraged to triage all such requests against their deadlines and projected costs (i.e. let the client manage feature creep, not you).
If other things change the delivery time, then as soon as you know there will be slippage, you must inform the client. If done early, clients are remarkably willing to work with you. But if you don't say anything until it's too late, they are less likely to forgive... especially should they discover you knew a significant time earlier and didn't tell them.
Cheers,
-Richard
I've seen executives leave a company shortly after some deadlines were missed. This changed everything but didn't necessarily make things better or worse. I've seen some contractual obligations like clawbacks as a way to penalize someone for missing a deadline that I'm not sure how well they work.
When one completely changes what a project is supposed to do midway through the alloted time for the project that tends to cause the initial trajectory to no longer be valid and thus the project will fail because it likely will not meet the initial deadlines within budgets. Replanning the project into short increments of at most a few months is a response that I believe is a logical direction to take a project to get good results as a lot of project may have to accomodate changing requirements which can easily change deadlines, head count or time worked.
What should the penalty be for setting an unrealistically short development timeframe against all of the advice of the developers and their leads?
Coincidentally, this seems to happen almost as often as development teams missing ship dates.
This is not really a programming question, but more of the management question.
Missed deadlines are rarely developer's fault. As a developer you should try your best to do as good work as you can, but in the end everyone is capable of only so much. If developers put in honest effort and despite this the deadline was missed, it means that the deadline was unrealistic to begin with.
Dealing with deadlines is responsibility of managers. There are different approaches but none of them include "penalizing" developers for doing their job. An important thing to understand here is the so-called project management triangle. What it means is that software project can be good (i.e. meeting requirements, good quality), fast (meeting deadlines) and cheap (headcounts, tools). The trouble is that only 2 out of these 3 properties can be chosen.
So if management want something good and fast - it is not going to be cheap.
If management want something good and cheap - it won't be fast.
And finally if management want cheap and fast - guess what, it won't be any good.
So the correct response to missed deadline depends on the chosen scenario. Good and fast requires adding some extra help, better tools, investment in above-average developers and more.
Good and cheap by definition assumes that deadlines are going to be missed (Blizzard, makers of World Of Warcraft are good example of this approach)
And finally cheap and fast usually means cutting features and releasing with bugs.
The main goal of project management is to plan how an application is going to be built, in time. You should not start your project development if you don't have a schedule showing what you're going to be doing every single day the project will last.
This way, you can detect that you're going to be late, as long as you follow the project's evolution on a regular (weekly if not daily) basis. And the earlier you know it, the sooner you can act accordingly.
You usually have two options :
Catch up (by hiring additionnal workers, working more, or removing features).
Tell your customer that something went wrong (even better : what went wrong) and you're gonna need more time.
For the second option, I'm not meaning there won't ever be penalties. But from my personal experience, as long as the customer is informed in advance and offered solutions (preferably three : give more money for additional workers/remove features to save some time/accept the project being late), they'll be open to negociation. Which is always better than conflicts :)
Perhaps the better question is if deadlines are meaningful in the face of inaccurate estimates? Businesses do a lousy job of estimating software--that is a fact. Both management and developers play a part in this and neither one seems willing to own-up to their responsibility in this problem.
But to answer your specific questions:
1.What actions have you seen applied as 'penalty' for missed deadline, and
which of these eventually resulted in
more-good-code?
The 'penalty' I've seen for missed deadlines for managers and developers range from nothing, to promotion, to simple transfer. The most severe penalties I've personally witnessed was a manager "transferred" to a less important project and for the business-unit to lose a financial bonus.
The only time I have ever seen someone fired over a missed deadline was when the employee was already going to be fired--the deadline gave the business a legal reason to fire the employee.
2.What project-management responses caused the project to fail outright?
This is a whole separate discussion on its own... but there is some inherent bias in this question--project management is at fault.
The three top things I have personally seen PM's do that sabotage a project are (in order of severity):
Ignore data/recommendations/warnings from their technical staff.
Ask for estimates early in the development process. This results in estimates with an error-bar of 10x (it'll take one month, give or take ten months).
Reject/modify/demand software estimates so that they fit an arbitrary budget and schedule. This is not to say Developers should ignore business demands--but rather the business demands need to be set equally by Developers and non-Developers.
3.What responses restored working order and resulted in code that could
be maintained afterward?
I have yet to see a functional software development organization. So the fix is usually a lot of blood, sweat, and tears from a couple of heroic developers working with a highly-capable PM who knows how to defend against politics within the company (i.e. deflect BS from their staff).
4.What responses resulted in more-bad-code?
Yelling. Cursing. Insults. (Sadly, this still happens in some workplaces)
More "project management"--either by way of people, meetings, status reports.
Getting software estimates earlier in the process so "we can plan better." Estimates need to come later when your staff has more data and a better understanding of the problem.
Coddling the developers (it's not your fault, the manager screwed up).
Coddling the project managers (it's not your fault, the developers screwed up).
Adding additional, unqualified staff to the project.
I got fired for missing a deadline, I was 98% finished with the product, external forces and deadlines that are that firm don't allow software to be developed properly. Even I can admit I wrote some poor code under the circumstances, but I also wrote some good maintainable code as well. No consideration was given for feature creep, infact no technical specifications were detailed upfront and adaptation of functionality was required as limited and buggy versions of the software became available for managements review. I could have communicated better, but when I did communicate it was emphasized that deadlines are non-negotiable.
Two obvious questions come to mind when a deadline was missed:
Was the deadline feasible?
Did external factors impact performance?
Obviously, if someone presents you with a deadline that doesn't make sense then there shouldn't be any penalty for missing the deadline. Also, if someone misses a deadline because they were called up for jury duty that also shouldn't be held against them as well.
In the event those questions don't apply then the next thing to do is to figure out what went wrong. If you based your estimate for how long something would take, and thus the deadline, on the developers estimation of how long it would take them to write the code then perhaps they were too optimistic in their responses.
I know this questions seems extremely open ended. I will try to narrow scope.
I have been struggling for some time as to include or exclude real time user performance stats in an application gui.
Does anyone have any info on the harm vs gain in including these stats in an app?
i.e. number of emails answered, number of customer calls taken, average time per customer etc.
The users are begging for more info on their stats, as it is how they are rated. However there is concern that given access to see their performance real time or near real time it will negatively affect their work.
I can kind of equate it to being measured on how many lines of code I churned out in one day. Would this help me to be more productive or just teach me write code as fast as possible and most likely make a lot of mistakes.
In my application I can think of these scenario's
i.e. BAD: "I see I have spent 10 minutes on this issue already, I need to finish this up asap"
vs
i.e. GOOD: "I was able to help that customer quickly, My productivity is good today"
I think there may indeed be a phenomenon one could call “The Facebook Effect,” where by merely presenting a metric (e.g., number of “friends,” minutes per call), you imply that it’s important. However, I don’t think that’s an issue here because it’s clear that users already regard these metrics as very important, otherwise they wouldn’t be begging you for them.
I believe there is a wealth of psychology research showing that adding faster feedback on a metric will very likely improve user performance on that metric. Furthermore, it is emotionally stressful for people to be evaluated on a metric that they cannot track well themselves, which appears to be the case now.
I say show the metrics real time. Management obviously wants high performance on them otherwise they wouldn’t be rating the users on it. User want it, and it’ll reduce their job stress. Sounds like a win-win to me.
Of course, the customers probably lose out, so there’s a bit of an ethical dilemma. However, if these metrics are problem, then the problem lies in corporate policy, not in the user interface. By showing the metrics to the user, you will highlight whatever shortcomings this policy has to the managers. Maybe management will get a clue.
If it’s part of your role, you could propose measurements of customer satisfaction (e.g., after-call automated survey, random follow-up surveys by a human) so that managers can at least track the impacts of their policy. Assuming they care (how are they evaluated?).
KISS principle, is this information pertinent to what the users will be doing?
If no, then no do not add it. One thing that I like on web apps is the time it takes for a page to load after updating / submitting something (basically posting back data).
That way I / a user can tell if there is an issue with data going to the database or a caching issue.
The problem with displaying say for instance calls to customers is your average times may not be as accurate as you'd hope. You may have a customer who likes to chat, or is having technical issues that are irrelevant to your business but yet get reflected in your apps.
This data shouldn't be trusted because of these types of things. Another thing is, if you start displaying call times you end up having employee competitions to see who can get off the phone first..that's when you start hurting yourself more..bad customer service.
A few big names used to rate employees based on things like call volume, average time on the call, etc. Remember when Dell tried to outsource all their technical calls to India? Customers here in the US were frustrated and calls were either too long (not understanding) or too short (Customers did not want to deal with it). Well the big shooters thought hey call times are pretty inline with what we had forecasted and our costs are going down. But it hit rock bottom as time went on...
Your application is useful as a tool to convey this information, and you should definitely include it if users are clamoring for more visibility and transparency into the data it collects. A user's response to the information, however, will largely depend on what the organizational culture already does with it.
For example, does management aggressively encourage users to keep calls short and deal with as many customers as possible, and fire those who don't meet quotas? If so, that's going to provoke an equally strong reaction from users to keep their calls short when they discover they've been a bit on the longer side. ("Uh-oh, I'm getting to the 2-minute mark. I'd better hang up and fake a disconnection to avoid getting my average call length too high.")
Conversely, if management simply encourages everyone to do a good job and provide excellent customer service, this information can be synthesized by users in the overall context of this work. ("I've spent a lot of time on this customer -- I should see if I can wrap things up shortly, or escalate him if I can't fix this problem.")
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
So I manage projects for an internal development team. That is All our clients are internal to the business.
I am trying to figure out he best way to collate requests and allocate the resources that we have. (unfortunately the business dosn't have an endless budget for developers, but they still want everything done)
I would like to do some sort of backlog and feature planning but how do i do that across multiple clients and multiple products.
And last but not least the emergency requests. Someone says we need this tomorrow, how do you deal with that. I seem to have one every week, which we can do we just never eat into the feature backlog.
Depending on how cooperative the sub-projects are, you can either manage the features and the backlog in a single order of priority (thus, the most important task to the organization comes first - transparent, but the decision makers must be able to converge on the priorities), or splitting the time / team and then managing the priorities with each client within the time or resource slice allocated to the client. Organization-wide this is not the most efficient way, but once this hard decision is taken you are free to manage each project independently.
Exactly the same goes with the emergency requests. An enlightened organization would be able to prioritize this across different divisions - i.e. an urgent security fix ranks any feature regardless of ownership, but more likely the "emergency" stuff will either be done as a part of the "slice" allocated to the client, or according to how much pressure the "emergency requester" can produce.
It looks like you have a lot of change going on. If you are not yet using an agile process, such as XP, you should try - at least the managing requirements/features and delivering often parts. Delivering changes often can also relieve some of the pressure on you as the progress from task to task becomes more visible.
I agree with MaxVT that you may want to look at something like XP, as, even if you are delivering programs that have limited functionality, they are still getting something that can help.
You may also want to start setting expectations of those making the demands, based on what you already have in the backlog list.
This would mean that you should go through your backlog, with the developers, and determine what tasks need to be done, and assign time to each task. This will give a way to state that for project A there is x hours, so you can tell someone when you may be able to get to it.
By being agile you can look at what features must be implemented for the app to be useful, and then get the application to that point. You can then track features to be added, in some priority fashion, so you implement the most important features first, then as you have time you add more functionality to it.
Knowing what must be done for each feature and how much time it should take will better help you with the project management, and for you to generate your reports for those above you.
When you have limited resources and emergencies are eating up most of your time, one of the best things you can do (aside from dealing with the emergency), is to make the effect visible so that you have data for higher-level discussions with stakeholders (e.g., "was this really an emergency? what could have been done to keep this from having become an emergency?", etc.)
In thinking about a prioritized backlog, you're on the right track, in part because the discussion over priorities is one that you can (or might be able to) push back on your internal customers.
For emergency "skip the queue!" work, one thing I've seen work is to use "red cards", either skip those right to the head of the queue, or rate limit them to only have one in progress at at time, so that you can be making progress with non-emergency work with the rest of the team that's not working on the emergency.
A key part of whatever approach you take is to gather enough data to support having data-driven discussion with your customers. In the simplest form, have the team give rough estimates for the size of each item in the backlog, so that you can both track how much work you're getting done each week, and how much work is in the backlog. After a few weeks, you'll have supporting data to take to your boss to support a "We're spending 90% of our time dealing with emergencies. What are we going to do about that?" discussion.
its all in the scheduling and resources (more about resources in a moment). there is also an aspect of change control to your problem.
scheduling
i use google spreadsheets because its simple, everyone is comfortable/familar with it, and everyone can access it simaltanious (its free too!).
if you look at the picture below, you can see there is an 'Assigned To' column - thats the inital of the programmer. you would have multiple schedules like this, one for each project.
in the second image, you can see some summaries. including how many hours total the programmer has been assigned on the project. this lets you plan when they will be available to work on another project.
the rest of the article is here -> Project Schedules with Google Spreadsheets
resources
you may have your project schedules in shape but what do you do if all your in-house programmers are busy on projects already? you are effectively out of resources. this is where outsourced contractors can help. if you dont have budget for this, then people simply have to wait until programmers come off the projets they are assigned to (e.g. "sorry boss, but greg wont finish his current project for another 2 weeks. if you want to pull him off that project, we can, but then that project will deliver late" <- good luck with that :)
bug management & change control
there are approaches for bug management and change control too, but i dont want to get into them too deep other then to say slot in 2-3 hours a week into each programmers outlook calender for debugging. with features that dribble in, gather together 5-10 and document them before you hand them to a programmer to code (make a package out of them, like v1.1).
There are two sides to this, the practical and the political. The first is straight forward, the second is a mess.
Some of this is horrible management/marketing bollocks sounding so I apologies in advance but it is good.
To sort out prioritisation on a practical level I start with a high level assessment of effort and benefit, each on a scale of 1 to 10 and then plot them on a matrix (effort on the X axis, benefit on the Y axis). The business have to assess benefit (and justify it), the IT team and the business jointly assess effort (the business team don't get to mess with IT's estimates but they may need to add in their own time).
Broadly speaking anything in the high effort low benefit quadrant (bottom right) gets killed immediately - to much for too little. Anything in the high effort, high benefit (top right) gets classed as a major project and needs to be investigated further as these are typically where you'll find one or other assessment is out. Anything high benefit low effort (top left) is a quick win and jumps to the top of the list. Finally things in the low effort low benefit (bottom left) are question marks. As with major projects these need to be examined further though in this case you're trying to turn them into either a quick win (you may be able to modify the scope to increase the benefit or decrease the effort) or to show that they're actually going to be more work than people think and should be killed.
But generally speaking the closer to the top left corner (low effort, high benefit) things are, the sooner they should get done.
One critical thing - all the information and the whole matrix is public - if there are disagreements the developer is just administering the process, not adjudicating on it. Publish the latest matrix (and resulting schedule) on a weekly basis and have regular calls between all interested parties to ensure that everyone agrees with it.
Which comes to the political side - where you know that something is a waste of time but it's being asked for by someone very important. Ideally this is where your manager earns his keep but generally if you have a transparent process (that is the benefit/effort scores and the matrix are all public), the guy pushing for something that's not worthwhile will either (a) struggle because everyone else pushes back pointing out that his change is trash and shouldn't happen at all let alone take priority, or (b) have enough clout that it doesn't matter but at least you're covered as the other people who would pressure you understand that.
And the transparent process is how you deal with the last minute requests. If everyone who has requests in knows where they are in the queue, people dropping things in at no notice becomes harder for others as they're not just messing with the developers, they're messing with their peers and pushing back their projects.
Generally speaking those who do it will either have enough clout that you couldn't stop it anyway or irritate the other people asking for changes enough that they'll be forced to minimise their bad behavior.
One interesting subset of these last minute issues is time dependent projects, that is ones where the benefit is greater if it is done this week than if it waits six months. An example might be where there's a three month window before a legislative tax change comes in and the project would allow the company to take advantage of that.
In that case the project gets assessed on it's maximum feasible benefit then reassessed when it's placed in the schedule - so if with it's maximum benefit it happens tomorrow then great, but if even with it's maximum benefit it can't happen for two months you have to drop the benefit based on what it would deliver at that point in time and reassess (normally this kills it).
So in short:
Good benefit / effort assessment allows you to pick those which will positively impact the business most
Transparent well defined process which the developer administers rather than adjudicates on.
If it was development for external clients, I would say that you need to charge a little more for "Emergency" requests. However, short of changing your organisation's internal charging model (and ticking of your F&A branch), there's not much you can do on that end.
You have a good case for bringing in one more developer, but of course $$$'s always tight.
Frankly, I love FogBUGZ (and to be fair there are other case/incident trackers out there, by FB is my favourite). I can see quickly what I have in the queue and their priority (regardless of project/client).
The other pieces of advice I'd give you are these:
Advertise the size of your work queue. There may be some internal secrecy required, but perhaps you can post on a wall/website all the project s you have on the go.
Get organizational priorities for the existing projects. Someone in your organisation must have an idea of what is needed when, and what is most important - be it the manager, CEO or BOD.
.
Everything else goes at the end of the queue.
.
If Bob has an emergency request and you are working on Jim's and Mary's requests; make Bob go through Mary and Jim first to get permission to leap frog them in the queue (or if necessary go above their heads).
Or, Bob can choose to push one or more of his projects that are higher in the queue down and replace it with his Emergency request. Either way, it imparts an inherent extra cost on the the emergency request. Things that aren't really emergencies tend not to be called that any more. It kind of like that ER line "Mark every lab request as STAT even if you don't need it right away"
e.g.,
[Jim1] <- [Mary1] <- [Bob1] <- [Jim2] <- [Jim3]
[Jim1] <- [Mary1] <- [Bob1] <- [Jim2] <- [Jim3] <- [Bob2]
|-------------swap-------------|
[Jim1] <- [Mary1] <- [Bob2] <- [Jim2] <- [Jim3] <- [Bob1]
The answer for your internal (and external) clients is almost always yes (sometimes no for technical reasons). However, that "yes" is always followed by a "but".
You - Yes bob, we can work on that project for you, but we can't start until
around X months from now.
bob - That's not good enough
You - OK, you have a couple options. If you want to shift some of your other
requests around we can push it to the start of your queue, that would get it
started in Y months.
Bob - Still not good enough
You - Well, you can negotiate with Jim and Mary to leapfrog their projects.
Bob - They won't budge
You - Then go over their heads, and talk to Mr. Dithers`
[some time later]
You - Yes Mr. Dithers, we can work on Jim's requests. You are aware that will
push back Jim and Mary's requests.
Mr. Dithers - Yup.
You - Aye-Aye Capt'n.
[some time later]
Jim - Why the $%#$%#$5 aren't you working on my request
You - Talk to Mr. Dithers
And remember, if EVERYTHING is a top priority, NOTHING is top priority.
Edit:
Further to FogBUGZ (since you asked), it's more than just issue/bug tracking. You have features requests, inquiries and schedule items too (you might have to upgrade to the latest version to take advantage of those). Use it to its fullest.
Make sure that you are including your feature requests in FB. The more you dump into FB the better the picture it will give you. Remember to use the filters and the grid views.
FB's got a wiki. Post your groups high level work list there for all to see.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
You must have heard the archetypical story of a failing/failed project:
A team of inexperienced programmers work 24x7
Bugs are fixed only to introduce new bugs
Customer is screaming that he could not even do the basic stuff (Saving/Querying) etc.
Programmers used to having the spec handed down struggle to improvise
No automated unit tests aggravate the situation
Architecture document that looked nice on paper was not followed in practice
Third party components used become bottlenecks not having been tested for fitness in the first place
Milestone after milestone missed
The team is not able to come up with a delivery date as nobody agrees as to the quantum of work actually needs to be done
No technical leadership / or a Cowboy Coder that can take on the technical issues
Now, If you were to be brought in as #10 what would be your first steps?
Update: First of all: Thanks to you all for chipping in. Well... I'm being brought in as #10. I was the original Architect anchoring the solution when we made the proposal to the client. Then, unfortunately, I couldn't take on the delivery responsibilities as I was assigned somewhere else. :)
Let's say it's a webification of an existing desktop application. I'm now being brought in as #10. Running away, sadly, is not an option. I'm sure this can still be reversed by following agile best practices and just wanted to tap the community for ideas.
The larger question perhaps is this: If the development team does not have specs but only the (baselined) code for a running application, the original solution called for looking at the code and extracting business rules on the fly. Now, the inexperienced programmers are reluctant to look at VB 6.0 code and want documents! So how do you fight this if you were to instate Agile processes?
Vyas, I feel like I could have written this question. My previous job involved resurrecting a KVM project that had failed after a year's development. Specs were in the form of a user manual and developers' experience with similar products. I ended up teaching C to 3 assembly programmers and re-architecting from scratch. We brought the product successfully to market in 4 months. (Then I resigned. Go figure.)
Some of the things I'd do again, particularly with an inexperienced team:
1. A team of inexperienced programmers work 24x7
10. No technical leadership / or a Cowboy Coder that can take on the technical issues
Give them a (short!) break from the project to "recharge." Maybe a day, maybe an afternoon, or maybe a long lunch on you. It will mark the end of the "old" project and the beginning of success.
Get their agreement to work their butts off when they return, and promise that you will be their go-to guy, cheerleader, and flak jacket. You, collectively, are a team, and your job is to forge their path, eliminate distractions, and lead them.
Plan an immediate success, no matter how small, and maintain a "can-do" attitude.
8. Milestone after milestone missed
9. The team is not able to come up with a delivery date as nobody agrees as to the quantum of work actually needs to be done
3. Customer is screaming that he could not even do the basic stuff (Saving/Querying) etc.
Take small bites! Break each piece down as far as possible, then deal with the small components. You'll identify "gotchas" early and be better able to scope the whole project.
Define your interfaces. Anytime you can isolate a chunk, do it. This allows parallel development, because you've already decided on parameters, preconditions, assumptions, what happens inside, and return values. You can stub it out, and build other modules and tests independently.
Prioritize. Focus on the defects and issues that affect the customer first. New features come last. If necessary, defer features rather than delivering buggy code.
Assign responsibilities. Volunteers are preferred, each in his/her area of expertise, but one person must be accountable for each task.
Track defects, and record everything that will help you reproduce, locate, and fix them. Document any that remain at delivery time, so the customer won't be surprised.
4. Programmers used to having the spec handed down struggle to improvise
6. Architecture document that looked nice on paper was not followed in practice
You will create the spec details as you go, each piece just before it's needed. It needn't be pretty, complete, or even written, as long as everyone understands the current task and you've got the big picture.
Discuss the implementation, one piece at a time, when the developer is ready to code it. Write the skeleton yourself if necessary, and let the team fill in the "guts." You want to keep them focused on each task, without "improvising."
Be available to answer questions as they arise. Your primary goal is to keep the team productive.
2. Bugs are fixed only to introduce new bugs
5. No automated unit tests aggr[a]vate the situation
Plan and start unit testing ASAP. If possible, enlist resources outside the team.
Fix small problems before they grow larger--or get hidden. Confidence in each small piece builds confidence in the whole.
7. Third party components used become bottlenecks not having been tested for fitness in the first place
Brainstorm solutions when you're not coding. Don't let them stop your progress if at all possible. Can you encapsulate or code around them? Replace them?
General suggestions:
Stay ahead of the team. Anticipate and try to solve problems before your team hits them. Gather any necessary information before it's needed.
Communicate constantly. Make it clear that you want no surprises, and solicit concerns, questions, status, roadblocks, etc throughout each day. Encourage collaboration and share "discoveries" across the team.
Celebrate every success. Compliment a clever solution, bring donuts when a problem is solved, demonstrate a new working feature ... anything that shows the team you appreciate them.
Get each task done, then move ahead. Don't waste time tweaking, enhancing, or reworking anything that isn't a direct barrier to success.
Keep your promises to the team, the customer, and your management.
Good luck -- please keep us posted!
Run away or find a new job. This is a death march and they need a scape goat.
Often, the death march will involve
desperate attempts to right the course
of the project by asking team members
to work especially grueling hours,
weekends, or by attempting to "throw
(enough) bodies at the problem" with
varying results, often causing
burnout.
Freeze releases, and start fixing issues with the program.... deal with the customer complaints by priority (the business side of the company can prioritize) and get the program running. Once you get the biggest issues out of the way, start cleaning up the code. Assign tasks to other developers, and start enforcing coding practices on all new code.
If you can do whatever you want, then look at what the real issues are and deal with them. If that means putting together a new team to develop the software all over from scratch, so be it. But you should try to at least fix the major bugs. Don't bother introducing new features, they only compound the problem, and a program that doesn't work and the problems aren't dealt with lose you clients.
Number 10 is obviously the worst problem, or at least the root of all others. Find someone with some creativity and ability to deliver a project, and give them free reign to do anything - including start over.
I hope you are getting paid really well. In any case, my plan would be something like these steps in the following order:
0) Stop adding features or functions across the team. Allow bugs to be addressed while the following steps are taken up to step 5, then stop bug fixing & resume feature development:
1) Apply what I call the Inverse Staffing Law: Weaker team members slow down the better and faster ones and generally a late software project needs people removed, not added. So, you need to assess the quality of the team members as individual contributors. Eliminate weaker staff from the team because presumably there are some. This is best done by reviewing their code and examining their bug fixes and figure out who is making the code worse vs. better and chop them for the team. This is not a time to mentor, you are going to need the best folks to have a change of "fixing" the situation in a optimal period of time. If you can't fire them or reassign them, have them getting coffee or something for everyone else left.
2) Assess the code itself. Identify areas of the code that are not constructed well and/or not well abstracted. If a area code is not constructed well and/or is obviously brittle at it what it is supposed to do, target it for a re-write. This feels painful at this point, but it will save you time in the long run. Recurring bugs and/or history of fixes will help identify the code that can't be salvaged. If a code area or module is fundamentally constructed well, but not abstracted well at the interface level, it should be suitable for re-factoring. This will save significant time and is useful code. Keep a list of the re-write areas, the re-factor areas, and the suitable areas.
3) Define a new reasonable architecture that you believe will result in a robust and complete solution to where you want to eventually be in features and functions. The architecture might not be optimal as starting clean, but in effect match up what you have with where you would like to be.
4) Work with the stake holders to decide what will make an acceptable first release attempting to table as many features as possible for "later" releases. Maybe you can't cut anything, but if you can, now is the time to do it.
5) Stop the background bug fixing efforts and assign the defined work out to the (remaining) team to estimate out a reasonable new implementation plan of the rest of the functionality. They need to own the schedule. Roll up the schedule and be fairly conservative. Now you have a reasonable prediction of when you could actually have something workable and robust.
6) Implement the remaining features and then harden up the release by tackling the remaining bugs. I am assuming all the normal good software development practices are observed here like source control, unit tests, etc.
7) Remove as many barriers as possible to keep the team cranking out stuff as fast possible.
8) Monitor for issues, and assist by getting your hands dirty where ever your can. Offer to take on the nastier issues to the extent you can help and still keep all members of the team as productive.
Good Luck!
This isn't about technical leadership any more, it's now about project management.
You as the technical lead will just be shifting deckchairs on the Titanic. So here's what I would do if I was the de-facto project manager.
1) Identify the project sponsors and stakeholders - both the official ones and the real ones.
2) Go to them and request that the project "goes dark" for a week.
3) If they don't agree, walk away from this project.
4) If they do agree, call a project time-out for a week - everything stops.
5) Spend that whole week talking to the important people on the project to identify the real project state.
6) Whilst engaged in those discussions, start formulating a project recovery plan, emphasising possible trade-offs between scope, schedule, budget, and personnel.
7) At the end of the week, decide which (if any) of your possible project scenarios are feasible.
8) Take the best of these scenarios back to the project sponsors and stakeholders, and start negotiating.
9) When a way forward is agreed, reboot the project and pray - possibly not in that order.
Common sense has already been pointed out to you by Maxim (Quit the death march). But if for reasons unknown you wish to persist, let me regale you with my experience in a similar situation - perhaps it might come useful.
It was my first job in a sleepy old town where good computer jobs where hard to come by and I despertely needed one immediately after college. I was hired coz the management thought i was enthusiastic enough and might be better than nothing (I offered to bring in my own comp to save them a cost of giving me a PC and offered to work for the experience alone)
The project had been abandoned by its creators due to the death march situation and had gone away after deleting all the comments in the code and performing other obfuscations. Nobody knew win32 / MFC stuff either.
I simply started studying the code on good old paper and pencil (lots of rubbing and corrections) until within 20 days time i knew the entire code including the variables by heart and what and where things where happening.
Armed with this knowledge i was able to make a critical piece working which had eluded everyone before. Of-course this was nothing but a drop in the ocean but it enabled the management to buy the clients confidence "smart fellow - got him with great difficulty - already got x working - u will have ur stuff working within y time".
Once the client was convinced and we where able to buy some time, some pressure was taken away. This got some hope back into the team and we started to hammer away for good. 6 months later i got promoted to project lead and 9 months later we had our fix shipment (lots of progress demos and a visibly more and more satisfied client in between).
As you can see, the elements of success are not directly duplicatable. But i would summarize that you need to breath some hope into the project first - show some progress and win confidence - that of your peers, management and the client. Once that is in place the technical stuff should be corrected too - there is nothing to replace this part of the equation.
If that does not seem likely, all that hard work (oh yes - lots and lots of work like you never imagined - why do you think its called a death march) would be a waste and you had better quit even before you start.
I had no choice and i was hot blooded and desperately need a job. The technical details where something icould work magic upon, and everthing just clicked into place. I really earned a lot of good will and self respect with that piece of work but in the long run its just a story i can narrate with great aplomb and nothing more except for those few in the know.
Things might be different for you but its for you to decide.
Good luck
Make sure you aren't the scapegoat
Cut scope creep
Trim functionality "requirements"
Implement a faster dev cycle (maybe Agile/Scrum/XP/whatever)
If you can, run away.
If not, you need to stop all activities that make the project unstable - including coding and fixing defects.
Assess where you are
Break up the requirements into much smaller "milestones"
Read some practical books (Mcconnell's "Software Project Survival Guide" comes to mind.
Identify all the problems and risks. Communicate all those to all involved.
Work on each piece one at a time.
Celebrate improvements and milestones as they are reached.
Good luck. Your scenario sounds pretty bad. It may not be salvageable - and things have to change to get better.
If you really had to get it on track (if bailing isn't an option)
Start off by accepting that it's a failure in management. You might then want to go on to implementing a strict but light process.
I'd suggest some form of Agile, since it's the easiest to successfully implement without a GURU, but you have to be VERY strict about it, including Pairing, Ruthless Refactoring, Reviews, Spiking functionality, Visibility, TDD, one-week cycles, 8-hour workdays (Yes, longer than 8 tends to harm productivity more than help, as you seem to have noticed)...
Don't be cutting anything out either. Parts of Agile rely on other parts--without the pairing, refactoring and testing you cannot eliminate upfront design (one of the biggest agile failures).
Don't forget about the management side of it. One week iterations to start (demo EVERY week). Constant adaptation. Very short stand-ups every day to address issues. (Keep to 15 minutes max, table longer issues, etc) Burndown charts, core-team with a client on it.
You can't just have a 15 minute meeting every week and 2 week iterations and call it Agile, but if you do it right, it just MIGHT give you a chance. You might get a GOOD agile consultant in to train you on getting started.
Also, constantly evaluate what works and what doesn't. Be prepared to fix what doesn't work. Weekly meetings to analyze that weeks' development successes and failures.
Overall it CAN work, and can bring a flailing team into line, but it's not trivial. The nicest part is that you can implement it without taking huge chunks of time out of your current development. You just keep developing, but you do it better.
Tough situation, you have zero customer trust and basically can't be successful under that situation, no matter what.
For all intents and purposes the project needs a reboot; the unfortunate fact is that incumbant shops usually don't get this oppurtunity to start over and re-evaluate everything that is there.
I hate to say it, but you need to halt development and spend a month working out what went wrong...
The result needs to be a plan for a feasible 6month - 1year delivery really making them focus on what the must-haves are and real trade studies on your third party components. And trashing the code base needs to be an option; start a new source control project and when you get to a particular module port peices that make sense and leave the garbage behind.
Agile is great and all, and a valid approach once you get a real plan in place; but its not going to fix a broken relationship with your customer... or all the junk that's already there.
Here's the summary of key learning after reading through your experiences:
Maxim
1: Make sure this is not a "Death March"
Ellie
2: Make sure what's delivered works
3: Refactor & Realgin codebase to Architecture / Best practices
4: Look at what are the real issues: Is the team technically competenet to deliver?
Kendall
5: Ensure availaibility of Technical Leadership
Bill K
6: Implement Agile Processes (At least automated unit tests if not TDD, short iterations that make progress visible)
7: Get customer buy-in
8: Be prepared to throw out what cannot work (wishful thinking aside)
Warren
9: Make sure the team memebers that remain given a chance to start over
Tim
10: Motivate team and as improvement becomes visible reward them
jsl4980
11: You need buy-in on schedule from your team (most imp.) & customer
[This raises more questions. What if your customer asks whether the team is competent enough to stick to your schedule? What if you yourself know that the timelines the team is proposing just shows their lack of understanding]
Ather
12: Is the team commited?
13: Do you formally QA?
Patrick
14: Start over, redesign and reconform to Architecture/Design best practices for modules yet to be developed.
The summary has 14 items. You can't do them all. So, what's the first step?
Here's what you have to do first -- get one thing improved.
You've got fundamental quality issues. (#2-5)
You've got architecture and component issues. (#6, 7)
You've got schedule problems. (#1, 8, 9)
You can tackle quality. Formal unit testing, heading toward TDD can help. This might be hard because architecture issues slow testing down.
You can tackle architecture. This might be harder because it will probably involve rework that will not appear deliverable. But it may fix quality issues. Or, it may be compounded by fundamental testing problems.
You can tackle schedule. Without other corrections (i.e., quality or architecture) you may not get any traction with fixing schedule issues.
I think that overall improvements in people's attitudes come from starting with one success -- any success -- as early as possible. What's the lowest-hanging fruit?
One long-standing bug? One unit test suite to find and fix that bug?
One major architectural feature? Would a diagram that everyone can post in their cube help? How about a presentation clarify things?
One new use case? One new feature that actually works?
Here's a good book on the subject:
Catastrophe Disentanglement: Getting Software Projects Back on Track
First off, be resolved that you may fail -- if you can't accept that, don't take the challenge. And that includes being a scapegoat (it does happen). Management won't look at it in those terms (i.e. they're not intentionally/consciously 'setting you up'). But that is a reality of a corporate environment; if you take on the responsibility (often with more pay than those that don't), then your head is for the block if things don't work out. You have to be ready to stick with it for the long haul too. I was once placed on a client site for 8 months to fix a waning project. And as you saw, one of the other blog-posters here spent 9 months before a release version was ready.
Now, assuming you are okay with the possibility of it going all pear-shaped in spite of your efforts, this is what I suggest:
a bug tracking system is going to be your number one best friend, it will allow you to regain a semblance of control. you can't hope to understand a complex system as a whole, so 'chunking' it will help. and a bug tracking system allows you to unitize problems and distribute them to the other guys you are working with.
you have got both technical and political challenges to deal with. the technical generally aren't so bad because you're a coder and you know how to do this. the political ones are much trickier, you're at the helm of a ship thats gone hopelessly off-course, and you're in the Bermuda triangle. the biggest challenge is often stemming the tide of negative sentiment amongst the client (e.g. client: "these cow-boys don't know what they are doing", "they promised me this and didn't deliver", "i have no confidence in these guys to any more").
for starters, apologize to the customer and tell them in concrete terms what you are doing to do to re-right their project, e.g. you: "I'm sorry about the delay on your project, I'm getting stuck into it now. I've looked at the project history, and personally, I would be angry too if I was paying good money for this system. the first thing I'm going to tackle is..." <- bingo, you've just taken responsibility for the project which means there's no turning back - its all or nothing now.
a few other people have said it here, and I agree; stop adding new features. what they haven't mentioned is that you may have to do this to keep the client happy (remember, there's a technical and political side to the challenge).
understand the business domain as best you can. read through any requirements documents you can get your hands on. you are at a massive disadvantage by coming onto the project late since you don't know what was originally discussed. the devil is in the detail. this is what sunk me on a late projects I wasn't able to salvage, everyone was on edge, and i missed a minor requirement. at the time, it wasn't a big deal and could have been corrected easily, but politically speaking, it was the straw that broke the camels back. one tactic which may help is to go out on client site for a few weeks.
understand that time is money. its not just a technical issue. the client has paid for something which isn't right or has not been delivered. your company has expended resources, possible having already used up all the project budget - the business is now losing money. and this is where the issue of new features come in again, yes - people are saying don't add them, stablise. but adding new features can be a politically helpful tactic, management will be happy because new money is coming in for off-spec work.
I'd recommend against you or your coding crew working ridiculous hours to deliver. if you normally leave at 5pm, leave at 6.30pm or 7pm instead. you and your coding boys can consistently maintain an hour or two of extra work for many weeks on end and perhaps 4-5 hours over the weekend. working until 9pm or 10pm every night will result in burn-out in roughly 2 weeks (some can go longer). after that point, your extra time on the project is doing more harm then good. in the unlikely event your boss takes issue with this, make a choice; do what they ask (i.e. work more hours), or say "I've already committed extra hours to working on this project - I'm here for the long haul and im going to get this project done if its the death of me. but that is the limit of how much time I'm willing to put in. i have other commitments to keep outside of work" <- but be ready for the consequences (remember, political situation as much as a technical one).
there are people here that are saying "stop and write a spec, stop and do this..." - I'm sorry guys, i just cant agree with you here, its unrealistic. the project is already stagnating, the last thing management or the client wants to here is "we have to stop everything and...". I've tried this before, where I've said to the client and management "the bugs will keep coming until we stop and i write up a detailed system test plan. it will take me two weeks" - the client didn't want to pay for this, and management wasn't willing to wear the cost. as it happened, the bugs kept coming.
learn to 'juggle' - you have to map out tasks ahead of time so programmers aren't waiting on you. this will generally mean you do less coding yourself. generally this is best achieved by having a project schedule before coding starts. programmers should know what they are doing next after they finish what they are currently working on, and they shouldn't be coming to ask you "what do i work on next?", they should already know.
build-in recovery utilities, especially if the software has recurring problems which are hard to pin-down. for example; it may take 12 hours to track down a bug and fix it, it may take 2 hours to put in utility (read 'hack') to fix the problem for the time-being. time and momentum are of the essessen, and unfortunately bandaid fixes may be needed.
be very observant of the clients mood. they need to know you are 'on their side' (e.g. client: "the product is unacceptable", you: "i agree, i would kick our asses to if i was in your position. all i can tell you is im on it and wont rest until its all working"). when the client is back on your site, they will actually start helping you. for instance, they may shield you from pressure from your management.
lead your guys by example. something along the lines of "I'm staying back a bit to work on the project, I'd appreciate the help if your willing to stay back too" and "i know its not our mess, but we're still going to clean it up anyway. i want the client to get some good quality software". programmers could generally care less about the company that got them into this situation, but they may care if its about one of their own or the client ('may').
many of the suggestions I've seen here assume a fairly high degree of power (e.g. 'stopping the project to restart it properly' or 'say no to new features') - you are starting the project already hamstrung, and as a programmer, you will traditionally have less power to affect change then a true manager. this doesn't mean 'give up/don't try' - it just means you are going to have to be creative and do things you don't normally do (i.e. use 'soft' or people skills).
a lot of people here are saying bail on the project, run for the hills. I have been on 3 hopelessly late projects to date. i managed to fix 2, and 1 I couldn't fix. personally, it doesn't bother me to take on a late project. after all, the worst that can happen is you get fired :)
If you were involved in the project from the beginning, I hate to say it, but the company should replace you (and the entire team).
It should be reanalyzed with a competent team with real project management processes and lead by a project manager with experience in this situation.
None of the original coders should work on the 'new project' of saving it. They can move to other projects (they don't have to be fired) but to get a fresh look at the project, everybody should be replaced.
And of course, management has to understand and be on board with the fact that the project is going to be much later than expected. If management doesn't agree with this (replace team, find experienced leadership, take a step back and start again) then #Maxim is right - get out of there.
1) The first thing I will assess is whether the people on the team are committed to the project or not? If not, it is worthless to do any other thing. Nothing can prevent the disaster unless I get a dedicated and committed team.
2) I'll make sure that there is QA on the team.
3) Come up with a reasonable plan of iterative and incremental releases to the customer. With the mess we are in, there is no way customer can get everything soon. Based on the priorities of customer, we'll deliver smaller increments of functionality to him frequently. This will keep customer engaged, a bit less-edgy since he is seeing something happening.
What ever you do, do it step by step.
First, it's not about addind features, it's about fixing the app. Don't add anything new. Just refactor. Say no to any new stuff somebody ask you to introduce in the system.
Don't try to improve the whole app. Take your team, make it focus on one aspect at the time, with the best practices you can, especially using unit test.
Use test driven development only. In that case, it will immediately show you what part of the behavior you don't understand (you can't code a test if you don't know what to test.
So here are the road map :
Identify the critical part you need to change
Isolate the code that implies this behavior
Find any occurence of this code in the rest of the code
Refactor using this knowledge and massive TDD
Integrate, test and fix until this particular part works
Go back to step
Make the situation clear to your boss : it will take time, money and will be painfull. Explain why, what you will do, and that you have no other way or it will fail AGAIN.
A above all, don't try to make it clean the first time. Refactor what you can, but don't expect to change the entire architecture of the part you are working on the first time. You will have to iterate the process on the whole application several times.
No miracle. Just method and patience.
Been there, followed these steps:
Stabilize
gather the real story: how good/bad is the codebase, how good/bad are the developers, what really needs to get done (bare bone min.), when it needs to get done by
reduce overtime (tired people, good or bad, don't work well)
remove the bad, input new/good - err on the side of replacement (many could be burnt out and appreciate even a forced change)
remove access to bad/un-required code (focus on the 20% of the code base that provides the 80% of the value)
put base code practices in place ensuring only good code is getting in (don't damage the base anymore)
Control
implement teams focused on the app components (decouple as much as possible)
put code management, release management, risk management, QA, etc. in place (build your environment so you can succeed)
get on your clients/sponsors good side - delivery a win, even if it's a somewhat stable very very small release - and then put in change management (control what gets requested)
Move forward
develop a plan (planning is essential, plans are useless according to Ike - you need to plan to find what is missing and to set a target, but don't expect to tell the future) - continuous planning is required
aggressively manage your people - good people make good product - make sure you get and retain the best
refactor over time - clean up code as you go - you may not have the luxury to fix everything at once so do it overtime to provide for a cleaner code base
move forward bravely - overtime be more aggressive with your deliveries test (but not stress) your team
Agile refactoring. Identify and prioritize what customer wants and then create the most important stuff in short sprints out of existing code. Good luck man :)