Reply to thread

Message: <blockquote data-quote="Mad Hamish" data-source="post: 7648032" data-attributes="member: 25321">As a developer I'll add a few thoughts from the trenches (about 12 years in the trenches as a developer & tester). And a hell of a lot of the work is in areas that you won't predict unless you've worked on similar things before. Data storage, speed of retrieval, changed requirements causing redesign, discovering that the framework you were told to use doesn't do what you need it to... (convincing management that the framework doesn't do what you need it to)performance problems as use and data scale up...There are a few different factors there. Commonly people are being asked to provide estimates on too big a task at a time or without enough detail. estimating (a+b+c+d+e) without a clear idea of what it should be doing. estimating a and estimating b... (although if you go too low a level you end up with estimates blowing out as well)There is always something that seems like it should be as easy as falling off a log that turns out to be as hard as log rolling through rapids with termites eating through the log and piranhas in the water.In most projects you're dealing with some new technology and it's extremely hard to judge how long that's going to take.Then there are just really stupid estimates and really bad approaches that cause terrible estimates. (I worked with somebody who was working on something he'd estimated as a 1/2 day problem for 3 weeks and was convinced all the way through that it was just a couple of hours away) Then there was another task on the same project that I'd had to take over which turned out to be way more complex than we'd though it would be because the person looking at it had missed some interactions with how the framework did database saving. I got it working but it took me a couple of weeks for a task that had been estimated at 1 day.A big thing is that if you pay attention to how your estimates actually turn out and learn from them for the next estimate but this doesn't seem to happen as often as it should.It's extremely rare that a project comes in much under time or much under budget. I've managed it in a few small projects that I've done by myself.As I think somebody else has mentioned there are various things that you can (theoretically) control about the system- quality -> how well the system does the job, this could include be how good the interface looks, how fast things work, what's required to set it up ...- scope -> what the system actually does- cost -> how much moolah it takes to make- time -> how long it takes to develop ityou can't control all of them and there are obviously limits (don't matter what you do it can't be done yesterday and it won't be free) Depends a lot what they're doing. If they're working with technologies they've used before with a reasonably specified system they should get pretty close. If dealing with new technologies or with a poor specification then you've got no hope. Of course specifications are hard and always change during projects so that commonly causes overruns itself.Scope creep is a big issue for most projects There's a lot of truth in that. I'm currently cleaning up another company's technical debt..._sometimes_ you can end with the opposite problem. Something might be good enough but people keep trying to improve it or come up with a better solution where it isn't needed.Terrible idea but can happen.Yep.Made worse when people put things out to tender, always with too little detail and massively unrealistic expectations. I'd like to believe it's not that common that it's that far off but it's more likely the bigger the project is.yep and then you have the pressure when things are sent out to tender as well or you are quoting on a an external project and management says they need the project Really bad idea...yep.or decide to use this amazing new product/framework etc which will fix the problem.always a good idea to keep them pretty much up to date with where things currently are.another classic problem is that it works with a low load but fails completely when the load is increased.And sometimes all the steps happen the same way...or management won't accept the idea...</blockquote>

Verification