Software is Like Building a House

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

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

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

  • Loner (10/7/2007)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.

    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.

    ----------------------------------------------------------------------------------
    Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

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

    RBR

  • I 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:

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

  • Michael Valentine Jones (10/5/2007)


    This works well for me

    1. Set delivery date

    2. Do some programming

    3. Test

    4. If test is good, go live, else go live

    5. Define requirements

    6. Repeat 1 through 5 until system is obsolete

    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.

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

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

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

    Dave

  • Thank-you. This was an excellent response. One that I too will borrow!

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

  • Loner (10/8/2007)


    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:

    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.

    Not all gray hairs are Dinosaurs!

  • On 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. 🙂

    Not all gray hairs are Dinosaurs!

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

Viewing 15 posts - 31 through 45 (of 45 total)

You must be logged in to reply to this topic. Login to reply