Hot answers tagged

319

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 ...


105

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 ...


90

The leader of this project will be the person who steps up and takes charge at the beginning. This applies to most things in life - not just software development. When everybody else is running around like chickens with no heads, the person who thinks things through, steps forward and says, "This is what we're going to do and this how we're going to do it." ...


90

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 ...


58

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 ...


51

In this case I would simplify to Kanban. Kanban simply has a backlog that you work off, so there is no need to organize work into sprints. It's best not to over-complicate things. Considering this is a stretch of work that would be only one sprint, and a very limited staff, I think it matches the Kanban way more than scrum.


40

I'm guessing this is not a project at a workplace where you are a paid employee and something you do in your spare time for free? If you are making no money from this, then clearly there is no incentive for you, and no incentive for anyone else to come in fresh to deal with it. (unless maybe it is for a charity or similar voluntary organisation) As an ...


35

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 ...


25

Announce your abandoning of the product to your community of users. Maybe you will find a successor for your role as maintainer. Try to organize some time of handover, as you would with a project in your day job. As esr put it in The Cathedral And The Bazaar: When you lose interest in a program, your last duty to it is to hand it off to a competent ...


24

Jarrod Nettles' answer pretty much summarises a lot what I was going to suggest, so I'll throw in some of what worked in my recent experiences in a similar situation. I would suggest finding some way to talk with them vocally, rather than by email. If you're not in the same area, get them all on Skype. If you're in the area, meet them at a coffee shop or ...


23

Build one to throw away comes from "not knowing what you don't know" at the start, so you learn as you go what you should have done at the start. Second System Effect comes from "now knowing what you did not know, however not knowing what you still don't know" i.e. Second system effect comes from trying to build a bigger, shinier, more complex system than ...


23

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 all ...


22

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 ...


20

There are a couple of flaws in your Team Lead's argument: Well-designed classes and enums are intended to be used anywhere in your project, not just where they may make sense logically. Classes and enums that are properly documented with XML comments are very self-describing, by merely hovering over the item referencing it. You can always get to a class or ...


20

I'm not sure that thinking about a problem ahead of time vs. iterative approach are contradictory to each other. Just like many other things, I think you should strive to achieve the balance between the two. How do you find the balance? That's something you learn with experience and often time best lessons (i.e. stuff that gives you experience) is when you ...


18

Martin Fowler's quote is relevant: "You can change your organization or change your organization." Given that you've apparently decided to change your organization (make it better) instead of change your organization (work for a different organization), here are a few suggestions. First, a lot of your course of action depends on details about the power ...


17

For the specific project there's not much you can do until you find out what the client wants. However, there are some things you can do now so your team is ready to go. How are you going to handle version control? Will you do code reviews? When will the daily standup meetings be held? What are the rules? What role does everyone play? How are builds handled?...


17

What I have done in the past is either convert the physical development machine to a VM, or if it is already a VM, retain it for future use. It's not as efficient as I'd like for disk space usage, but space is cheap. Also, this process is so much less expensive time-wise than trying to re-configure an environment in the future should the need arise.


15

Separate the shared code off into a library, and include the library in the projects. As an Android developer, you're presumably using Java. Consider using a dependency management tool like Maven or Ivy. A side effect is that this will help maintain separation of concerns by enforcing modularity. The cost is that it may take some work to separate; the ...


14

I had enough experience coming out of school to start as a Sr. level programmer (after all, a lot of older sr. level programmers don't know this stuff), so I don't have the benefits of learning from a more experienced team. I completely and wholeheartedly disagree with what's being said here. The exact problem you're describing is one in which you just ...


14

Technical stories are allowed, but I would advise you to try to avoid them as much as you can. For example, your story for saving and retrieving images can easily be written as two regular user-stories As a reviewer, I want my uploaded photos to be stored persistently, so that other users can view them at any time. (Note that this assumes that in your ...


14

Why on earth are you planning to use Agile methods for such a small scale project? Agile methods are designed e.g. to handle the risk of unforeseen absences from ruining your project, and to schedule work tasks in a large team. They work by splitting the work to small chunks, assigning a difficulty to each of them, and then by some kind of magic the ...


13

While what you have done is sure to be a good thing, the project manager has to worry about a number of things: testing - what if you break something. Either something in the home page, or some other unintended consequence? The system needs to be retested. Depending on how far your company goes, this could be a large cost. Scheduling user downtime. May be ...


12

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 ...


12

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 ...


11

My biggest problem in University was team members who did little or no work. Some through laziness, others through being too busy with other work, others through manipulation and knowing that they could get away with it. Through trial and error, these were the strategies that I found to work in getting them to participate: Project Manage them. When everyone ...


11

Another suggestion for you, which is slightly the opposite of what you're asking but I think should be in your list for consideration. Have you considered not abandoning it? If you have a project that there are people actively using and have increasing requirements for, but are unable to modify it themselves and you are the only expert in the software... ...


11

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 ...


11

My current favorite methodology is to maintain a script that installs ALL needed dependencies for a project, downloads the source, and hooks everything up. Some scripts have two modes - one for production, which usually is pretty much a subset of the other mode: development. Some environments only take about 5 minutes to install with a script - in that case ...


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