3 ms·

The biggest problem is communication and setting expectations. I constantly hear/see people saying "oh that will be quick!" without any real evaluation of the w

The biggest problem is communication and setting expectations. I constantly hear/see people saying "oh that will be quick!" without any real evaluation of the work. Simply saying "this is hard, it will take some time" makes focusing on correctness a hell of a lot easier. In no uncertain terms: don't be a pushover. If it can't be done well in the amount of time you suggest, don't say that it can be. You're just digging a hole for yourself (both present and future) and any one you work with.

ff_ 8y ago
This is easy to say and not unheard of, but in organizations it is common (in my experience at least) that if you say too often "this is hard and might take some time", people will just start to bypass you (and/or your input/judgement) in order to get stuff done quickly but less correctly.
- rglover 8y ago
  If you explain why they're less likely to. And if they push back, just say "okay, then I need your okay to rush on this so we can get it done—keep in mind that it may have flaws and I'd need you to take responsibility for those."
OneWordSoln 8y ago
The problem is that every new software project requires defining and solving a brand-new problem, and that "communication and setting expectations" part is really the problem of, first, specifying the problem and then, second, guessing how long it will take to solve the problem. Insert the old joke about "multiply by three and add five". Within corporate environments, the ultimate problem is that the people who allocate the resources are usually the least knowledgeable about the costs of "digging a hole" (i.e. technical debt). Of course, there is a great deal of blame to be placed on our -- the developers' -- shoulders, but guesstimating software delivery is difficult enough without non-technical people setting ridiculous timelines. I'd say the solution to the problem is to have managers select competent, driven developers who care about quality, and then for those managers to trust the technical teams to get the job done right. For such a team to work, each piece must work well and work hard.

ff_ 8y ago

This is easy to say and not unheard of, but in organizations it is common (in my experience at least) that if you say too often "this is hard and might take some time", people will just start to bypass you (and/or your input/judgement) in order to get stuff done quickly but less correctly.

rglover 8y ago
If you explain why they're less likely to. And if they push back, just say "okay, then I need your okay to rush on this so we can get it done—keep in mind that it may have flaws and I'd need you to take responsibility for those."

OneWordSoln 8y ago

The problem is that every new software project requires defining and solving a brand-new problem, and that "communication and setting expectations" part is really the problem of, first, specifying the problem and then, second, guessing how long it will take to solve the problem. Insert the old joke about "multiply by three and add five". Within corporate environments, the ultimate problem is that the people who allocate the resources are usually the least knowledgeable about the costs of "digging a hole" (i.e. technical debt). Of course, there is a great deal of blame to be placed on our -- the developers' -- shoulders, but guesstimating software delivery is difficult enough without non-technical people setting ridiculous timelines. I'd say the solution to the problem is to have managers select competent, driven developers who care about quality, and then for those managers to trust the technical teams to get the job done right. For such a team to work, each piece must work well and work hard.