InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comTue, 21 May 2013 13:52:18 GMT20http://www.sqlservercentral.com/Forums/Topic407174-263-1.aspxA little off your question but pertinent to the article:Steve McConnel did mention that his project differed from business in that there would be no quality shortcuts or tradeoffs, no charges for overtime, and no risk of project cancellation.He failed to mention there would be no mandatory scope creep by the customer. In my experience, the fort would be a skyscraper and just about the time you had all of the steel up, or just a bit later, the customer would ask for a couple of sub-basements -- not realizing or caring about the difficulty in replacing or modifying the foundation with hundreds of tons of steel standing on it already. From the non-technical customer's point of view, coding is something done via a tool similar to a word processor, so adding to the code should be no more difficult than scrolling back and inserting a few extra paragraphs in a white paper.Tue, 09 Oct 2012 09:18:09 GMTmichael.lairdhttp://www.sqlservercentral.com/Forums/Topic407174-263-1.aspxWhat doesn't take longer than you expect in your life? Living it. Going MUCH faster than I ever thought and continually accelerating.I have found though, that getting ready to go somewhere ALWAYS takes LONGER than my wife thinks it will.Mon, 08 Oct 2012 15:57:00 GMTjshahanhttp://www.sqlservercentral.com/Forums/Topic407174-263-1.aspxOn the topic,Planning and estimating with padding is all well and good. For the post part we are close or within a reasonable percentage of error. And we do learn from the experiences. However, identification of the critical risk factors is important. Unfortunately these often fall short. There may be one thing in the project, architecture, design, or software platform which is not thought of and is not planned for and that shatters the estimates if it happens. The intangible or fatal flaw that is imperceivable at the start but comes to roost in the middle of the project is the one thing that we all fear. The "deprecated", redesigned, replaced, discontinued, or "enhanced new version" can be a major problem and can redefine all the estimates and the feasibility of the project. We can be good at estimating, but as long as technology is involved each estimate has to be joined with significant critical success factors and a major caveat. :-)Mon, 08 Oct 2012 10:36:39 GMTMiles Nealehttp://www.sqlservercentral.com/Forums/Topic407174-263-1.aspx[quote][b]Loner (10/8/2007)[/b][hr]I can only complain at the web site or some blogs. I am sorry you have to listen to my complain. Maybe I should stop complaining at the website or blogs too. Prozac is good drug !!!:crazy:[/quote]No need to be sorry. No need to apologize at all, ever. There are two things worth mention about what you post. First it is of benefit to you. You have to have somewhere to vent and to get some release about the stress and pressure. You cannot afford to keep this all inside and let it tear you up. And bouncing ideas, venting, asking IT related questions, and speaking of your experience in teams or in heavy IT related areas should always be seen as an asset. you are part of a community here and in this community there is technical and social give and take. So give as you can and take what you need as well. Second of all what you vent about is good for many of us to hear. We have not had your experiences and have not faced what you have in your jobs. As a result we may not even believe that these sort of things happen in the workplace. But you are living proof that they do. By your posting the real issues in the office and how it effects you we as a community can see what one day may come right into our face, and others here might see the effects of what they do and how they do it and change themselves. And one last thing, maybe the next job will be much better.M.Mon, 08 Oct 2012 10:19:01 GMTMiles Nealehttp://www.sqlservercentral.com/Forums/Topic407174-263-1.aspxI like the Shogun technique: to make my best estimate and then to multiply it by a factor. (Yes in Shogun it was gifts/rewards and the multiplier was progressively small value than .5.)When I was actively developing software I tried for a 250% multiplier. Better but of course imperfect. Also difficult to do unless you are willing not to talk about it with management. Perfect honesty being difficult.However, the more we estimate 'like' tasks to more proficient we must become.I was trained by PM professionals in the nuclear power industry. Learning to break-down work into unique scopes of work by Work Breakdown Structure and Organization Breakdown Structure to identify discrete tasks that are self-contained units of work performed by one group and with precedence and successor relationships really does help.Also remember Fred Brook's experience that he wrote about in the Mythical Man-Month: true now as then. Highly recommended. I really appreciate the point that you can't simply add labor to a task. If only one man will fit in a hole than only one man can work effectively to dig that hole. Adding more men will simply cost more man-hours with no increase in producing the hole.Mon, 08 Oct 2012 10:17:14 GMTanorhoadshttp://www.sqlservercentral.com/Forums/Topic407174-263-1.aspxThank-you. This was an excellent response. One that I too will borrow!Mon, 08 Oct 2012 10:13:11 GMTanorhoadshttp://www.sqlservercentral.com/Forums/Topic407174-263-1.aspxHere are two examples from my experiences:I recently ripped out carpeting and replaced it with hardwood. It took longer. First, there was the issue of selecting fairly priced product, and in this economy one would think that would be easy. Turns out, the box stores couldn't compete with the specialty store in this case, but unfortunately I went there last expecting it to be more money. Then I rented the tool I needed, and had no idea how to use it. Then it broke, the head was leaking compressed air and nails wouldn't set fully. Then it broke again after they fixed it, the trigger mechanism failed. Then there was the pain I experienced from putting my body into unexpected positions. What should have taken a week ended up at about 9 days.Previously I had a Honda Accord that had a radiator fail after about 150,000 miles or so. There are only so many insects and rocks before something causes a leak! Honda wanted around $700 to fix it. They estimated about 3 hours for the job, at the highest labor rate. Hmmm, I can do that myself! So I bought the radiator, disasembled the car, put it back together with the new one, and then freaked out over what I missed. Why? It took me less than an hour! It also cost around $200!I do all my own auto repairs, and had every class except for transmission back in HS. So I know how to work on cars.I took some basic home building classes in HS, but haven't done it as frequently. This being my first hardwood floor job, I had some unexpected issues.GSquared said it very well this morning, with experience you can estimate well.Mon, 08 Oct 2012 09:22:02 GMTdjackson 22568http://www.sqlservercentral.com/Forums/Topic407174-263-1.aspxI've actually had managers tell me to pad my estimates on how long something will take, "just in case".I occassionally have something go over my original estimate, but not often. Maybe because I'm actually trained to do that kind of estimate accurately. The human mind is usually terrible at things it does "off the cuff" or "by instinct/intuition", but can be superbly accurate after adequate training and practice, on all kinds of things.Mon, 08 Oct 2012 08:33:58 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic407174-263-1.aspx[quote][b]Michael Valentine Jones (10/5/2007)[/b][hr]This works well for me1. Set delivery date2. Do some programming3. Test4. If test is good, go live, else go live5. Define requirements6. Repeat 1 through 5 until system is obsolete[/quote]ha! That's like a more-formal version of: Ready, Fire, Aim.Estimation is a skill. I wish more people possessed this skill. Even outside project management, estimation should be taught in school. It's useful to know within $20 how much a cart full of groceries will cost or how long is likely required to put those groceries away. Many responses in this thread have used the term "optimistic" to explain why we underestimate time and money. I think there's some psychology involved too. We're generally bad at estimating for our personal information but when someone else is asking for a judgement of work, we want to deliver the news we believe they want. Since everybody is so impatient, the estimate is usually skewed to accommodate less time requirement. For the sake of planning, however, the honest/non-skewed estimate is far more valuable. Ex: Don't tell me the task will take 10 minutes because that's what you think I want to hear when the operation is 1 minute per unit and you have a stack of 60 units to process. I am likely to wait in standby-mode for 10 minutes but an hour is plenty of time to do another process in parallel.Mon, 08 Oct 2012 07:09:32 GMTMike Dougherty-384281http://www.sqlservercentral.com/Forums/Topic407174-263-1.aspxWithout meaning to be trite - the more well known (differentiating that from thought to be known) something is the more likley it is that the estimation will be correct. The reason you can be more often correct about the length of the drive somewhere has a great deal to do with frequency along the path and how much you are paying attention to time. These two things composited make the task well known to us. we need to both know the steps for the task (path, if you will) and must note the correspondent time required to complete those steps to successfully estimate. Not wanting to beleaguer the point I will stop there.As a software engineer I pride myself in being able to figure out how to do just about anything. The truth is that I am not any good at time estimation becuase I am ALWAYS more interested in the task than the time it takes. Thankfully, as a member of a desgin team, I am often teamed with people who are more "time aware" than myself. I design the development task steps and they attach times to it. It is surprising how often this methodlogy can be successful. This is the answer to your poll - things take as long as I expect them to when I have help planning them.Tue, 09 Oct 2007 13:21:22 GMTPaul G-468777http://www.sqlservercentral.com/Forums/Topic407174-263-1.aspxI was a team player and I got along with everyone fine. I used to talk to my co-workers all the time and we had a lot of fun.But for the last 3 companies I worked, I did not know it was my bad luck or people were different, no matter what I did and said, I got in trouble. Company 1 - The DBA was the king, when I made a mistake, he either yelled at me in front of the whole group or emailed to the whole team. His brother was a developer too, when his brother made a mistake, no one said anything. Even when I did something right, but if he did not like my approach, I had to re-do it according to his way. I went to lunch with them too, but how I could enjoy it when that person just yelled at me.Company 2 - I mentioned that one young DBA missed something when she implemented my work into production. It happened she was a young Indian woman, flirting with every DBA including the DBA manager. His manager complained to my manager that I was a racist. My manager told me to stop saying anything.Company 3 - One time my mother called me because of emergency, we talked about 20 minutes. The next day my boss called me and said someone complained that I used company time to do personal stuff. When my new manager dictated us to use trigger for the ETL process, I sensed something wrong. So I posted the question here, someone mentioned it would create a deadlock. The next day I went to work, somebody told me the job created a deadlock. I mentioned to my manager, he told me not to post anything and never trust anyone on the website. He started picking on me more and more because when he told me to do the project, I found out the old procedure he wrote had a lot of mistakes. I did not say anything instead just changed it. He found out and he did not like it. He just could not stand someone was better than him. He worked remotely and when he came to town, he wanted to go to dinner together.In all companies, either I stopped talking or I could only say something good, happy and fun things. I went to lunch / dinner with my co-workers. I felt so stressful because I did not know what to talk about, when I came home, I had to take Pepcid AC, Bayer, even Prozac. Last time I had pneumonia in May and in July, my doctor went up the roof. All these were caused by stress.Ok I am still a team player, but I play a role at work, I cannot be myself at work. I also have to play a dump employee at work. I can only complain at the web site or some blogs. I am sorry you have to listen to my complain. Maybe I should stop complaining at the website or blogs too. Prozac is good drug !!!:crazy:Mon, 08 Oct 2007 16:48:10 GMTLonerhttp://www.sqlservercentral.com/Forums/Topic407174-263-1.aspxA boat yard suggested the best way to estimate the amount of time to plan for a job: give it your best estimate (1 hr), double it (2 hrs), add 10% (2.2 hrs) then round up to next time value (1 day). It has proven more true than I like to think.Mon, 08 Oct 2007 14:10:50 GMTRex Richardsonhttp://www.sqlservercentral.com/Forums/Topic407174-263-1.aspx[quote][b]Loner (10/7/2007)[/b]No team can build a data warehouse or any system in seven days unless the company have a thousand developers. But even the company hires a thousand developers, the system would not be done on time because people do not work on the same goal, there is no team spirit.Going out to lunch, dinner or get a drink to me is not team building activities. It is socialized with your teammates, they might still do not trust and respect you. In my old company, I worked on a very good teammates, no one forced us to go out, but we worked very well together because we respect each other's talent and trust each other's work.my 2 cents.[/quote]A team is something more than a bunch of machines thrown next to each other. If a team is well built, with the right plan, the right coordination, and of course the right minded people, and if the team members are all focused on the same goal, you can get a tremendous amount of work accomplished in 7 days.I'm saddened by your post mostly because of your automatic rejection of all-things team-related. It sounds to me that you've been hurt in a team setting before, so you now approach each team you're on in the same way (often precipitating the same thing you hate by the fear you bring).I'm not the most hoorah person in a group, but knowing how your team thinks, what they like, what they know is a HUGE asset. Learning to cooperate, anticipating where someone is going to be on a volleyball field, knowing that the no-look pass you just threw is going to connect with your wingman is something that translates directly into team efficiency. Of course - there's a balance, but learning about each other outside of the constraints of work can be very valuable.Not every co-worker is out to s***w you. You really need to learn to trust - this is actively eating you alive. I hope you can find a safe setting to flourish in. Perhaps something in the not for profit world, a goal or a mission that overrides all other concerns.Mon, 08 Oct 2007 10:21:14 GMTMatt Miller (#4)http://www.sqlservercentral.com/Forums/Topic407174-263-1.aspxYou definitely have to get along and share information to get things to work smoothly.But I'll disagree with you. Social activities are a way to do team building, not just exercises in some room. Going along to lunch, dinner, a ball game, anything helps to build a strong team. It's not the ball game, it's the relaxed, away from work atmosphere that bonds people together.Mon, 08 Oct 2007 09:12:29 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic407174-263-1.aspxActually I was starting writing an article about comparing building a house vs building data warehouse. Now I can scratch that article. I was thinking about the TV show 'Extreme Makeover:Home Edition', the have to build a house in seven days, of course in the show money is no object, Sears supplies all the tools and appliances. But it is the team spirit and all the people volunteers that successfully build the house. They work on the same goal. The team leader Ty would help solve all the problems (of course he has a lot of helps), but in reality when we work on the project, how many time the manager is on our side to help us solving the problem besides keep telling us to get it done in time. All the team members get to know the family members and build the room with their special interest. How many team members on the team know the business and how the data warehouse system work? Most of the time one person works on one time and never bothers to learn anything else. Ty is not the architect, he relies on the construction company to get the architect to draw the blue print to build the house. He trusts and respects the construction company, all the team members and the volunteers. My former manager was a developer before, he actually gave me a template when I started on the project. First the template sucked, second that meant he did not trust me to get the project done by myself. He did not respect my knowledge. On the same token, I did not respect and trust him either. In some cases, some team members did not want to share their knowledge, they were worried they would lose their job, it was their job security. One time I was learning Actuate Report, I asked the Actuate report developer to show me the admin piece, he said 'NO'. I did not want his job. But people these days had a hard time to share the knowledge. There were tons of volunteers to help to build the house. How many time when you need help, you teammate would volunteer to help you ? or you need information from other department, anyone from the other department would volunteer to help you and explain to you the problem.No team can build a data warehouse or any system in seven days unless the company have a thousand developers. But even the company hires a thousand developers, the system would not be done on time because people do not work on the same goal, there is no team spirit.Going out to lunch, dinner or get a drink to me is not team building activities. It is socialized with your teammates, they might still do not trust and respect you. In my old company, I worked on a very good teammates, no one forced us to go out, but we worked very well together because we respect each other's talent and trust each other's work.my 2 cents.Sun, 07 Oct 2007 13:56:56 GMTLonerhttp://www.sqlservercentral.com/Forums/Topic407174-263-1.aspxI'll have to check out that movie, but it definitely is the small stuff that kills you.Often because you don't really want to estimate it. The small things that you think will take 10 minutes aren't worth the 2 minutes to estimate them. Software is similar because if you went through everything in painstaking detail, then you probably get a great estimate, but because 40% of your time would be in design before making the estimate, you'd be committed to the project before you started coding!Plus, most of us would go crazy spending 40% of our time talking about the details of an application.Sat, 06 Oct 2007 07:50:38 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic407174-263-1.aspxThis works well for me1. Set delivery date2. Do some programming3. Test4. If test is good, go live, else go live5. Define requirements6. Repeat 1 through 5 until system is obsoleteFri, 05 Oct 2007 16:23:40 GMTMichael Valentine Joneshttp://www.sqlservercentral.com/Forums/Topic407174-263-1.aspx[quote][b]peterzeke (10/5/2007)[/b]So next time the toilet gets clogged, rather than assume it will take 20 minutes to plunge it out, I put some bigger numbers around the job, say 3 hours. (Whoa! -- It's a hell of a clogg!) ;)[/quote]If you approach that problem from a DATABASE application developer's viewpoint, it would take three hours. After all - you don't use the front door (UI) - you'd have to clear the clog from the BACKend....[ewwwwwwwwww]:w00t:Fri, 05 Oct 2007 15:40:06 GMTMatt Miller (#4)http://www.sqlservercentral.com/Forums/Topic407174-263-1.aspxAbout the only thing that goes right when it comes to time is when I heat something in the microwave: 2.41 minutes and the popcorn is ready. i know it, the family knows it. It even says so on the bag.But, anything that takes longer than 2.41 minutes has an unmeasurable lag ratio, an aill-defined start time, and a completion estimate that seems unattainable. Like Steve Jones, I've come to discover that maintenance around the house is tough to estimate. Of the jobs I've done, I'd say that I was off by 3-to-1: if I thought something would take an hour, it took 3. So, now, when I estimate that kind of work, I nearly consider multiplying my initial estimate by 9: if I think it will take an hour, multiply it by three, and just to be safe, multiply it by 3 again.So next time the toilet gets clogged, rather than assume it will take 20 minutes to plunge it out, I put some bigger numbers around the job, say 3 hours. (Whoa! -- It's a hell of a clogg!) ;)Fri, 05 Oct 2007 14:36:18 GMTpeterzekehttp://www.sqlservercentral.com/Forums/Topic407174-263-1.aspxRe: Mr. Blandings Build His DreamhouseGreat movie. :w00t:We drag that out every now and then and thoughly enjoy it. It's even funnier when you are not familiar with east coast mentality.We had to watch that just before we built our current home. It kept things in perspective.Fri, 05 Oct 2007 14:09:46 GMTBob Hoffman-209065http://www.sqlservercentral.com/Forums/Topic407174-263-1.aspx[quote]If Architects Had To Work Like Software Designers...[/quote]If you've never seen the movie / read the book, check out "Mr. Blandings Build His Dreamhouse" (movie with Cary Grant and Myrna Loy). Classic example of the above statement!The best part is where one small change significantly affects the project cost. (I won't say more.) :DFri, 05 Oct 2007 13:47:34 GMTTodd Townleyhttp://www.sqlservercentral.com/Forums/Topic407174-263-1.aspxProject schedules are just like everything else, it's easy to account for the big stuff but it's lots of little stuff that eats you to death. It's easy for me to budget around my two mortgage payments, car payments, electricity bills, and student loans. It's the neverending $30 trips to Wal-Mart and Home Depot that keep me broke :w00t:Fri, 05 Oct 2007 13:33:30 GMTTim Mitchellhttp://www.sqlservercentral.com/Forums/Topic407174-263-1.aspxIt's said that no battle plan survives contact with the enemy.-this isn't really the same topic but the last line of any good plan should be "If all else fails, improvise". Among other things, this will save your battle plan from becoming obsolete.Fri, 05 Oct 2007 12:22:06 GMTNF Scott Smithhttp://www.sqlservercentral.com/Forums/Topic407174-263-1.aspxI think estimating comes with knowledge of what you are going to do and the desire to get it done on time to start with.I volunteer a Church camp to take care of all the facilities and projects there. It is 80 miles from my home, a 2 hour drive one way. There is no nearby store for supplies. I have to maintain a 7 mile long "driveway" just to access the property. We generate all own utilities. I have to design the project, plan the work schedule, get materials to the site, line up the workers, feed the crew and anticipate all the problems that will crop up. I've learned to have plans A, B & C ready to go when things go bad and they do.My success rate?All things considered, not to bad. Some projects are taking longer to completion, others do not. This year a new 44' bridge was put in. Additional parking was added. A roof put on the new bathhouse. Another new cabin completed except for interior furnishings. Two of my 3 generators were hauled out because of mechanical breakdowns. 2500 -3000 gallons of fuel hauled in. Plus all the other normal stuff being done while fighting mosquitoes, bears, white sox's, etc.So accurate estimating can be done if you want or really need the project to be done. The bridge took more than a year in planning. Closer to 3 and still required changes when the onsite conditions changed.You have to think differently based upon your resources. In Steve's case, when the throw bolts broke, his wife went to the store to get more. If I needed to do that, it would take someone a minimum of 2 hours to get them, if they could quickly find them. I would have to plan on having extra bolts before hand.That or have them flown in from town, a 15 minute flight. We get ice cream that way! :w00t:Fri, 05 Oct 2007 10:39:34 GMTBob Hoffman-209065http://www.sqlservercentral.com/Forums/Topic407174-263-1.aspxOr "H" is better at getting stuff done than the rest of us :PFri, 05 Oct 2007 10:10:30 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic407174-263-1.aspxI experienced that working with an 'internal mutiplication factor' works out quite alright for me. When estimating how much time a project would take, most of the time I've got a pretty good hunch. And I know it's based on the fact that I believe that all actions to be taken will turn out right first time. Which of course never happens. So I multiply the initial estimate by 2.Works most of the time for me; perhaps it's a matter of finding your own personal internal multiplication factor....Fri, 05 Oct 2007 10:03:07 GMTH-122523http://www.sqlservercentral.com/Forums/Topic407174-263-1.aspxWell it is really good to know that even someone who has been involved in making estimates most of his life has trouble with it.I have always had trouble giving estimates, partly because I just think it won't take as long as it does. I used to error on the short side because I was afraid the people receiving the estimate wouldn't accept a longer time line. While I think I have gotten over that problem, I still seem to estimate things on the short side.Other people are always telling me that all it takes is more practice and I will get better at estimating software projects. It is good to know that others have struggled with the same issues.Fri, 05 Oct 2007 09:34:18 GMTJereme Guentherhttp://www.sqlservercentral.com/Forums/Topic407174-263-1.aspx[quote][b]Donald E. Weigend (10/5/2007)[/b][hr]I like to use Bob Vila's rule: Take your estimate and double the units of measure. So if you think something will take one minute to complete, your estimate should be two hours. If you think that a project will take three hours, your estimate should be six days, and so on. Now another good rule of thumb is to use Scotty's (from Star Trek) method for estimating; multiply everything by a factor of four. Something that should take two weeks to complete will actually take eight weeks.[/quote]But you left off the best Scotty/Kirk part!Kirk: Mr. Scott, do you always increase your time estimates by a factor of four?Scotty: Of course, Captain! How else can I keep my reputation as a miracle worker!I've always liked the concept of under-promise and over-deliver. And Mark's piece is absolutely brilliant! Since he doesn't remember from where he unabashedly pinched it, I shall with equal unabashment pinch it from him.Fri, 05 Oct 2007 09:22:10 GMTWayne Westhttp://www.sqlservercentral.com/Forums/Topic407174-263-1.aspxI like to use Bob Vila's rule: Take your estimate and double the units of measure. So if you think something will take one minute to complete, your estimate should be two hours. If you think that a project will take three hours, your estimate should be six days, and so on. Now another good rule of thumb is to use Scotty's (from Star Trek) method for estimating; multiply everything by a factor of four. Something that should take two weeks to complete will actually take eight weeks.Fri, 05 Oct 2007 08:27:42 GMTDonald E. Weigendhttp://www.sqlservercentral.com/Forums/Topic407174-263-1.aspxI know I am a terrible estimator; it's definitely something I want to improve. For example, I thought this post would take me one minute to write and it ended up taking me five.But in terms of things that don't take longer than expected, in my experience those tend to be situations where someone else stands to make money. I always dread movie lines, then the next thing I know I'm at the front. The corollary is that getting a refund or exchange almost always takes longer than expected. :w00t:webrunnerFri, 05 Oct 2007 07:41:45 GMTwebrunnerhttp://www.sqlservercentral.com/Forums/Topic407174-263-1.aspx[quote][b]shepton (10/5/2007)[/b][hr]Unashamedly pinched from I can't remember where...If Architects Had To Work Like Software Designers...Dear Mr. Architect:Please design and build me a house. I am not quite sure of what I need, so you should use your discretion. My house should have somewhere between two and forty-five bedrooms. Just make sure the plans are such that the bedrooms can be easily added or deleted. When you bring the blueprints to me, I will make the final decision of what I want. Also, bring me the cost breakdown for each configuration so that I can arbitrarily pick one.Keep in mind that the house I ultimately choose must cost less than the one I am currently living in. Make sure, however, that you correct all the deficiencies that exist in my current house (the floor of my kitchen vibrates when I walk across it, and the walls don't have nearly enough insulation in them).As you design, also keep in mind that I want to keep yearly maintenance costs as low as possible. This should mean the incorporation of extra-cost features like aluminum, vinyl, or composite siding. (If you choose not to specify aluminum, be prepared to explain your decision in detail.)Please take care that modern design practices and the latest materials are used in construction of the house, as I want it to be a showplace for the most up-to-date ideas and methods. Be alerted, however, that kitchen should be designed to accommodate, among other things, my 1952 Gibson refrigerator.To insure that you are building the correct house for our entire family, make certain that you contact each of our children, and also our in-laws. My mother-in-law will have very strong feelings about how the house should be designed, since she visits us at least once a year. Make sure that you weigh all of these options carefully and come to the right decision. I, however, retain the right to overrule any choices that you make.Please don't bother me with small details right now. Your job is to develop the overall plans for the house: get the big picture. At this time, for example, it is not appropriate to be choosing the color of the carpet. However, keep in mind that my wife likes blue.Also, do not worry at this time about acquiring the resources to build the house itself. Your first priority is to develop detailed plans and specifications. Once I approve these plans, however, I would expect the house to be under roof within 48 hours.While you are designing this house specifically for me, keep in mind that sooner or later I will have to sell it to someone else. It therefore should have appeal to a wide variety of potential buyers. Please make sure before you finalize the plans that there is a consensus of the population in my area that they like the features this house has. I advise you to run up and look at my neighbor's house he constructed last year. We like it a great deal. It has many features that we would also like in our new home, particularly the 75-foot swimming pool. With careful engineering, I believe that you can design this into our new house without impacting the final cost.Please prepare a complete set of blueprints. It is not necessary at this time to do the real design, since they will be used only for construction bids. Be advised, however, that you will be held accountable for any increase of construction costs as a result of later design changes.You must be thrilled to be working on as an interesting project as this! To be able to use the latest techniques and materials and to be given such freedom in your designs is something that can't happen very often. Contact me as soon as possible with your complete ideas and plans.PS: My wife has just told me that she disagrees with many of the instructions I've given you in this letter. As architect, it is your responsibility to resolve these differences. I have tried in the past and have been unable to accomplish this. If you can't handle this responsibility, I will have to find another architect.PPS: Perhaps what I need is not a house at all, but a travel trailer. Please advise me as soon as possible if this is the case..Mark[/quote]Now That's FUNNY...Fri, 05 Oct 2007 07:39:49 GMTnoeldhttp://www.sqlservercentral.com/Forums/Topic407174-263-1.aspxNice to see I'm not the only one having issues with estimates. Todd has a nice comment above and I tend to agree with it. With small changes, the overhead is large and can easily overwhelm the change itself. With large changes, it's hard to estimate in detail. I will say that as we've built some software at End to End Training, we tend to discuss it more before we build. Spending 2-3 hours going over features and expectations a few times results in us thinking through what we want with fewer changes down the road. It's very annoying to keep discussing it without seeing progress, but it does seem to help.As for manure, it can easily take longer. Depends on how much hay the horses have eaten :)No comments on my video?Fri, 05 Oct 2007 07:36:11 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic407174-263-1.aspxWhenever I start a project around the house, my wife is quick to remind me that it may become a "[i]Broomhead Project[/i]". That is our official designation for projects that run past the estimates.Like when I had to replace the wax ring of a toilet. Should have been easy but the previous owner used a hammer to bend the floor bolts over. They had been too long and the plastic cap wouldn't fit over them (and hide the bent bolts). The toilet was very close to the wall forcing me to use a mini-hacksaw to cut the bolts.Or when I needed to fix a faucet that started to leak. When I tried to turn off the water with the valve under the sink, the handle just twisted around and around. It was stripped. When I went out to turn off the water supply to the house, the shutoff was buried under about 4 inches of mud. Also, a trip to the store to buy another valve, canister of propane, solder, flux, and copper pipe.The only place that I come close to completing projects on time is at work. Now if I could figure out how to write a program to put new flooring in my kitchen, I might be on-time and under budget :)Fri, 05 Oct 2007 06:44:42 GMTSteven Broomheadhttp://www.sqlservercentral.com/Forums/Topic407174-263-1.aspxJust about the only thing that I can estimate correctly these days is brewing a batch of beer. 4.5 hours from start to finish including cleanup, and 3 weeks later I get to enjoy it...As for everything else, like many of the other posters have mentioned I believe the fact that we underestimate because we're either a) too optimistic or b) don't take into account all of the things that really need completed. For me it's typically a bit of both, and it's something I'm constantly striving to better myself with.-Luke.Fri, 05 Oct 2007 06:41:51 GMTLuke Lhttp://www.sqlservercentral.com/Forums/Topic407174-263-1.aspxActually Jones law is (Douglas) Hofstadter's law, which states recursively"It always takes longer than you expect, even when you take Hofstadter's law into account"Fri, 05 Oct 2007 06:31:38 GMTjay-hhttp://www.sqlservercentral.com/Forums/Topic407174-263-1.aspx[quote]...really carefully analyze all the different tasks that need to be completed for the result as well as prioritizing and sorting them.[/quote]Therein lies the key to estimating! It seems that too often we have a "gut feel" for how long a task should take, and we try to fit everything that needs to be done into that feeling. But if we first break the task down into definable pieces and then estimate each individual piece, the sum of the pieces will become a much more accurate estimate.I've used the following example for years when discussing estimating. You are sitting in a meeting discussing some aspect of your software. A small change is needed, and you know right where that change is required. Someone asks, "How long will that change take?". "Ten minutes" you respond.No, that change will take four hours.Here are the various tasks involved:1. Discuss and agree upon the change2. Log into your system and locate and open the program3. Locate the area in the program where the change needs to occur4. Think through the change carefully to make sure there isn't other impact. May involve a quick look at other code.5. Change the code6. Test the code7. Move the code into whatever change-management system you may have8. The code may have to go through some sort of QA process, with internal analysts and/or customers.9. Document the code change10. Move code change into production11. Final verification that the agreed-upon change is correctly working in production.You could argue the application of some of the points above. The point is, in estimating we too often gloss over all the tasks required to support the primary task (#5 above), and thereby short our estimates right out of the gate.Fri, 05 Oct 2007 04:17:56 GMTTodd Townleyhttp://www.sqlservercentral.com/Forums/Topic407174-263-1.aspxUnashamedly pinched from I can't remember where...If Architects Had To Work Like Software Designers...Dear Mr. Architect:Please design and build me a house. I am not quite sure of what I need, so you should use your discretion. My house should have somewhere between two and forty-five bedrooms. Just make sure the plans are such that the bedrooms can be easily added or deleted. When you bring the blueprints to me, I will make the final decision of what I want. Also, bring me the cost breakdown for each configuration so that I can arbitrarily pick one.Keep in mind that the house I ultimately choose must cost less than the one I am currently living in. Make sure, however, that you correct all the deficiencies that exist in my current house (the floor of my kitchen vibrates when I walk across it, and the walls don't have nearly enough insulation in them).As you design, also keep in mind that I want to keep yearly maintenance costs as low as possible. This should mean the incorporation of extra-cost features like aluminum, vinyl, or composite siding. (If you choose not to specify aluminum, be prepared to explain your decision in detail.)Please take care that modern design practices and the latest materials are used in construction of the house, as I want it to be a showplace for the most up-to-date ideas and methods. Be alerted, however, that kitchen should be designed to accommodate, among other things, my 1952 Gibson refrigerator.To insure that you are building the correct house for our entire family, make certain that you contact each of our children, and also our in-laws. My mother-in-law will have very strong feelings about how the house should be designed, since she visits us at least once a year. Make sure that you weigh all of these options carefully and come to the right decision. I, however, retain the right to overrule any choices that you make.Please don't bother me with small details right now. Your job is to develop the overall plans for the house: get the big picture. At this time, for example, it is not appropriate to be choosing the color of the carpet. However, keep in mind that my wife likes blue.Also, do not worry at this time about acquiring the resources to build the house itself. Your first priority is to develop detailed plans and specifications. Once I approve these plans, however, I would expect the house to be under roof within 48 hours.While you are designing this house specifically for me, keep in mind that sooner or later I will have to sell it to someone else. It therefore should have appeal to a wide variety of potential buyers. Please make sure before you finalize the plans that there is a consensus of the population in my area that they like the features this house has. I advise you to run up and look at my neighbor's house he constructed last year. We like it a great deal. It has many features that we would also like in our new home, particularly the 75-foot swimming pool. With careful engineering, I believe that you can design this into our new house without impacting the final cost.Please prepare a complete set of blueprints. It is not necessary at this time to do the real design, since they will be used only for construction bids. Be advised, however, that you will be held accountable for any increase of construction costs as a result of later design changes.You must be thrilled to be working on as an interesting project as this! To be able to use the latest techniques and materials and to be given such freedom in your designs is something that can't happen very often. Contact me as soon as possible with your complete ideas and plans.PS: My wife has just told me that she disagrees with many of the instructions I've given you in this letter. As architect, it is your responsibility to resolve these differences. I have tried in the past and have been unable to accomplish this. If you can't handle this responsibility, I will have to find another architect.PPS: Perhaps what I need is not a house at all, but a travel trailer. Please advise me as soon as possible if this is the case..MarkFri, 05 Oct 2007 02:21:51 GMTsheptonhttp://www.sqlservercentral.com/Forums/Topic407174-263-1.aspxThe arrival of old age; it's turned up a damn sight quicker :PK.Fri, 05 Oct 2007 02:12:29 GMTKarma-343206http://www.sqlservercentral.com/Forums/Topic407174-263-1.aspxBasically, we're just rubbish at this estimating lark.I also find that when estimating something incorrectly but in the positive way, i.e. you think you'll end up finishing sooner, that I always manage to fill the extra time anyway. Although, that's a good thing, because the extra time and care makes for a better end result.Fri, 05 Oct 2007 01:33:58 GMTMichael Lysonshttp://www.sqlservercentral.com/Forums/Topic407174-263-1.aspxStrangely enough, it rarely takes me longer than planned to travel somewhere. Even before the era of travel planners, I always managed to estimate a good ratio between distance and average speed, allowing for traffic. When I was in the army, we worked with routing/timing tables during manouvers. Has to bring back some memories for you too, Steve :) Those figures must have come from years of experience. I made it good practice to make notice of my experiences in travelling for future reference.In project planning, I find that it helps to make for good planning when calculating back from a deadline, hard deadlines giving better results than soft ones. It forces you to really carefully analyze all the different tasks that need to be completed for the result as well as prioritizing and sorting them. It will soon tell you how much time you have for the different stages and as such, it helps the people you're working with estimating up front if they can handle things in the amount of time given.Fri, 05 Oct 2007 01:15:22 GMTJurriaan Themmen