Advanced C

[James Kuyper]

There's a well-known three-step algorithm for obtaining
realistic project estimates:

1) Ask an experienced engineer how long the job will take.
The answer has a number and a unit of time, for example
"four weeks."

2) Double the number. For the example, this yields "eight
weeks."

3) Advance to the next-larger time unit. The example now
yields "eight months."

... and that's how long a typical four-week project takes. ;-)

So the lesson to be derived from this is that the most accurate time
estimates are those measured in fortnights, while the least accurate
ones are those measured in minutes or seconds.

 

[Stanley Rice]

So do you mean that it will take 8 months to finished a project that would be finished by the experienced engineer in only 4 weeks?

 

[Charles Richmond]

There's a well-known three-step algorithm for obtaining
realistic project estimates:

1) Ask an experienced engineer how long the job will take.
The answer has a number and a unit of time, for example
"four weeks."

2) Double the number. For the example, this yields "eight
weeks."

3) Advance to the next-larger time unit. The example now
yields "eight months."

... and that's how long a typical four-week project takes. ;-)

I always heard it as: "Double it, add one... and go to the next larger unit
of time." By this estimation, it would take nine months.

 

[Charles Richmond]

So do you mean that it will take 8 months to finished a project that would
be finished by the experienced engineer in only 4 weeks?

ISTM that he means... at first, the programmer estimates the project to
take four weeks. But after working on it a while, time grinds on and on...
and it ends up taking at least 8 months!!!

This validates the rule: "The first half of the project takes 90% of the
time, and the second half of the project takes the *other* 90% of the time."

 

[Seebs]

So do you mean that it will take 8 months to finished a project
that would be finished by the experienced engineer in only 4 weeks?

No. It means that it will take 8 months to finish a project that an
experienced engineer *thinks* will only take 4 weeks.

-s

 

[Nick Keighley]

So do you mean that it will take 8 months to finished a project that would be finished by the experienced engineer in only 4 weeks?

these are all jokes based on the oberservation that estimating
software projects is notoriously difficult.

This is partly because software is all desing with virtually no
manufacture. Estimating how long it takes to build something *** once
you have a design *** is much easier than designing a solution to a
novel problem.

The Channel Tunnel, for instance, was 100% overspent on a 1 billion
UKP estimate. You could almost buy a fighter aircraft for that sort of
money.

 

[Malcolm McLean]

these are all jokes based on the oberservation that estimating
software projects is notoriously difficult.

I remember that we were once pitching for an embedded system, a
vending machine. The clinet gave us a list of tasks, and I could see
that there was maybe a week's work there, but all neatly broken down
and timed over several months. Then I spoke with the hardware
engineer, and he said "the first thing to do is to get the port
working. So increment a number. Don't just echo it back to output
because then you can't distinguish it from something wrong in the
hardware." At that point I realised that, though the schedule was pure
fantasy, we weren't going to be in for an easy time.

 

[Geoff]

I remember that we were once pitching for an embedded system, a
vending machine. The clinet gave us a list of tasks, and I could see
that there was maybe a week's work there, but all neatly broken down
and timed over several months. Then I spoke with the hardware
engineer, and he said "the first thing to do is to get the port
working. So increment a number. Don't just echo it back to output
because then you can't distinguish it from something wrong in the
hardware." At that point I realised that, though the schedule was pure
fantasy, we weren't going to be in for an easy time.

Manager: "This project is weeks behind schedule. How many more
programmers do you need?"

Programmer: "That depends, how many more weeks do you want to set it
back?"

 

[Nick Keighley]

these are all jokes based on the oberservation that estimating
software projects is notoriously difficult.

<snip>

Hardware Engineer: "I got a quote from a guy to plaster a wall. He
looked at the condition of the wall, measured the area and did a quick
calculation to give him a price. Why can't software people do that?"

Software Engineer: "we aren't plastering walls."

 

[Bill Cunningham]

Hi Guys... How are you?

So, I would want to learn more about language C, but I want something
more heavy. I'm already from a level medium to hard, but nevertheless
I don't know anything more applied. I don't know about alter some
config in PC, or make a communication with the network of the PC...

I would like of to know about some workbook that speak more this.
What you suggest?

P.S.: Sorry for my english, I'm brazilian.

Socket programming. Signal handling. Threads.

 

[Ralph Spitzner]

"This project is weeks behind schedule. How many more
programmers do you need?"

Programmer: "That depends, how many more weeks do you want to set it
back?"

A friend of mine (who then was in the position to give such an answer)
when asked by the boss "How long until it's done ?" used to say:
"It's done when it's done, so f*ck off until it's done."

-rasp

 

[Malcolm McLean]

Hardware Engineer: "I got a quote from a guy to plaster a wall. He
looked at the condition of the wall, measured the area and did a quick
calculation to give him a price. Why can't software people do that?"

Software Engineer: "we aren't plastering walls."

There were three projects, all estimated at six months.

The first project came in two months later than estimated. Naturally,
the programmers were criticised.

The second project came in two months earlier than estimated. The
programmers were criticised for exaggerating the complexity of the
project.

The third project came in a few days before the six months were up.
The programmers were fired. They'd obviously padded the estimates and
spun out the work to make it look like they were meeting the deadline.

 

[Der Engel]

W R Stevens, yes. It doesn't cover network programming though -- for
that see the first volume of his "Unix network programming" and the
first volume of "TCP/IP illustrated".


And Raymond's "The art of Unix programming". Available on paper, but
also free.

But more on-topic: advanced C is (to me) not about handling weird
programming interfaces or using /all/ of the C language. The thing
I spend most time with is the complexity of large code bases.
- How to understand it all well enough?
- How to make a decent design, reflected in the code?
- How to make it testable?
- How to stop it from deteriorating over the years?

/Jorgen

It looks like APUE2e does really cover network programming:

http://www.apuebook.com/index.html

 

[Mike Manilone]

It looks like APUE2e does really cover network programming:

http://www.apuebook.com/index.html

Advanced C? It seems Clay can be a good choice for system
programming. It's also for application programming.

 

[Tim Rentsch]

So the lesson to be derived from this is that the most accurate time
estimates are those measured in fortnights,

If fortnights are in the set of units under consideration,
then weeks are more accurate than fortnights.

while the least accurate
ones are those measured in minutes or seconds.

Not even close. Estimates in years go to centuries. Estimates
in nanoseconds go to microseconds. But nothing else even comes
close to estimates in Planck times, which go to... I don't know
what, but it's an awful lot of Planck times!