> The matter at hand isn't hard to understand, so it does me no particular credit to have a grasp of the obvious which you lack. The fact that I understand it and you don't isn't an accomplishment on my part, it's just a failure on your part.
Priceless. Tell me exactly what "particular credit" insulting people in a adult technical discussion where you are wrong gives you ?
The main difference between you and me is that, in the 27 years I spent programming computers, I listened and shared ideas with my peers, which at the end, made me an even better coder. Obviously, you only got good at trolling on the net, which doesn't effectively train one's critical thinking attitude.
> self is a value on the stack. Think about what that means.
It means two things:
First, it means that you don't have the slightest clue about what you are talking about, and you are trying to get away by spouting irrelevant nonsense, and insulting people.
Second, it means it is a different value in both address spaces, of course. This is why I made a distinction between "local self" and "remote self". The _self_returned bit indicates to the local site that the remote site wants local self to be returned. What is hard to understand in the following pseudo code ? :
in sender address space:
id SendMessageToObject( NSProxy theObject,... ) {
Message message =...// Build message
Result result = SendRemoteMessage( message )
if (result._self_returned)
return object// Remote wanted self to be returned
else
(Normal code) }
In remote address space:
while(1)// runloop code in real life {
Request request = GetNextRequest()
Result result = AllocateResult();
id local_object = GetObjectFromRequest( request )
result_object = PerformRequest( request )
if (result_object==local_object)
result._self_returned = YES
else
(normal processing)
SendResult( result )
Deallocate( result ) }
Note that I don't expect you to actually read and understand this post. It will be easier for you to act like a child, close your ears, sing "I can't hear you", and write some additional insults.
> I can see that you've never thought the matter through
I honestly think you should stop being arrogant and actually think about what I posted.
Annotating the return value is unnecessary, as there is no problem in testing for self as a return value:
1) Add a single bit in the return message "_self_returned" 2) Add a test on the remote site after the method had been called, to see if the returned value is exactly equal to the receiver. Set the bit in the returned packet accordingly. 3) In the local sender code, see if "_self_returned" is set, and return local self if it is.
No new annotation, no additional vending, no additional serialization, no additional round trip. Just as I said: removing the "return self" was not necessary for DO performance enhancements.
Ok, I was on holidays, so I couldn't reply earlier.
> If a method has no return value, then NSConnection and NSProxy don't have to serialize and transmit a return value. This is the case for any void method, whether or not it's also declared oneway.
So, the issue is not about the vending, or the round trip, but the serialization ?
But, why on earth would you want to serialize/self/ as a return value ? Do you realize what you are saying ? Self, is/by definition/ already shared by both sides of the connection... Just allocate one bit in the return packet (and there is extra space here) to tell if the return value is self.
Face it: the reason for the suppression of "return self" is better code, not inexistent performance enhancements for DO.
jcr... that ringed a bell to me. John C Randolph, of course. (I don't fully remember. Maybe you worked at NeXT at some point ?)
I do recall that we crossed fire a few time last century over comp.sys.next. You had a few sound ideas (I mean, someone who hates C++ can't be all bad), but an annoying tendency of considering you could never be wrong.
After a quick search through my mailbox, here you are, arguing that NeXT changed "return self" to "void" in foundation kit to "be more efficient with network resources" (which is truly stupid as those methods were not oneway). Still a good laught, even after all those years.
Glad to see you didn't change. You still sound like a I-know-all self-righteous you-know-what...
So you are lucky. My Airport Express needs to be rebooted from time to time (nothing damning, the express sometime stands month without needing it). My previous UFO Apple Airport also needed to be rebooted (and much more frequently than the Express).
The symptom on the Express are that DNS queries stop working. I can ping it, ping my DSL modem, and ping website for which I have IP. I can nslookup into my provider DNS. I cannot lookup into the Express DNS.
Another issue is that sometimes, I start getting more and more lag. Rebooting the mac or the DSL model doesn't fix it. But I discovered, amazed, that rebooting the express fixed it.
Btw "Buy one that works" is an extremely arrogant comment. Those units work for you, it does not prove it works for anyone else.
And, to be clear, I don't believe int he least that we shot down flight 93. There was enough time after the initial attacks that people could communicate with their relatives and, once realizing what was happening, determined action could be taken. A group of pepople fighting in a cockpit could easily throw the plane into an unrecoverable attitude.
Right. It is possible that people organized that fast. Unlikely, but possible... But now, on sep 11th there were report of that missile-like thing in cell phone conversation from flight 93. And, if you think about it, what are the odds of the govt deciding not to shot down the third plane after what happened to the first three?. Pretty slim, if you ask me, pretty slim...
Wrong. Let say you are a software shop (with around 500 "sofware engineers"), with a few hundreds of customers and 50 millions line of code in an obscure language that is more than 20 years old.
Would you call that a detail ?
And when, during those 20 years, every 3 or 5 years some smart ass added yet another part done in another language to the pile, would you still call that a detail ?
And if, when looking at the mess they had, some smart ass decided to dig the company out of the hole by smartly doing external acquisitions, without any regards of the languages used in those, would you still call that a detail ?
And when you look at an end result of 50 million lines in a core obsolete language, with around 50 others million lines of add-on products in around 10 different languages, what would you call that ? A detail ?
The software engineering processes have evolved, the people moved in and out, 6 or 7 generation of tools were used, but the code written 20 years ago is still there, and still needs to be maintained at an unbelievable high cost.
Now, be sure that al the exec that took those brain dead positions had their fat pay check, and made a lot of bonuses running/ruining that company.
For instance, worked at a Java shop on a project that automated deployment of new software which occasionally meant deploying a new version of a JVM. Since much of the deployment code had to run on the server where Java was being deployed to... well Java wouldn't be an appropriate choice.
I don't understand. You should obviously have your deployment code use a separate JVM instance, which would not get upgraded when deploying a new JVM for the business apps.
When I managed developers (after beeing one for 2 decades), my position was: here are the tools, here are the processes, here are the langugages.
If you, as a senior developer, wants to divert from the tools, you can (and I will even pay for them), but you will have to deal with the impedance mismatch yourself (ie: if the developer want to go OSX, he'll get one, but he will also have the hassle of dealing with the OS/tools/etc, the different line termination in source files, the filename case insensitivity issues, the pain of getting oracle working, etc).
If you want to divert from the processes, explain why, and, if it is good, we will update the process for everybody.
If you want to use a different language, well, no (unless very special cases, like embedding lua, for instance).
At the end, such a position on the tools have positives and negatives:
+, dev-side: Developer is happy. Developer works harder and smarter to prove that his choices were the best. +, business-side: Better morale. Better cross-breed of ideas. Lot of alternative ideas for tool progression. Largely more portable code, with less bugs. Sometimes, the fact that a dev have some special tool can be a life-saver (ie: using osx tools to track leaks, for instance) -, dev-side: Spending time on self-inflicted troubles (for instance, it may not be fun to be forced to use Outlook to book meeting rooms, but having to use Outlook inside vmware is worse, or having to maintain a separate makefile from the others). Also, you lack peer experience when running into tool-specific troubles. -, business-side: You sometimes have troubles that you could have avoided. Upgrading the common toolset will have a lot of people screaming around.
This works as long as you have a few dozen devs. I am not sure it scales particulary well.
Anyway, the most important thing to standardize on are the languages, because you can't change that, and you have to maintain previous code. Next are the processes. At one moment everybody must use the same processes, but you can (and must) make them evolve. Last thing are the tools, which can be changed at will.
> Players are given 1 - 5 minutes each to win a game, which generally does not result in a checkmate outcome Do you actually play chess ? Blitz games often ends in checkmate, because the player with the biggest time pressure will blunder.
I have seen my son give otb (=over the board) checkmate in rapid chess to someone 300 ELO higher than him with 3 seconds vs 5 seconds left and 8 moves.
Of course, the player with worst position can choose not to move and lose on time, but it is the stupidest thing to do, because in chess, you can think on the opponent time
Lurk around playchess.com. You'll see 1 minute bullets games (ie: 1 minute for each opponents). The average rate of play is higher than 1 move per second, and they generally finish in checkmate.
PS: slashdot formatting is borken for me. Can' do proper paragraphs. Such is life
> It's written for Windows, you're running OSX? No problem, it'll rewrite itself as an OSX program. Though, that's probably still decades off. But AI seems to me to be the way to ultimate compatibility.
It exists today. It is called LLVM. If you use llvmc to target the LLVM assembly, then you'll get exactly what you say.
I think that it will, one day, replace gcc. Apple already uses it for the iPhone toolchain and the OpenGL stack.
Take a look at llvm: the potential is really amazing.
Well, it is the old host file back, but, with a price tag of 100.000$ a line.
This should limit it quite a bit, and fill some people's pockets with money (which is the point).
Of course, don't expect being able to register any sub-domain in the new domains, it'll belong to companies and very rich individuals.
Do you remember the time when having a.com address was considered ugly (people had.org,.net or.edu..com was for/businesses/, and that was considered evil all over usenet)? I do. Amazing the change monetization can bring to anything...
In the late 90's we stopped using documents with images and text), because they had the following disadvantage:
1) Printable 2) Searchable 3) You could look over them at a glance to find information
We replaced them by the fabulous presentation with voice-over.
It removed part of the ability to scan over information, to search, and to print.
Unfortunately, it still had the disage of letting the user seek to some part of the presentation, so another iteration was needed.
Now, welcome to the 21th century. Thanks to flowgram, you don't have to worry about printing anymore (you can't), or searching (you can't), or even pausing, going forward, or doing anything (you can't).
If you get a phone call in the middle of the presentation, though luck. And of course, you have no way of knowing how long it is, how long is left, or anything. And if you miss a word or a sentence, you can always restart the presentation and listen more carefully the next time.
I must congratulate the folks over flowgram.com. It seems very hard to have some idea that could be less usable. I'm pretty sure there is someone somewhere working hard at this, and some VC will give him money for that, but, for now, if you want to put have a shitty unusbale presentation online, flowgram is the way to go.
> Not too hard to guess what that might have been.
I wonder which would be more ironic:
1) If his ex-wife marry the guy that buy "his life", so she get back the whole lot ("Oh, that is soo sweet, I recovered my friends, my house and my jetski" )
2) If the guy his wife left with win the auction to buy "his life" ("Your taste in women was pretty good, what else do you have?")
> Personally, if I were in the senate right now and the two choices were "stop this from happening going forward, but let the first batch go through" and "nail the guys who did this, but continue to have this fight every time the issue comes up", I might just pick the future over the present.
That is because you are weak. You have to get down HARD on the first that did it as to serve as a deterrent to the others.
What message does this law send to everyone? Well, if you'll get caught, legislative process will get you out one way or another.
> The deck is stacked against anyone who wants to bring the telecoms to court. Next time it won't be.
That is wishful thinking. Next time, next time, next time, forever.
If you only worked under incompetent managers, then I can understand that you are biter.
But you can't hide from the truth: if the software is a multi-millions code line monster, you won't succeed without good management AND good coders. And not with everyone doing everyone else job.
And about the "manager only knowledge", well, you know, the good engineering manager know the whole product, knows exactly the marketing requirements, the product roadmap, and align everything with the company strategy. He knows exactly the state of the development, its quality issues, support issues, etc. You know, because it is his job. That is the "manager only knowledge", that you are so fast to dismiss. Maybe all you ever got were bean-counters PHB managers, in which case, I feel sorry for you.
Btw, my actual title had "VP" in it, but you don't have to believe me...
> Why do most "as a manager" replies in Slashdot are antagonistic?
Because when we post, it is generally because we are exasperated by some bullshit engineer response/justification, hence the posts are generally antagonists.
You wouldn't believe how many time I have been served bullshit arguments to drop useful features from a codebase because of some ego trip from an engineer. Like the "it is too difficult", "it produces support issues", "nobody uses it anymore", and, when you dig into it, you just discover that it is because it was written by a guy they can't fathom that just left the company (or have been promoted to management).
> Inquiring with a curious tone can provide clues of valid issues that are making development more expensive than it needs to be.
Note that the issue here is that you considering this as an employee complain. Well, having to actually perform the work they are paid for cannot be considered a complain. It is a suggestion, and should be treated as such. And, as a manager, you should already know the answers to the 4 questions you are asking him.
But if you start asking for confirmations, you can easily end up where you don't want to go, because the guy may start spewing bullshit arguments. Like:
* "Of course, it does affect the dev cycle, if we keep it we will miss the deadline". Translation is: "If you keep this feature, I will say that it is your fault when we'll miss the deadline (because I am not going to work hard if you don't agree to me)"
* "This features is the longest to test". If you point at data that proves otherwise, the rest will be "Not everything related to that feature is taken into account, you have to factor in the cost of the ocmplexity on the other features, which I estimate out of my ass to 25%"
* "While there are not a lot of defects about this particular feature [because it is not very used], 30% of all other defects comes from the fact that this feature exist. If we remove it the defect rate will come down"
* "Nobody use the feature". If you point to the contrary, the answer will morph into "they don't really want that feature, but something very different that we will have the time to do if we drop that feature"
And, at that point, as a manager, you are fucked. Because if you fight back, you'll be in much worse shape than if you politely said "No, we need to keep this feature because [...]". And the feature will mysteriously become buggier and buggier, and harder and harder to use, etc, etc.
Now, if you carve under the threat, you'll have lost control of the development, the engineer will make you dance on your head, and will end up with a shitty product. You know that, most of the products around suffer form that.
This is why, in respectable software companies, you have product managers that are busy with the marketing aspect "is the feature needed?", engineering managers that are concerned with the "how much does it cost, with everything take into account?" aspect, and architects that have the final say on the "does it technically make sense?".
Note that the engineers have no product responsibility there. Of course, they have very useful input to the managers at stake, but as you don't want me to mess with your code, engineers don't have to mess with management decisions.
Slashdot Mirror
> The matter at hand isn't hard to understand, so it does me no particular credit to have a grasp of the obvious which you lack. The fact that I understand it and you don't isn't an accomplishment on my part, it's just a failure on your part.
Priceless. Tell me exactly what "particular credit" insulting people in a adult technical discussion where you are wrong gives you ?
The main difference between you and me is that, in the 27 years I spent programming computers, I listened and shared ideas with my peers, which at the end, made me an even better coder. Obviously, you only got good at trolling on the net, which doesn't effectively train one's critical thinking attitude.
> self is a value on the stack. Think about what that means.
It means two things:
First, it means that you don't have the slightest clue about what you are talking about, and you are trying to get away by spouting irrelevant nonsense, and insulting people.
Second, it means it is a different value in both address spaces, of course. This is why I made a distinction between "local self" and "remote self". The _self_returned bit indicates to the local site that the remote site wants local self to be returned. What is hard to understand in the following pseudo code ? :
in sender address space:
id SendMessageToObject( NSProxy theObject, ... ) ... // Build message // Remote wanted self to be returned
{
Message message =
Result result = SendRemoteMessage( message )
if (result._self_returned)
return object
else
(Normal code)
}
In remote address space:
while(1) // runloop code in real life
{
Request request = GetNextRequest()
Result result = AllocateResult();
id local_object = GetObjectFromRequest( request )
result_object = PerformRequest( request )
if (result_object==local_object)
result._self_returned = YES
else
(normal processing)
SendResult( result )
Deallocate( result )
}
Note that I don't expect you to actually read and understand this post. It will be easier for you to act like a child, close your ears, sing "I can't hear you", and write some additional insults.
Hi, jcr. Care to get closure on our "return self" thread ?
This is where we left: http://slashdot.org/comments.pl?sid=612415&cid=24271417
> I can see that you've never thought the matter through
I honestly think you should stop being arrogant and actually think about what I posted.
Annotating the return value is unnecessary, as there is no problem in testing for self as a return value:
1) Add a single bit in the return message "_self_returned"
2) Add a test on the remote site after the method had been called, to see if the returned value is exactly equal to the receiver. Set the bit in the returned packet accordingly.
3) In the local sender code, see if "_self_returned" is set, and return local self if it is.
No new annotation, no additional vending, no additional serialization, no additional round trip. Just as I said: removing the "return self" was not necessary for DO performance enhancements.
Ok, I was on holidays, so I couldn't reply earlier.
> If a method has no return value, then NSConnection and NSProxy don't have to serialize and transmit a return value. This is the case for any void method, whether or not it's also declared oneway.
So, the issue is not about the vending, or the round trip, but the serialization ?
But, why on earth would you want to serialize /self/ as a return value ? Do you realize what you are saying ? Self, is /by definition/ already shared by both sides of the connection... Just allocate one bit in the return packet (and there is extra space here) to tell if the return value is self.
Face it: the reason for the suppression of "return self" is better code, not inexistent performance enhancements for DO.
Thanks God I am not David Stes! He was the mother of all morons. I am surprised his name goes through the profanity filter.
Btw, please explain us why "return self" have cost in distributed objects.
- It can't be because of vending, because, by definition, self is already vended.
- It can't be because of additional round trip, because we are not talking about oneway void methods.
So, why is it slower / expensive ?
> Only to ignorant prats like you.
French have a saying that goes "Etre pris pour un idiot aux yeux d'un imbécile est une volupté de fin gourmet". In English, that would translate as "To be seen as an idiot in the eyes of an imbecile is a pleasure worthy of a fine gourmet". Guess why it comes to my mind when I read your posts ?
jcr... that ringed a bell to me. John C Randolph, of course. (I don't fully remember. Maybe you worked at NeXT at some point ?)
I do recall that we crossed fire a few time last century over comp.sys.next. You had a few sound ideas (I mean, someone who hates C++ can't be all bad), but an annoying tendency of considering you could never be wrong.
After a quick search through my mailbox, here you are, arguing that NeXT changed "return self" to "void" in foundation kit to "be more efficient with network resources" (which is truly stupid as those methods were not oneway). Still a good laught, even after all those years.
Glad to see you didn't change. You still sound like a I-know-all self-righteous you-know-what...
So you are lucky. My Airport Express needs to be rebooted from time to time (nothing damning, the express sometime stands month without needing it). My previous UFO Apple Airport also needed to be rebooted (and much more frequently than the Express).
The symptom on the Express are that DNS queries stop working. I can ping it, ping my DSL modem, and ping website for which I have IP. I can nslookup into my provider DNS. I cannot lookup into the Express DNS.
Another issue is that sometimes, I start getting more and more lag. Rebooting the mac or the DSL model doesn't fix it. But I discovered, amazed, that rebooting the express fixed it.
Btw "Buy one that works" is an extremely arrogant comment. Those units work for you, it does not prove it works for anyone else.
And, to be clear, I don't believe int he least that we shot down flight 93. There was enough time after the initial attacks that people could communicate with their relatives and, once realizing what was happening, determined action could be taken. A group of pepople fighting in a cockpit could easily throw the plane into an unrecoverable attitude.
Right. It is possible that people organized that fast. Unlikely, but possible... But now, on sep 11th there were report of that missile-like thing in cell phone conversation from flight 93. And, if you think about it, what are the odds of the govt deciding not to shot down the third plane after what happened to the first three? . Pretty slim, if you ask me, pretty slim...
> Languages are just details
Wrong. Let say you are a software shop (with around 500 "sofware engineers"), with a few hundreds of customers and 50 millions line of code in an obscure language that is more than 20 years old.
Would you call that a detail ?
And when, during those 20 years, every 3 or 5 years some smart ass added yet another part done in another language to the pile, would you still call that a detail ?
And if, when looking at the mess they had, some smart ass decided to dig the company out of the hole by smartly doing external acquisitions, without any regards of the languages used in those, would you still call that a detail ?
And when you look at an end result of 50 million lines in a core obsolete language, with around 50 others million lines of add-on products in around 10 different languages, what would you call that ? A detail ?
The software engineering processes have evolved, the people moved in and out, 6 or 7 generation of tools were used, but the code written 20 years ago is still there, and still needs to be maintained at an unbelievable high cost.
Now, be sure that al the exec that took those brain dead positions had their fat pay check, and made a lot of bonuses running/ruining that company.
For instance, worked at a Java shop on a project that automated deployment of new software which occasionally meant deploying a new version of a JVM. Since much of the deployment code had to run on the server where Java was being deployed to ... well Java wouldn't be an appropriate choice.
I don't understand. You should obviously have your deployment code use a separate JVM instance, which would not get upgraded when deploying a new JVM for the business apps.
When I managed developers (after beeing one for 2 decades), my position was: here are the tools, here are the processes, here are the langugages.
If you, as a senior developer, wants to divert from the tools, you can (and I will even pay for them), but you will have to deal with the impedance mismatch yourself (ie: if the developer want to go OSX, he'll get one, but he will also have the hassle of dealing with the OS/tools/etc, the different line termination in source files, the filename case insensitivity issues, the pain of getting oracle working, etc).
If you want to divert from the processes, explain why, and, if it is good, we will update the process for everybody.
If you want to use a different language, well, no (unless very special cases, like embedding lua, for instance).
At the end, such a position on the tools have positives and negatives:
+, dev-side: Developer is happy. Developer works harder and smarter to prove that his choices were the best.
+, business-side: Better morale. Better cross-breed of ideas. Lot of alternative ideas for tool progression. Largely more portable code, with less bugs. Sometimes, the fact that a dev have some special tool can be a life-saver (ie: using osx tools to track leaks, for instance)
-, dev-side: Spending time on self-inflicted troubles (for instance, it may not be fun to be forced to use Outlook to book meeting rooms, but having to use Outlook inside vmware is worse, or having to maintain a separate makefile from the others). Also, you lack peer experience when running into tool-specific troubles.
-, business-side: You sometimes have troubles that you could have avoided. Upgrading the common toolset will have a lot of people screaming around.
This works as long as you have a few dozen devs. I am not sure it scales particulary well.
Anyway, the most important thing to standardize on are the languages, because you can't change that, and you have to maintain previous code. Next are the processes. At one moment everybody must use the same processes, but you can (and must) make them evolve. Last thing are the tools, which can be changed at will.
Warning: at Subject, line 1: condition always evaluates to true
> Players are given 1 - 5 minutes each to win a game, which generally does not result in a checkmate outcome
Do you actually play chess ? Blitz games often ends in checkmate, because the player with the biggest time pressure will blunder.
I have seen my son give otb (=over the board) checkmate in rapid chess to someone 300 ELO higher than him with 3 seconds vs 5 seconds left and 8 moves.
Of course, the player with worst position can choose not to move and lose on time, but it is the stupidest thing to do, because in chess, you can think on the opponent time
Just look at the tie-break in US women championship. 11 seconds vs 2 seconds. Wanna bet who won ?
Lurk around playchess.com. You'll see 1 minute bullets games (ie: 1 minute for each opponents). The average rate of play is higher than 1 move per second, and they generally finish in checkmate.
PS: slashdot formatting is borken for me. Can' do proper paragraphs. Such is life
Here you go
And here, at the bottom of the page, you can see an exhibition chessboxing by the FIDE (ie: Federarion Internationale Des Echecs aka: World Chess Federation) president
> It's written for Windows, you're running OSX? No problem, it'll rewrite itself as an OSX program. Though, that's probably still decades off. But AI seems to me to be the way to ultimate compatibility.
It exists today. It is called LLVM. If you use llvmc to target the LLVM assembly, then you'll get exactly what you say.
I think that it will, one day, replace gcc. Apple already uses it for the iPhone toolchain and the OpenGL stack.
Take a look at llvm: the potential is really amazing.
> > The amazing discovery they made is that when people had time to think about a question, they gave better answers. This is profound.
> I don't think so. Thinking about a question is anti-american due to the lack of truthiness in such answers.
Mmm. Now that I had the time to think about it, I tend to agree with you.
This is, indeed, profound.
> The amazing discovery they made is that when people had time to think about a question, they gave better answers. This is profound.
I don't think so. Thinking about a question is anti-american due to the lack of truthiness in such answers.
Well, it is the old host file back, but, with a price tag of 100.000$ a line.
This should limit it quite a bit, and fill some people's pockets with money (which is the point).
Of course, don't expect being able to register any sub-domain in the new domains, it'll belong to companies and very rich individuals.
Do you remember the time when having a .com address was considered ugly (people had .org, .net or .edu. .com was for /businesses/, and that was considered evil all over usenet)? I do. Amazing the change monetization can bring to anything...
Lucky you, using FF2 on Mac OS X, with flash player 9, there was none of that...
In the late 90's we stopped using documents with images and text), because they had the following disadvantage:
1) Printable
2) Searchable
3) You could look over them at a glance to find information
We replaced them by the fabulous presentation with voice-over.
It removed part of the ability to scan over information, to search, and to print.
Unfortunately, it still had the disage of letting the user seek to some part of the presentation, so another iteration was needed.
Now, welcome to the 21th century. Thanks to flowgram, you don't have to worry about printing anymore (you can't), or searching (you can't), or even pausing, going forward, or doing anything (you can't).
If you get a phone call in the middle of the presentation, though luck. And of course, you have no way of knowing how long it is, how long is left, or anything. And if you miss a word or a sentence, you can always restart the presentation and listen more carefully the next time.
I must congratulate the folks over flowgram.com. It seems very hard to have some idea that could be less usable. I'm pretty sure there is someone somewhere working hard at this, and some VC will give him money for that, but, for now, if you want to put have a shitty unusbale presentation online, flowgram is the way to go.
> Not too hard to guess what that might have been.
I wonder which would be more ironic:
1) If his ex-wife marry the guy that buy "his life", so she get back the whole lot ("Oh, that is soo sweet, I recovered my friends, my house and my jetski" )
2) If the guy his wife left with win the auction to buy "his life" ("Your taste in women was pretty good, what else do you have?")
> Personally, if I were in the senate right now and the two choices were "stop this from happening going forward, but let the first batch go through" and "nail the guys who did this, but continue to have this fight every time the issue comes up", I might just pick the future over the present.
That is because you are weak. You have to get down HARD on the first that did it as to serve as a deterrent to the others.
What message does this law send to everyone? Well, if you'll get caught, legislative process will get you out one way or another.
> The deck is stacked against anyone who wants to bring the telecoms to court. Next time it won't be.
That is wishful thinking. Next time, next time, next time, forever.
If you only worked under incompetent managers, then I can understand that you are biter.
But you can't hide from the truth: if the software is a multi-millions code line monster, you won't succeed without good management AND good coders. And not with everyone doing everyone else job.
And about the "manager only knowledge", well, you know, the good engineering manager know the whole product, knows exactly the marketing requirements, the product roadmap, and align everything with the company strategy. He knows exactly the state of the development, its quality issues, support issues, etc. You know, because it is his job. That is the "manager only knowledge", that you are so fast to dismiss. Maybe all you ever got were bean-counters PHB managers, in which case, I feel sorry for you.
Btw, my actual title had "VP" in it, but you don't have to believe me...
> Why do most "as a manager" replies in Slashdot are antagonistic?
:-)
Because when we post, it is generally because we are exasperated by some bullshit engineer response/justification, hence the posts are generally antagonists.
You wouldn't believe how many time I have been served bullshit arguments to drop useful features from a codebase because of some ego trip from an engineer. Like the "it is too difficult", "it produces support issues", "nobody uses it anymore", and, when you dig into it, you just discover that it is because it was written by a guy they can't fathom that just left the company (or have been promoted to management).
> Inquiring with a curious tone can provide clues of valid issues that are making development more expensive than it needs to be.
Note that the issue here is that you considering this as an employee complain. Well, having to actually perform the work they are paid for cannot be considered a complain. It is a suggestion, and should be treated as such. And, as a manager, you should already know the answers to the 4 questions you are asking him.
But if you start asking for confirmations, you can easily end up where you don't want to go, because the guy may start spewing bullshit arguments. Like:
* "Of course, it does affect the dev cycle, if we keep it we will miss the deadline". Translation is: "If you keep this feature, I will say that it is your fault when we'll miss the deadline (because I am not going to work hard if you don't agree to me)"
* "This features is the longest to test". If you point at data that proves otherwise, the rest will be "Not everything related to that feature is taken into account, you have to factor in the cost of the ocmplexity on the other features, which I estimate out of my ass to 25%"
* "While there are not a lot of defects about this particular feature [because it is not very used], 30% of all other defects comes from the fact that this feature exist. If we remove it the defect rate will come down"
* "Nobody use the feature". If you point to the contrary, the answer will morph into "they don't really want that feature, but something very different that we will have the time to do if we drop that feature"
And, at that point, as a manager, you are fucked. Because if you fight back, you'll be in much worse shape than if you politely said "No, we need to keep this feature because [...]". And the feature will mysteriously become buggier and buggier, and harder and harder to use, etc, etc.
Now, if you carve under the threat, you'll have lost control of the development, the engineer will make you dance on your head, and will end up with a shitty product. You know that, most of the products around suffer form that.
This is why, in respectable software companies, you have product managers that are busy with the marketing aspect "is the feature needed?", engineering managers that are concerned with the "how much does it cost, with everything take into account?" aspect, and architects that have the final say on the "does it technically make sense?".
Note that the engineers have no product responsibility there. Of course, they have very useful input to the managers at stake, but as you don't want me to mess with your code, engineers don't have to mess with management decisions.
And sorry if that post seems antagonist...