Software engineers: How do you estimate a project you've never implemented before?

[Descartes]

As senior software engineer for my company, I'm often faced with assimilating a new platform, or language, or tool as part of a project. Some of these projects are so out of our niche that I haven't the slightest idea as to how long it will take to implement. I can approximate, but then I get chastised when I don't hit the approximation (guess that throws away the idea of an approximation). For example, our next project entails writing a custom application for the Pocket PC to be run on Symbol's portable barcode scanners, have that interface directly with a backoffice system on an old SCO box, and allow the batch transfer of items scanned via a serial link. Ok, great! Now, Symbol has an SDK that's fairly lucid, but I still have to learn the API. I may wind up having to write some daemon for SCO to facilitate the serial transfers, I'm not entirely sure yet.

Point is, how the hell can I accurately estimate this? Anyone else been in situations like these? It's very aggrivating to be expected to know something before I've had any time to research. I tried to research, but then I get, "why's it taking so long to create the estimate?" ARGH!

 

[teddymines]

You could start off with an SDLC that lends itself well for dealing with the unknown. I'd recommend a spiral model where you introduce a phased approach to adding functionality at milestones, then gain approval before proceeding.

Are your requirements complete, or are you tasked with evolving this from feasibility? If the latter is the case, I'd recommend exploratory programming, where you prototype and look for head nods from your customers. This is a good way to create requirements from nothing.

As for your estimates, assuming you're going with the spiral model, you could make WAGs for initial investigation, then for each trun of the spiral. Investigative milestones could include initial high-level requirements (if any), high-level architecture, documentation analysis (like the API's, development tools, etc.). Then milestone each spiral evolution. Turn #1 may be getting the Pocket PC ported into the barcode scanner. Turn #2 may be adding data transfer, etc.

Each milestone should include a confidence level (may be 50% or lower to start out with) and become refined as the schedule executes. For example, you will want to add verification and approval to each milestone. You'll also need time to append to your requirements base. Hopefully by the last few turns, your confidence level will be around 90% due to your experience with the system.

Hope this helps a little!

 

[UglyCasanova]

I am pretty sure that I am going to major in CS (still a senior in HS). Do you enjoy it? What is a basic day like? I know this is going off topic of your original post, but I am very curious and have been trying to find out as much about the field as you can. Anyways, I gotta go to work now to earn some $$$ for college tuition.

 

[AmigaMan]

I remember reading a /. article about software estimation and how it's almost impossible to predict accurately.
Link

 

[Kev]

just go hide in a corner under a pile of coats, and don't come out until its all been done for you.

 

[Ameesh]

i have had similar problems, what i do is try to map out how many man hours it would take me to learn the technology (best guess) and make those into 8 hour days with a 15% buffer that way if i estimated say 15 days to get something done in my mind im thinking it will only take 12, in that 12 i work longer days then 8 hours to make the learning phase go faster, so by day 10 im done with development and i start unit and stress testing by day 12 i know if im ready or i have found bugs which gives me the oppotunity to either turn it in early after being tested (day 12) or turn it in on time after i have fixed the bugs i havee found.


have you ever written for windows? or are you just a unix shop primarly?

 

[Descartes]

<< I am pretty sure that I am going to major in CS (still a senior in HS). Do you enjoy it? >>



I enjoy it very much, actually. I know it might be hard to tell from my post, but I wouldn't want to do anything else. I love the challenges of coming up w/ solutions, it's just that I often feel encumbered by the "business" side of things (typically referred to as the Dilbert principle). I started programming for fun, and I still do so on side projects.

What is a basic day like? I know this is going off topic of your original post, but I am very curious and have been trying to find out as much about the field as you can. Anyways, I gotta go to work now to earn some $$$ for college tuition. [/i] >>






<< What is a basic day like? >>



I'm usually doing one of several things: coding, designing, interfacing with customers, eating a bagel, or pacing around my office. I spend at least 20% of my time doing R&D work as well. Recently, as noted above, we're doing some barcoding integration stuff, so I'm doing a lot with that as well. Basically, if a client has a problem, and there is any means to integrate with it whatsoever, we will do so. Because of that, we're often faced with the unknown, so we have to approximate.

I would say it does take a bit of an introvert to hold a job like this, as I'm often "zoned" out for many hours at a time during the day with total disregard for anyone elses existence. I love it though, and it can only get better.

 

[CSoup]

<< I am pretty sure that I am going to major in CS (still a senior in HS). Do you enjoy it? What is a basic day like? I know this is going off topic of your original post, but I am very curious and have been trying to find out as much about the field as you can. Anyways, I gotta go to work now to earn some $$$ for college tuition. >>



One thing you have to be carful about is that CS != Software Engineering != programming.

 

[Descartes]

Ameesh: Your approach is more or less what I've attempted to convey to the powers that be, but they want more concrete estimates for that which is enigmatic. Hopefully things will change once all see that this isn't the best approach.



<< have you ever written for windows? or are you just a unix shop primarly? >>



I work primarily in windows, but we have a lot of clients on *nix as well (sco, aix, linux, etc.). Our company sells a backoffice platform that actually runs natively on unix, so I'm often writing a means to integrate the two platforms. I will target windows unless requested otherwise.

 

[Descartes]

<< One thing you have to be carful about is that CS != Software Engineering != programming. >>



While that's true, I would find it difficult to argue that CS suits you more appropriately for anything other than being a software engineer (or any of it's related disciplines).

 

[Rickr]

Basically, you are screwed. If your managers don't understand that some projects cannot be estimated without doing some R&D first, you simply cannot win. My suggestion is to make your best quick guess, then multiply by three.

And keep a copy of "If You Give a Mouse a Cookie" on your desk.

PS, I had responsibilities similar to yours for about 10 years. I finally quit, and got basically a "programming" job. Anytime a suit asks for an estimate for the impossible, I have them talk to my boss. Most folks at work think I'm the surliest SOB they've ever seen, which is very funny as it is all an act. My bosses love me because I always do exactly what they want- on time, on budget.

 

[CSoup]

<<

<< One thing you have to be carful about is that CS != Software Engineering != programming. >>



While that's true, I would find it difficult to argue that CS suits you more appropriately for anything other than being a software engineer (or any of it's related disciplines). >>



I agree that for most CS majors, software engineering is a good fit. But I know plenty of CS majors who are more interested in the theoretical side of CS and also plenty who graduated without understanding either sides of CS.

Also, if a person is not interested in the theoretical and mathematical sides of CS, but are interested in the engineering side, they might be better suited in a program more geared towards design and programming.

 

[EagleKeeper]

Break each identified task into functional pieces.
Come up with a battle plan in three phases, research, development, implimentation.

Determine estimated time needed for researching each piece - technology. Research
Use your experience with the existing systems for a estimate to the design each piece or ask others you are familiar. Development

Again then come up with an estimate for impliment based on the size of the project. Implimentation

Then double the estimates and present it with a disclaimer.

 

[StageLeft]

Use your best guess, double it, and then try madly to meet the deadline that you gave them

EDIT: The above written before seeing that eaglekeeper said the same !