So, you quietly take the person aside, ask them to ( without attracting attention ) get the game off the screen, and you jolly the photographers and / or distract them for a moment while that happens.
I believe Microsoft has grabbed key people before.
The guy credited with architecting NT, Dave something comes to mind. Also, didnt they hire some Borland developers away? Compiler team guys, cant remember the details.
A: You can drive out a large number and class of bugs from the
component before you begin integration testing. Then you will
be focusing on "more real" bugs.
B: There is nothing that says that the test harness cannot run
multiple threads and test some "real world" type conditions.
I know it will not drive out every integration or real world
bug, but it will be a good start.
Both of these will leave you with less to do when you do start your beta. And yes, you note well that there *will* be bugs found in the wild.
I have done both of the above, and it has been an huge help in delivering software that is robust.
I've worked with code like that in the "language of choice".
Do these introducers never get asked to justify their actions?
I dont see a problem with mixing languages, as long as the choice is a defensible one that moves the project forward. Making project choices on the basis of "gee, this will look cool on my resume", or "gosh, I really want to play with this" on any level ( in language or out ) should, generally, be disallowed.
I believe the parent post meant that the bottom level components will not care if they are called from the real system or from a test harness. So, do the test harness, and use it to test the snot out of that sensitive component.
If you put a mutex on log access, and dont accept the message async, you can end up serializing your app. I.E., dont hold up the caller on logging.
Also, there are application blocks for logging in C#. Dont recall the name of it right off the top of my head.
Another way to solve the timing issue, make it so that you have one app in your system to receive and record the messages. That one app should timestamp the message when it comes in, put it in a queue, and release the caller. Then you dont have the worry about figuring out what happened before and after what. Requires connectivity, but you have that, or you have a fairly easy to debug problem.
Everything that logs should put a unique name on the message, something like App:Module:Function.
Other than those, I think you have hit the high points.
They talk about Google. But it seems to me that they would not single out Google. If they do single out Google, then how will they know Google traffic from other traffic? If they dont single them out, then how will they decide how to bill, and who to bill? And will the additional analysis equipment be worth the costs?
So, others are "yelling loudly", and they then "should" yell even louder. What stops the others from yelling even more loudly, then BMW needs to top that?
And how can google say "dont do this" if they allow BMW to? What makes it OK then?
And how can they distinquish the signal from the noise when the noise looks just like the signal? Because the signal is noisy?
You have kinda a point, but not handling the problem means that the error message will not lead you directly to a solution.
Check for null, check return values, and DO SOMETHING with this information. If you cant recover, report. Then when it crashed in the field, you have something to go on, not a generic segfault report.
Ending up in a catch handler because a reference variable is null ( nothing ) isnt much different from ending up in a catch handler because you dereferenced a null or bad pointer.
And it sounds like he/she/it doesnt want to be able to confidently blame anything, he doesnt want things going wrong in the first place, or to be able to detect and recover when they do.
He needs a great team, and to leave the technology selection to that team, once he has apprised that team of the requirements. If he is serious about this, he will find this team based on experience at building systems under similar constraints. And he will listen to the team on issues of tool selection, testing methodology, schedule, archetecture, platform, etc, etc.
I'm sure he would like a magic bullet, but there isnt one. Care and time are required.
Slashdot Mirror
Quick question:
Does this make you the Grammer Nazi?
Depends on where he/she is in the pyramid scheme.
So, you quietly take the person aside, ask them
to ( without attracting attention ) get the game
off the screen, and you jolly the photographers
and / or distract them for a moment while that
happens.
You can be his former client when you remit that final check.
And not until.
I believe Microsoft has grabbed key people before.
The guy credited with architecting NT, Dave something
comes to mind. Also, didnt they hire some Borland
developers away? Compiler team guys, cant remember
the details.
A: You can drive out a large number and class of bugs from the
component before you begin integration testing. Then you will
be focusing on "more real" bugs.
B: There is nothing that says that the test harness cannot run
multiple threads and test some "real world" type conditions.
I know it will not drive out every integration or real world
bug, but it will be a good start.
Both of these will leave you with less to do when you do start
your beta. And yes, you note well that there *will* be bugs
found in the wild.
I have done both of the above, and it has been an huge help
in delivering software that is robust.
I've worked with code like that in the "language of choice".
Do these introducers never get asked to justify their actions?
I dont see a problem with mixing languages, as long as the
choice is a defensible one that moves the project forward.
Making project choices on the basis of "gee, this will look
cool on my resume", or "gosh, I really want to play with this"
on any level ( in language or out ) should, generally, be
disallowed.
I believe the parent post meant that the bottom level
components will not care if they are called from the
real system or from a test harness. So, do the test
harness, and use it to test the snot out of that
sensitive component.
If you put a mutex on log access, and dont accept the message
async, you can end up serializing your app. I.E., dont
hold up the caller on logging.
Also, there are application blocks for logging in C#.
Dont recall the name of it right off the top of my head.
Another way to solve the timing issue, make it so that you have one
app in your system to receive and record the messages.
That one app should timestamp the message when it comes in,
put it in a queue, and release the caller. Then you dont
have the worry about figuring out what happened before and
after what. Requires connectivity, but you have that, or
you have a fairly easy to debug problem.
Everything that logs should put a unique name on the message,
something like App:Module:Function.
Other than those, I think you have hit the high points.
Excepting the point about the US dollar, your points all seem to me
to be arguments *for* expanding beyond this planet earth.
I respect your position on this, but I cant help but think
that population control will not work long term. Earth is
finite.
That is a good point.
They talk about Google. But it seems to me that they
would not single out Google. If they do single out
Google, then how will they know Google traffic from
other traffic? If they dont single them out, then
how will they decide how to bill, and who to bill?
And will the additional analysis equipment be worth
the costs?
Kinda like trucking companies not shipping until you guarantee them a slice of the profits?
Above and beyond a base minimum, of course.
You, suh, are usin' my client's valuable
Intellectual Property. I demand, yes, I
demand that you turn over 1 beellon-gajillion
dollars.
Or do you want to buy air!
Or lose the cell phones, and get one land line.
Turn off any and all electrical devices not in use.
Pile on the blankets, dont run the heater.
Is that Moe HailStorm?
Hail, hail, Hailstorm woohee!
I agree with you.
So, others are "yelling loudly", and they then "should"
yell even louder. What stops the others from yelling even
more loudly, then BMW needs to top that?
And how can google say "dont do this" if they allow BMW to?
What makes it OK then?
And how can they distinquish the signal from the noise when
the noise looks just like the signal? Because the signal
is noisy?
only helps during the debugging. s/Assert/Check/g
absolutely.
Code review and educate programmers about misuse, where misused.
Dont throw something out automatically, if properly used.
Absolutely. Automate the running of those
tests to the extent possible.
You have kinda a point, but not handling the problem
means that the error message will not lead you directly
to a solution.
Check for null, check return values, and DO SOMETHING
with this information. If you cant recover, report.
Then when it crashed in the field, you have something
to go on, not a generic segfault report.
No, no one else did. Just you. :-)
There is nothing magical about managed code.
Ending up in a catch handler because a reference variable
is null ( nothing ) isnt much different from ending up in
a catch handler because you dereferenced a null or bad
pointer.
And it sounds like he/she/it doesnt want to be able to
confidently blame anything, he doesnt want things
going wrong in the first place, or to be able to detect
and recover when they do.
He needs a great team, and to leave the technology
selection to that team, once he has apprised that
team of the requirements. If he is serious about this,
he will find this team based on experience at building
systems under similar constraints. And he will listen
to the team on issues of tool selection, testing methodology,
schedule, archetecture, platform, etc, etc.
I'm sure he would like a magic bullet, but there isnt one.
Care and time are required.
I read his comment as saying that C# would not guarantee
a good result ( correctness ). And it wont.
What the guy really needs is a great team and some decent
process to backstop that team. Not a silver bullet.
If he could pick the right people, he would :-)
probably never have asked the question...