Hacker News Reader

Comment by gregdoesit | Hacker News Reader

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.

View on HN

> 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.

True. 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.

I 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.

Unfortunately 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.

Isn'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.

Project Management Triangle:

https://en.wikipedia.org/wiki/Project_management_triangle

Time, cost and scope. Pick two.

Add: 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"

> "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.

I used to work at a corporation too

Reply on news.ycombinator.com