3 ms·
There is such a things as physics in software: between time, scope and people, one of them almost always has to give. Exceptions I've seen are with mature and w
by gregdoesit 9y ago
There is such a things as physics in software: between time, scope and people, one of them almost always has to give. Exceptions I've seen are with mature and well-bonded teams working on familiar scope they understand clearly, with a timeline they themselves defined.
I've found the best "methodology" to deliver decent results are sticking with short iterations. Software is often about doing something we've either not done before, in a way we've not done it before, with people we've not done it with before. So we will have surprises (aka delays) on the way. The more frequent we check just what these delays are, the more realistic we can be about whether we can make it on time, or if we need to cut scope or pull in more help to make it on time.
- saas_co_de 9y ago> There is such a things as physics in software: between time, scope and people, one of them almost always has to give This can be true but can also be completely false. Massive differences in productivity are possible depending on how individuals work together on a team.
- Drdrdrq 9y agoTrue. Also, there is a fourth variable where you can cut corners (even if it's almost never a good idea): quality. Great teams can produce much more than mediocre ones, but they too have a limit. When deadline is set too close, one of these 4 things has to give, and it is good to know in advance which one that is, so team can set the priorities accordingly.
- Clubber 9y agoI would say that is part of the scope. The scope being a well tested, functional and relatively bug free software that does x, y and z.
- Terr_ 9y agoUnfortunately most business people don't make things like "doesn't corrupt the database when an exception is thrown" into a feature bullet. So while you can argue it's part of the scope, it's not part of the scope that anybody else seems to think about.
- Jtsummers 9y agoIsn't this: > Massive differences in productivity are possible depending on how individuals work together on a team. Addressed by this: >> Exceptions I've seen are with mature and well-bonded teams working on familiar scope they understand clearly, with a timeline they themselves defined. ?
- JoeAltmaier 9y agoAdd: process vs getting work done. We have to be cognizant that every minute spent on process, is not spent on writing deliverable code. I know, process can help ensure the correctness etc. But when the job becomes the process, and not writing and delivering code, then everything slows to a standstill. "And we're going to keep having these meetings, until we figure out why nothing's getting done around here"
- Jtsummers 9y ago> "And we're going to keep having these meetings, until we figure out why nothing's getting done around here" Do you work with me? I've been fighting this battle for the last 3 months. They've added almost an hour of meetings every morning at 9am. Half the office shows up at 8:30. That's enough time before the meeting to check email and get coffee, so essentially no work starts until 10. At 10 they get back to their desks, there's a bit of whining about whatever management has changed that day and how stupid the meetings are, some email correspondence and by 11 nothing is done and they go to lunch. They get back by 11:30-12 and finally start doing work. So your 8 hour workday turns into maybe 4 hours of real labor time, and no one works 100% of that.
- fpisfun 9y agoI used to work at a corporation too
- Clubber 9y agoProject Management Triangle: https://en.wikipedia.org/wiki/Project_management_triangle https://en.wikipedia.org/wiki/Project_management_triangle Time, cost and scope. Pick two.