121–130 of 152 posts
Earlier quoted context omitted.
You forgot the "assuming requirements don't change" part. What's actually heard would be "Wa wa wah (up to) six months from now (guaranteed) wa wa."
Yeah, and they'll push for four months total at a meeting a month into the project, while simultaneously changing their mind on a half dozen requirements.
Earlier quoted context omitted.
I'm not saying waterfall is a good alternative. Waterfall is just as shitty as Agile, but one benefit is that wastes less of everyone's time with meetings and busywork. But waterfall is equally guilty of a one-size-fits-all mentality, from the opposite view of Agile, and this cookie-cutter property is what makes both methods attractive to bureaucracies. I'm a fan of common sense. If it's clear in a given team and pro…
Continuous improvement of the process itself is part of any good agile process. Corporate buzzword compliance agile is often guilty of not doing that - the "cookie-cutter property". But importantly, I've found that a refined agile process saves more work than it costs, by figuring out what doesn't need done before doing it, and prioritizing immediate value over future value. It's very important to be able to say "Thi…
I admit though that it's hard to know exactly what you mean just exchanging textual comments like this, so I'm happy to leave it at that.
Earlier quoted context omitted.
"So why waste valuable time to do all this, if you know it's not the truth anyway ? The answer is to accept that you will learn things as you go along, and that things take as long as they take, and to rather deal with that." This maybe is applicable for a company developing new products internally, but for projects delivered to third parties, delivery dates are part of contractual obligations. Estimates are hard, bu…
Contractually obligating pi to be 3, the Earth to be flat, or software features and ship dates to be specified, doesn't make them so. All you've done is restate the problem as an error on the part of the negotiating process. Not a problem to be dumped on developers.
(Yes, I know, the product you build is different than manufacturing, different than construction, different than paperwork, and every other deliverable.)
Earlier quoted context omitted.
"So why waste valuable time to do all this, if you know it's not the truth anyway ? The answer is to accept that you will learn things as you go along, and that things take as long as they take, and to rather deal with that." This maybe is applicable for a company developing new products internally, but for projects delivered to third parties, delivery dates are part of contractual obligations. Estimates are hard, bu…
Don't put hard commitments into the contracts then. Why slave yourself to something that you aren't sure you can deliver? Good developers should ideally only ever do the same thing once, which means that there is very limited utility in trying to improve estimates for a task that you should never perform again.
"How much is it going to cost to build my house?"
"Er, I'd rather not commit to a price. We'll figure it out later."
Earlier quoted context omitted.
It's better than this actually. If they want a release by Christmas I can with, high certainty, tell them: Features will be in: A, B, C Features likely to make it in: D, E Features unlikely to make it in: F, G Nope: H, I, J Hell No: K, L, ..., ZZZ The problem I've always found is that, no matter what, you are going to be arguing with sales and management about E, F and L instead of them just working with A, B, and C.
Ask them to give you a guaranteed schedule of sales that you will hold them to. They'll say it's absurd, you can't predict that. Turns out it's the same with software dev. If you find yourself arguing about this with management or sales, they're not trusting you to be the expert at what you do. Tell them that.
Sales quotas are extremely common.
Earlier quoted context omitted.
Don't put hard commitments into the contracts then. Why slave yourself to something that you aren't sure you can deliver? Good developers should ideally only ever do the same thing once, which means that there is very limited utility in trying to improve estimates for a task that you should never perform again.
In general, this is a terrible practice. "How much is it going to cost to build my house?" "Er, I'd rather not commit to a price. We'll figure it out later."
"How much is it going to cost to build my house?"
"Give me the blueprints and tell me your finishes."
[Waits on client to provide specs...]
Earlier quoted context omitted.
In general, this is a terrible practice. "How much is it going to cost to build my house?" "Er, I'd rather not commit to a price. We'll figure it out later."
Software development is very different from building physical structures. "How much is it going to cost to build my house?" "Give me the blueprints and tell me your finishes." [Waits on client to provide specs...]
"How much is it going to cost to build this application?"
"Give me your specifications for the app."
[Waits on client to provide specs...]
Earlier quoted context omitted.
Contractually obligating pi to be 3, the Earth to be flat, or software features and ship dates to be specified, doesn't make them so. All you've done is restate the problem as an error on the part of the negotiating process. Not a problem to be dumped on developers.
When you buy something from Amazon Prime and it gets there three weeks later, I hope you are as amused by the "negotiating process." (Yes, I know, the product you build is different than manufacturing, different than construction, different than paperwork, and every other deliverable.)
Or: your entirely counterfactual counterexample rather neatly proves my point.
Earlier quoted context omitted.
Going to join you in this rant if you don't mind. > Most can't tell their manager that it will take 2 weeks to parse a CSV because the source data is shit and they have too many other things they are working on. So they stay an extra 6 hours in the office and get called a rock-star until the day that they opt to go to their child's school play instead. Ugh! For real! I had this happen to me recently. I have trouble t…
Personal experience here - everything got better when I really started being a dick. I flat out tell them that they can't change reality and things take time; and I will not work extra hours or during the weekend to keep promises I didn't make. I had the same feeling of "when are they going to fire me" but actually it looks I am getting much more respect.
The other developers always seemed to get the message that when I said "Maybe... I'm not sure if I have the time for it... I can see...", I really meant "No, but please don't make me say no.", while anyone else hears it as "Cool, he said he would see if he has the time for it" and then follow up with me a few days later "Did you make time for that project?"
I'm making an effort to flat out say "No" more often, but it's nice that other people are also beginning to realize that I only mean "Yes" when I actually use the word "yes".
Earlier quoted context omitted.
Estimates can be fairly accurate if they're made for software that's a composition of previously iterated work. If someone asks for a login system with X,Y,Z and you've done that 1000 times, you can be fairly accurate in stating what it will take to do it 1001 times. The issue is when a piece of software is custom, and there's no domain expertise available for the custom bit then you cannot accurate estimate how long…
And some developers bring this on themselves. They could use the boring conservative technology that they know inside and out from the last project, or they could use something that's new and hot this month, which they have never done or have much less experience with (but is exciting). Double whammy if it's an unfamiliar domain and a cutting-edge tech stack.