Tag Info

Hot answers tagged

272

Communicate your concerns in the most concise and non-confrontational way possible up the management ladder. Summarize the risks, but do not impose your conclusion on them. Management must always have the choice of what to do, but it is your job to assess and communicate the situation. Use email, so as to leave a paper trail when things go south. Having ...


87

Keep a paper trail (e.g. diary, saved emails, etc). Only include facts and objective observations. Leave all conclusions up to whomever (if anyone) reads what you've written. As a developer, if you're not viewed as an obstacle to the project you're likely to come out fine from the finger-pointing that will no doubt happen. Your manager may not be so ...


74

I'm going to recommend you take a little time to read 2 books. Death March is the canonical book that describes a pathological project management style that is widespread in software development. Due to schedule compression, feature bloat, or mismanagement, many projects end up in a bad state; it helps to understand that you are not alone and your project ...


43

3 simple and cynical strategies to maintain career/sanity. See a train wreck in the making - get off the train: Failing projects are terrible for morale and unless you have ninja upward management skills will have some negative impact on your career. Jump now if you can see any soft landing. If that doesn't work keep your head down: People are going to ...


28

What impact will this soon-to-be failed project have on your career at the firm, and beyond? In my experience, merely being associated with successful projects is not an indicator of your own personal excellence. The qualities that you exhibit in the face of adversity and sometimes what looks to be certain failure, often gets noticed by the higher-ups, more ...


23

Both describe the consistency of an application's behavior, but "robustness" describes an application's response to its input, while "fault-tolerance" describes an application's response to its environment. An app is robust when it can work consistently with inconsistent data. For example: a maps application is robust when it can parse addresses in various ...


20

The concept of failure is really a business related call. If a commercial project costs more than the money it brings in, that project would be considered a failure. If an open source project cannot build a community around the code to help maintain it and care for it, that open source project failed. I've been involved in projects were we delivered ...


18

In a situation like this, as the lowest rung of the ladder, there is only so much you can do to help the project. Make sure your work is spotless help identify the biggest problem areas Try to provide answers, not just problems. Look like you are trying to fix them. Aside from that, you really do have to look after number 1. Document everything keep ...


17

Failing projects can be toxic to the soul, cause depression, over work and low self-esteem. It's all relative to perspective. I've worked on horrible projects while sitting across from another guy who had a smile on his face every single day. Oh how I wanted to slap that smile off his face. Some people aren't bothered by the current state of affairs on a ...


13

The biggest problem is misunderstanding. Common failures are: Only a team is doing Scrum but rest of the company (including sales, management, HR) still think in the old way. Examples: Continuous interaction with customer and customer's involvement is very important. HR has to understand that team performance is more important then performance of ...


12

My favorite lesson – very hard won! – is that in a multithreaded program the scheduler is a sneaky swine that hates you. If things can go wrong, they will, but in an unexpected fashion. Get anything wrong, and you'll be chasing weird heisenbugs (because any instrumentation you add will change the timings and give you a different run pattern). The only sane ...


10

Are there some prejudices, yes perhaps in some cases. For large organizations however this path to expensive proprietary application servers and other expensive software suites given them some advantages and securities that some rarely think about. 1) Support: Typically when a large corporation has million dollar software the support is built into the ...


10

Try to be proactive about finding a new way to achieve success for the project. Think about how you can propose some alternatives. Right now your boss is probably getting beat up about the project being a failure, wouldn't (s)he appreciate someone coming in with solutions instead of problems? Maybe there is a way to split the features into staggered ...


9

Biggest problem is always buy-in. If any team, or key individuals haven't bought in (project management, QA, development, etc) then failure is almost assured. Another related problem is actually making everyone involved aware of what scrum actual is and what is not. I've seen environments where project management has actually taken this as a ticket to ...


9

The biggest problem I've noticed in over 10 years of xp and scrum, is when teams who don't quite "get" agile yet, decide to "be flexible about agile" and start customizing it, dropping certain parts, etc, without a clear understanding of what each part does and why it's there. I've seen teams be more successful with scrum when they do things by the book at ...


8

You should do lessons learned for all projects, failed or succeeded. There is a lot to learn from a good project. True failed projects have been very rare for me. In addition to understanding what happened, I do the "ask why 5 times" thing to try to get to underlying causes. There is also the matter of why I didn't notice what was happening and either do ...


8

EDIT: On re-reading this sounds a little bit harsh, it's not meant that way. The things you describe are common and are usually caused by entirely understandable factors (and then exacerbated by your trying to be helpful). Anyway, if it comes across as harsh, sorry, it's not finger pointing, it's just trying to say "this is what seems to have gone wrong, ...


8

Sounds like most projects I've been on. It probably won't end as badly as you think, however: 1) Do your job. Don't worry so much about the overall project as long as you complete your responsibilities. 2) CYA. If the project does fail and you suspect the manager will start blaming everyone but himself, make sure you have enough proof that you did ...


7

Work hard; but not at the expense of your family or your health. Keep a record of all critical design decisions; especially as they pertain to your work. Keep networking, and keep your options open if the situation becomes too difficult or you become a victim of a mass layoff. Try not to think of your project as a "failed project". Everyone likes people who ...


6

The best thing to do is to communicate openly and frankly about your own failures and graciously ask to be relieved of your obligations. It won't help you or the customer to point out all their failings, and you'll feel better without the obligation hanging over you. Take this experience as a painful class in the school of hard knocks, and prepare better ...


6

Have you heard the phrase, "closing the barn door after the horse is gone"? You blew it. It's too late. Sure, you can show that you at least understand you blew it by apologizing, but you've established your reputation with that client (and your employer's reputation as well). "Did you have situations where your ignorance and personal non-technical ...


6

Trying to do all the analysis for the code we were developing in the same sprint we were actually coding it.


6

Here's a few basic lessons I can think of right now (not from projects failing but from real issues seen on real projects): Try to avoid any blocking calls while holding a shared resource. Common deadlock pattern is thread grabs mutex, makes a callback, callback blocks on same mutex. Protect access to any shared data structures with a mutex/critical ...


5

Be honest. Explain that the project was cancelled and why it was cancelled. You say that the company was "dissatisfied" with how it was going. You need (to provide) more information, was it the speed of progress, the performance of the product, its direction?


5

Good. You now have your feet on the ground and are a really programmer. Projects go poorly all the time. It's usually got little to do with the developer. Any manager that you would want to work for should understand this. Any manager that doesn't understand this is probably setting themselves up for failure. Remember that interviews go both ways. I've ...


5

Your entire GUI project should only be called from the main thread. Basically, you shouldn't put a single (.net) "invoke" in your GUI. Multithreading should be stuck in separate projects that handle the slower data-access. We inherited a part where the GUI project is using a dozen threads. It's giving nothing but problems. Deadlocks, racing issues, cross ...


5

I haven't ever heard of any problems that were the result of using an Open Source product. I think the reason for the concern isn't due to some historical failure, but something else. When you use a commercial product for some task, and something goes wrong, you usually have someone you can call for support. That person (and company) usually has a vested ...



Only top voted, non community-wiki answers of a minimum length are eligible