251–260 of 420 posts
The problem is usually solved in three important ways:
1) making the deliverables as vague as humanly possible
2) promising experiments and not results
3) applying for grants for work that you have already completed, and using the money to work on the next grant's project
The problem of having deadlines that are too far out is mitigated somewhat by the pressure to publish. Publishing has fixed deadlines but somewhat flexible deliverables.
Earlier quoted context omitted.
Great! Please let us know when cancer will be cured. In other words, "I don't know" is sometimes a complete answer. I don't know. Period. This is supposedly one of the main points of this religion (agile). Some things are unknowable. So you move ahead a bit, and reassess. If you are scrumming, that is usually 2-3 weeks, and don't get me started on that arbitrary limit. But, you try to move forward for a bit, learn so…
> Please let us know when cancer will be cured. An absurd comparison given most software engineering tasks have been done before, they're simply difficult to estimate for some given team without expertise in doing some particular task.
I've been developing software for over 20 years, and I still can't estimate how long something will take me when I've never done it before. This uncertainty needs to become more than just a stick to beat developers about the head and shoulders with. Most of the time the PMs understand this, but there have been many projects where they just don't get it. I have suffered great anxiety from being forced to give estimate…
I bet your estimates won't be as far off as your colleagues'.
Heres's a good one by Dave Thomas. A quote: "Agile is an adjective not a noun". https://www.youtube.com/watch?v=a-BOSpxYJ9M
I've been developing software for over 20 years, and I still can't estimate how long something will take me when I've never done it before. This uncertainty needs to become more than just a stick to beat developers about the head and shoulders with. Most of the time the PMs understand this, but there have been many projects where they just don't get it. I have suffered great anxiety from being forced to give estimate…
I find even heuristics like double your estimate or padding it aren't useful because there's so much variance.
It is kinda funny. For me the first line has always been:
> Individuals and interactions over processes and tools
And when I am asked to explain Agile, that is always at the core of my message. Form a team, let them do their work and start learning how they can improve how they do it.
From my perspective, the primary role of a (software development) Project Manager/Scrum Master is to create an environment where the team can optimize itself while not drifting into personal conflicts (create a healthy environment for collaboration and feedback). Everything else, like planning/risk management/change management/stakeholder management/reporting/presenting come afterward.
Those other things are important too (and should not be skipped completely), but if the team doesn't work, most of the other tasks create little value.
Any software development methodology or process is going to come up short if it ignores the fundamental nature of software development, which is: We do not know what we're doing until we do. Any process or methodology that tries to extract promises out of the software development organization about things that are still in the we do not know what we're doing phase is going to result in disappointment at best and seri…
I have a theory that commercially successful software development methodologies are like diets: they have to be almost impossible to follow. This ensures that when you fail to lose weight/achieve bug free software, you blame yourself for not following the rules exactly, rather than the rules for not working.
Earlier quoted context omitted.
Im not a coder, so maybe the domain is different in a way i dont understand, but I agree with you 100%. Refueling nuclear aircraft carriers have projections start to finish, a half decade long. There are countless pre and co requisites with interrelated projects, not counting the mundane issues like material and manpower. I simply do not accept it is impossible to project a timeline for software. If someone stops you…
> If youre a professional coder and you show up to a planning meeting and your answer is "I dont know, i have no idea and its not possible to provide an answer even on an order of magnitude" thats just ridiculous. True, but it's because that question is often ridiculous. If it's technology I've never worked with before, in a domain I've never worked, for which the test data doesn't exist yet, it's perfectly reasonabl…
To be fair, thats something that happens all the time in "normal engineering". While the field itself is much better understand (mostly because aside of record beating sky scrappers, its usually within the same problem space), not everyone knows everything.
For a more down to earth example, if I ask my carpenter to scope out a bathroom remodel, the first thing he's going to do is call a plumber to take a look. The carpenter's not going to be able to give an answer on the plumbing themselves, but they sure as hell can say "Im going to ask someone and get back to you on it".
As a software engineer, I have a network of connections I can reach out to if I'm asked about a problem completely out of my space, and you'd be hard pressed to ask about something that no one in my team knows or has a connection to someone who knows. Definitely won't get the answer today or even tomorrow, but we can get SOME information.