Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange
147

Stop doing the 80 hour weeks. This is positive reinforcement. Because they are getting the product on time with expected costs, they are going to continue doing it, regardless of what it does to you. If they cannot budget time properly, then that's management's fault. Not yours. Let them miss a few deadlines.


135

You seem to assume the primary objective of project management is to produce exact estimates. This is not the case. The primary objective of project management is the same as for developers: To deliver value for the product owner. A product using a lot of slow manual processes rather than automation might in theory be easier to estimate (although I doubt ...


125

I think one of the main advantages is that humans and developers specifically are actually pretty bad at estimating time. Think of the nature of development too -- it's not some linear progression from start to finish. It's often "write 90% of the code in 10 minutes and then tear your hair out debugging for 17 hours." That's pretty hard to estimate in the ...


111

Read Bob Martin's "Clean Coder" (and "Clean Code" while you're at it). The following is from memory but I strongly suggest you buy your own copy. What you need to do is a three point weighted average. You do three estimates for each piece of work: a best case scenario - assuming everything goes right (a) a worst case scenario - assuming everything goes ...


96

In general, is there a way to push back on this? If not for this release, what about in future? Of course, there is: Let them fail badly with this approach. Nothing teaches as well as failing. Make an estimation yourself before you start and show it to them. Then do your best, write good code, stop compensating for their stupidity with your free time, ...


70

So my code is late too. No, it is not your code, it is the code of you and the senior. You are working as a team, you have a shared responsibility, and when you two miss a deadline, it is the fault of both of you. So make sure the one who makes the deadlines notices that. If that person sees that as a problem, too, he will surely talk to both of you ...


58

If you're using Fibonacci numbers (or something similar), it limits the number of options when estimating a story. I worked with a group that used low numbers only: 1, 2, 3, 5, 8, and 13. We had a reference story that was a 5. This enabled us to easily make snap decisions on a story's complexity while doing Planning Poker. The other side effect was that ...


52

This generally occurs because of a perverse incentive - the salespeople are being paid on commission, while the production staff is paid on salary. The salespeople have several levers to work with: features, cost, and delivery date. They have a strong disincentive to lower the cost, because this generally lowers their commission, so they tend to ratchet UP ...


48

You could ask him/her to estimate how long it would take for her to access some far away location in an uninhabited corner of the world. As an extreme example, let's choose some lesser known peak in the Himalayas, where very few (if any) people have ever climbed on. She would need an awful lot of preparation plus practice before even starting the journey, ...


39

You are right - copy-paste works great, and DRY has no point when your task is to produce a program for which either the copied template or the copy will not have to be maintained or evolved in the future. When those two software components have a completely different life cycle, then coupling them together by refactoring common code into a common lib which ...


34

My recommendation: You either include testing time in the ticket, or add a ticket to represent the testing task itself. Any other approach causes you to underestimate the real work needed. While developer time is often a bottleneck, in my experience, there are many teams constrained on test. Assuming the limiting resource is one or the other without ...


32

Two choices really: Quit, or grow a backbone. I think I don't have to explain much about quitting.. that one is obvious. If you can neither take it nor dare to change it, it's the only way to go forward. If you do want to change this, then it is your responsibility to stand up against this. This does need "a backbone", because you will be going against ...


30

This might be a good moment to introduce a quasi-agile approach. If instead of estimating in terms of hours/days you allocated a fibonacci type scale & gave each task a value based on how big it is: 0 - instant 0.5 - quick win 1 - simple change 2 - a couple of simple changes 3 - more challenging 5 - will require some thinking about 8 - a significant ...


27

In a good team, you should have a queue of development tasks assigned to you in an issue tracker. That way, while you are waiting for a reviewer, you could (should) work on next task waiting in that queue. Once you get used to work in that fashion, this will open an opportunity to have your changes reviewed in "batches", thus decreasing delays. If you don'...


26

The development team must be consulted on these decisions or you will never get out of that cycle. If you aren't managing the team, then one of your line managers needs to advocate for the development team. If they are part of the problem, then you may want to consider other employment options. Generally speaking, Sales shouldn't be committing to anything ...


26

The trick is not to avoid there being blanks. The trick is to fill in those blanks as early as possible in the process of development. You are correct that, if developers make assumptions, they will invariably be wrong and that will cost time redeveloping the software later. But, equally, if business people are expected to do a full up-front design when ...


24

Unless you are estimating something very similar to that which you and your co-workers have done before, +/-10% is ridiculously optimistic. Your management either doesn't have a lot of experience with software, or they're not aware of Large Limits to Software Estimation. That paper has some accompanying supporting material, and a lot of punditry can be ...


24

Best thing to do is not to throw the new developer into the fire, but instead carve out some functionality and/or bug fixes that the developer should have no trouble jumping in to. Find an area that needs work that doesn't require a person to know the entire architecture, requirements and code-base all at once. Maybe have him or her work on documentation ...


24

It would be better to say "I think that can be done". or "I'll check and get back to you". I've had times where I've said no or counter proposed something. If the customer wants "a browser based application that works without ever being connected to the internet and uses tactile feedback", it probably is possible. But it is expensive and it would be more ...


24

It's to enable estimation to get better over time, without the estimators all having to adjust their estimation. Rather than everyone involved in the estimate having to think like "OK.. looks like 2 man days.. but last sprint we underestimated everything, so maybe it's really 2.5 man days. Or 3?", they carry on the same as always. "5 story points!" Then, ...


24

First, congratulations on your contract! Ok, enough celebrating, let's get down to business. ;) I've been a consultant for over 15 years -- here's my advice. In project management, what you are talking about it "contingency" planning -- and you absolutely should do it, else you are likely to disappoint your client (and make yourself unhappy throughout the ...


23

You answer the question honestly. You tell them it's a difficult problem, the solution is not obvious, and you are not sure how long it will take to resolve. Promise to update them on your progress every [time frame], so they know you're working on it, and of course, actually send them the updates.


21

This is almost a universal thing in smaller companies as they have a greater need to close a deal. Until I was brought into sales meetings at my company I was bitter about this but I can at least understand how and why it happens a little more. Clients want it fast and many will play hard to get. This encourages sales to bend on time commitments just to ...


21

There are a lot of reasons why deadlines will always be tight. One of the main theories here is Parkinson's law. Parkinson states: "Work expands so as to fill the time available for its completion". So, if you have a project that would take 3 months and you get a 6 month deadline? How long would it take? 6 Months of course, because there's always ...


20

This is the second question in short succession triggered by that article. Good programmer: I optimize code. Better programmer: I structure data. Best programmer: What's the difference? There's another name for this: premature optimization. Never use early exits. That's the "single point of entry / single point of exit" rule. It's a patch over the real ...


19

So from a project management perspective, it is great to solve a task by copying some existing code 100 times and make some minor adaptations to each copy, as required. At all times, you know exactly how much work you have done and how much is left. All managers will love you. Your base assertion is incorrect. The thing that makes software different from ...


19

Emphatically, Yes Testing is part of the development process. If your team actually spends time testing the software, the time spent testing needs to be part of the estimate.


18

Have you explained that to the person? You are the professional software engineer, so the person that you are building software for should be considering your knowledge and feedback when it comes to the design and implementation of software systems. The Cone of Uncertainty is probably a good starting point. Software projects are hard to estimate until more ...


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