Analysis, design, and testing always take longer than programming. Even with a code change of one line you may take a lot of time analyzing the problem and the best way to fix it.
Jerry Banker > -----Original Message----- > From: John Rodgers [mailto:[EMAIL PROTECTED] > Sent: Friday, March 07, 2008 4:01 PM > To: [email protected] > Subject: [U2] Estimating Timelines > > Snipped from Louie's contribution on the Include Wierdness > > - I have noticed that some programmers inflate their estimates by > 10 > times, just so they will look good finishing early. We have to > be accurate, without lying. > > > Speaking for myself, this is usually necessary because today's > applications are so complex that all the dependencies are impossible to > forecast. > > It is not a question of lying - it is a question of trying to > anticipate > the worst case. > The first estimate you give is the only one that "management" (your > customers) will ever remember. You can explain the changed > circumstances until you are blue in the face - it makes no difference. > The customer cannot see the issues. You are late in delivering. > > > A good example just occurred today. > > Set up a control flag for particular function. > > Easy enough - we already have a screen for these things - just add one > field > Should be about an hour. Tops. No big deal. > > Add the field and test it. > SB+ spits it back at me with a "matrix out of range" error. > > These are linked screens - we are on the fifth screen. > I smell a big problem. > > I create a sixth screen and put the field on that additional screen. > Now I get a different (more informative) message. "Too many fields on > linked screens". > > As I suspected - we have hit the limit of this arrangement. We are on > an > old version. > > Now I have to totally re-design this set of screens. > With Page forward and back keys > Don't forget the Inquiry mode - How do I make those use the same screen > defns? > Make sure it functions "exactly" as it did before - it does not want to > because the sub-screens are a different herd of cats. > > Now, how much time should I have estimated for this task? > And this is not unusual. > > Does anyone out there have any thoughts on THIS issue? > I think it (estimating timelines) is one of the more difficult tasks we > face. Especially when interfacing to an existing mature application. > Coding is the easy part of this job. > > > Cheers > > > JR > > > > > > > > > John Rodgers > > Masonite International > > Tel: (813) 2612396 ext 3036 > ------- > u2-users mailing list > [email protected] > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
