My Dear J -
I went over to look at the links....
this *has* to be designed using parallel processing, nicht war? If so, perhaps the paralellisation is a bottleneck?
are they using flags, semaphores, shared memory, interrupts, wait-states, signals ( unix sig )?
or is it hardware specific, hardware bound or hardware independant? that alone can kill ya as we saw in the days
of the Sun "t-series". code had to be redesigned to take advantage of the "look-ahead" crap, pipes, &etc...
If you can get a look at "the big picture" you can then see where the bottlenecks really occur and where any fixes/changes will actually help.
That "used to be" one of
my specialties.
That part is what I "used to do" before Big Brother Ora castrated our support dept and threw all the sr guys
into the same pool with the newbie phone support people.
It was incredibly frustrating - i felt like the depressed robot on Hitchikers Guide: overqualified and underutilized
having to field "first level" calls from CU in India and China, asking "how do I run this command" and
demanding free consulting and training that was not covered by support contract. The best was to
"teach them how to be a Unix Sys Admin over the phone"
and then explain to them how that is specifically excluded form their support contract, but I would
(gag) be happy to connect them with someone from sales to arrange to sell them a training class...
Then they would fill out a Customer Satisfaction Survey and give you a 1 (fail) out of 10 rating , which the new automatic metrics used to rate you on your job (instead of being rated by an actual manager).
Gawd I'm glad I'm out!
Oh Dear - I looked at their links. Their process is nothing new, same old stuff touted as "new" in the 80's and 90' and 00's, just changed labels:
Agile Software - nothing new, except for the feature where it allows the customer to continuously interfere.
Try that with your plumber and see how it works out.
Extreme Programming: again not much new - except for Pair programming
Pair programming is an agile software development technique in which two programmers work together
at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews
each line of code as it is typed in. The two programmers switch roles frequently
Oh yesssss I love having somebody back-seat driving looking over my shoulder criticizing every choice I make and
every fat finger typo that happens - We can see it works out great with Sheldon on "The Big Bang Theory"
I fear it would end in death and dismemberment!
What actually works better is "ego-less programming and peer review" where the team meets regularly and discusses selected code
without knowing who wrote it.
OMG then I see this:
http://wiki.c2.com/?TruckNumbera bunch of real word Sheldons arguing the semantics over the "Truck Number" - ie exactly how many *essential* people you can afford to lose
on a project and not fail - thru vacation, accident, or "just fed up and f***ing leaving" (probably due to this exact topic being taken seriously) .
The answer is simple-
a) except for a one-man project, no single person is ever irreplaceable - it will cost time, but that's it.
b) dont put all your people in one
basket vehicle
My Dear J -
On second thought, I am (again) glad I am out of it! its just SSDD.
go for the prize, but don't get invovled in the insanity!
yhs
prof marveling that he lived thru it to retire