Of course I understand what the parent poster said. I've worked on real-time kernel based clustered applications. First off, you're assuming unit tests will find all bugs. Bad assumption. It's just another tool in the toolbox; it's not perfect. Nothing is. Second, if one is saying they cannot test a real-time application then they're not building scaffolding code right. Third, it is true there are synchronization and hardware scenarios that cannot be tested with unit tests because the scenario only exists in an integrated environment or when there are multiple nodes. No one is saying you're supposed to perform integration testing with unit testing. That would be retarded and represent a total misunderstanding of what a unit test is and what it's used for. Using the real-time excuse to avoid testing the 60% to 90% of your code which generally consists of primitives, containers, and general purpose code is just an excuse to be a lazy, sloppy programmer.
I think there's a difference between intelligence and consciousness. We can think of an algorithm as being created to make decisions by selecting the option with the best outcome so even though it's not consciously self-aware it can make decisions we would recognize as intelligent.
we don't even really know what human intelligence is
It doesn't matter. We still measure it. IQ tests; exams testing knowledge, memory, comprehension skills; etc. There are lots of things we measure but don't understand.
Unit tests should be trivial for the majority of classes. Good OO design will cause your many of your classes to be single purpose and simplistic therefore the unit tests will also be simplistic. That's the point of OOD (or even modular design)--breaking down complex problems into many simpler problems*.
Maybe you should consider that unit testing is not just for validating the current set of objects but also validating that future revisions do not break compatibility. In other words it makes regression testing possible or easier with automation.
Writing the unit tests also serve to prove to your teammates you've thought about boundary conditions and logic errors. When you're forced to think them in a structured way then you're in a better position to catch code bugs while writing the unit tests. Many times you'll find them before even executing the test code.
Note: If anyone responds with something along the lines of "complex problems cannot always be simplified" I will literally punch you--repeatedly.
I've used scrum for over a year now, so my opinion is colored by that. It's my opinion that scrum works quite well in terms of productivity but it has two major problems. It takes most the fun out of development and turns IT work into a daily grind of task processing fed from an infinite treadmill. The second is it kills inventiveness.
Why do I say that? Well, scrum prioritizes tasks by importance and not by tasks you're interested in working on. On teams I was on the task priority was simplistic and based on three things: 1) the seniority and level of the requestor, 2) the number of systems impacted by the bug, and lastly 3) the nature of a feature enhancement. #1 is usually turns out to be a waste of time (I call it the boss tax.) #2 is usually very hard and quite monotonous. #3 is the source of fun tasks. Since operations work always ends up trumping enhancement work, feature requests get pushed into the future so you're always chasing the day when you actually get to do interesting work. It doesn't come often.
Scrum is a team collaboration effort so stories added to the board must be justified. It's not enough to justify a task with "...because I want to work on it and I have cool ideas to try out..." or "the code base needs refactoring and I have some ideas how to craft it better". It will be summarily rejected by your teammates because they will chant "we must stick to the priorities". That is the precise moment when scrum kills invention.
Sometimes we need a mental Scoobie snack and need to work on interesting things in order to prevent burn out. I don't think it's to the team's advantage to ignore that. All the great ideas were developed by those interested in the particular problem and many were developed by those who momentarily ignored their peers and the bureaucratic system of control.
What I described is classic thread starvation problem due to a simplistic scheduler implementation. We have 3 threads but each is given different priority. In our example, it's thread 3 that never gets CPU time. The way you break free to give yourself time to innovate is to ignore the system and show your work after your prototype is complete. This may mean locking yourself away for a few days until your work is done. It may mean getting a negative review or worse getting fired. If the system of managing software development penalizes you for developing innovation, then the system is the problem.
As I said earlier scrum works well but only when metered and executed properly but who pulls that off? For example the schedule must allocate time between sprints for the sprints to be effective. The in-between time is critical for performing non-scheduled activities. Of course that lasts until a manager sees the schedule and says "hey why is there all this idle time between sprints?" which inevitably results with the "brilliant" observation that butting sprints against each other will "boost productivity". Sprints are a great idea so why not make every day a sprint day right?
Over the year we got a lot done so on paper we were very effective and productive, but it came with a cost--never ending recruitment and over taxed, under staffed teams. In the last 18 months my team has experienced 50% turnover. One teammate moved to another team and 2 others left the company. From what I can gather the story was the same during the previous 18 month block of time. You have to understand this is a big deal because in this company 100 resumes results in 1 phone screen; 100 phone screens result in 1 offer. It will take 6 to 9 months to replace the missing three so the remaining 3 teammates are facing those months of supporting 3 very large complex systems while simultaneously trying to do new development while on pager duty. For one of those 3 systems no one understands it because it requires specific technology experience and the 2 domain experts left. When the new hires come on of course there will more time wasted on training.
Is that the 3rd actual use for the ipad? Portable electronic sketch pad. Too bad no stylus though. It's easier to sketch with a pencil like stylus. Given 1st is glorified MP3 player and 2nd book reader.
I find it funny that many put down cowboy coding as an atrocity--worst of the worst sins, but how come many revenue positive startups are built on top of cowboy code? It's because it works if the developers are good and passionate, but if not the code churned out will be a mess of spaghetti. Corporate profitability is priority #1--not code quality. Code quality is probably #3 or #4 on the list.
I'm not sure I understand what the big deal is with worrying about some "pendulum". Sometimes I have time; sometimes I don't. (Given hard means it requires more time.) I just like games. It's not an either or proposition.
There is nothing to worry about here. The casual game market was just an expansion to reach a previously ignored segment of players: the very old, the very young, and the very busy. Your hard games aren't going away any time soon and neither will your easy games. Stop fretting over it.
Yes. I can blame them and I do--harshly. This is a forum for ideas and debate--not a forum for devising critical computer algorithms. Although syntax parsing may be precise, it's a very unforgiving mode of thinking and highly irritating when done by humans because it's indicative of a poorly developed ability for abstract thought. Near perfect emulation of algorithmic processing is not what I consider to be a rich form of intelligence; it is robotic intelligence.
Abstract intelligence is the one that's superior because it's capable of comprehension even when the information stream is noisy, irregular, or ambiguous. Abstract thought can exceed expectations; robotic thought can only meet expectations.
What's with the obsession with parsing words around here? Jesus. You guys are getting out of hand. I think it was clear the OP was not saying "at the same time". It was clear he was describing cause and effect over time. Apply a little intelligence the next time you read.
Re-read my post and stop making up lies. I said we support the ones that come with better testing tools. We support Firefox, Safari, and Opera. There is no concerted effort not to support IE. This is very different from a top-down corporate mandate for IE only support. Apparently I have to repeat myself for this to sink in with you. We just don't have the time.
Or were you ignoring the fact that for several years IE6 was basically the only choice for a free browser
I'm sick of these table debates so let's cut to the chase. The answer is CSS is deficient so sometimes tables are needed but they should be avoided where possible. Pass this answer around so we can stop these stupid, incessant CSS versus HTML table debates and retarded generalizations such as "you should never use tables" comments.
You probably commute to work and do all your shopping in a car (or perhaps the bus/train/whatever) which is a type of mechanical mule. How come it is that you don't use a horse and buggy for doing all those tasks? The answer is the same for both cases.
The strange thing is where I work IE is the least supported internally. Developers here don't support it for the main reason that it consumes too much precious time to make it work right due to non-standards and very painful testing tools. It's not due to anti-MS sentiment. We just don't have the time. When your schedule is overloaded the natural tendency is to cut the more difficult platforms and do primary support on the ones that come with better testing tools and tend to work right on the first try.
For any organization still boxed in with IE6 or IE7 then I say they were arrogant and ignorant and now they're getting their just deserts. These were the crusty companies with idiot managers dictating technical standards--not a good sign when doing the job search. Unless the option is going jobless and hungry, I will avoid pursuing a job with them like the plague.
Naive attitude. This is a sovereign nation with borders and the right to self-preservation so placing controls on who can enter falls entirely within those rights. You are advocating opening the flood gates and creating a free-for-all by letting anyone in who merely requests entry--essentially nullifying the impact of controlled, selective, and orderly immigration. A massive, sudden swell of immigrants is a disruptive force on the economy due to the finite availability of jobs, housing, and public services. We need immigration controls to throttle the incoming rate so that markets can self-adjust. Case in point: average salaries for carpenters in the American south west plummeted due to unfettered Mexican migrant workers. In 1980, wages were $15 to $17/hour. In 2005, $12 to $15/hour.
Your utopian plan will never be adopted by Americans because it is just plain stupid.
Now. I can't speak for the performing arts and fashion design. Some say the correlation exists there. I just didn't see it in any drawing, painting, ceramics, etc classes.
Actually, there is some correlation between creativity and homosexuality; you'll find a larger percentage of gays in art school than studying any other discipline
I took some art courses working on an undergrad Fine Arts program at 2 different colleges and I didn't see an unusually high number of gay students. I honestly don't know what you're talking about. I suspect you're peddling bullshit stereotypes you picked up from watching some lousy TV sitcoms.
New hires come on and get the "honor" of maintaining the system.
If only that happened in reality. Here's what really happens:
A core set of developers develop some convoluted flaky system and end up moving to to other teams to work on something else. New hires come on and get the "honor" of maintaining said system. What you end up with is a bunch of recruits barely familiar with the code supporting the oncall. They continue beating their heads with resolving tickets and doing mundane band-aid deployments for a year before they quit or suffer performance problems due to burn out.
Slashdot Mirror
Of course I understand what the parent poster said. I've worked on real-time kernel based clustered applications. First off, you're assuming unit tests will find all bugs. Bad assumption. It's just another tool in the toolbox; it's not perfect. Nothing is. Second, if one is saying they cannot test a real-time application then they're not building scaffolding code right. Third, it is true there are synchronization and hardware scenarios that cannot be tested with unit tests because the scenario only exists in an integrated environment or when there are multiple nodes. No one is saying you're supposed to perform integration testing with unit testing. That would be retarded and represent a total misunderstanding of what a unit test is and what it's used for. Using the real-time excuse to avoid testing the 60% to 90% of your code which generally consists of primitives, containers, and general purpose code is just an excuse to be a lazy, sloppy programmer.
I think there's a difference between intelligence and consciousness. We can think of an algorithm as being created to make decisions by selecting the option with the best outcome so even though it's not consciously self-aware it can make decisions we would recognize as intelligent.
It doesn't matter. We still measure it. IQ tests; exams testing knowledge, memory, comprehension skills; etc. There are lots of things we measure but don't understand.
Unit tests should be trivial for the majority of classes. Good OO design will cause your many of your classes to be single purpose and simplistic therefore the unit tests will also be simplistic. That's the point of OOD (or even modular design)--breaking down complex problems into many simpler problems*.
Maybe you should consider that unit testing is not just for validating the current set of objects but also validating that future revisions do not break compatibility. In other words it makes regression testing possible or easier with automation.
Writing the unit tests also serve to prove to your teammates you've thought about boundary conditions and logic errors. When you're forced to think them in a structured way then you're in a better position to catch code bugs while writing the unit tests. Many times you'll find them before even executing the test code.
Note: If anyone responds with something along the lines of "complex problems cannot always be simplified" I will literally punch you--repeatedly.
I've used scrum for over a year now, so my opinion is colored by that. It's my opinion that scrum works quite well in terms of productivity but it has two major problems. It takes most the fun out of development and turns IT work into a daily grind of task processing fed from an infinite treadmill. The second is it kills inventiveness.
Why do I say that? Well, scrum prioritizes tasks by importance and not by tasks you're interested in working on. On teams I was on the task priority was simplistic and based on three things: 1) the seniority and level of the requestor, 2) the number of systems impacted by the bug, and lastly 3) the nature of a feature enhancement. #1 is usually turns out to be a waste of time (I call it the boss tax.) #2 is usually very hard and quite monotonous. #3 is the source of fun tasks. Since operations work always ends up trumping enhancement work, feature requests get pushed into the future so you're always chasing the day when you actually get to do interesting work. It doesn't come often.
Scrum is a team collaboration effort so stories added to the board must be justified. It's not enough to justify a task with "...because I want to work on it and I have cool ideas to try out..." or "the code base needs refactoring and I have some ideas how to craft it better". It will be summarily rejected by your teammates because they will chant "we must stick to the priorities". That is the precise moment when scrum kills invention.
Sometimes we need a mental Scoobie snack and need to work on interesting things in order to prevent burn out. I don't think it's to the team's advantage to ignore that. All the great ideas were developed by those interested in the particular problem and many were developed by those who momentarily ignored their peers and the bureaucratic system of control.
What I described is classic thread starvation problem due to a simplistic scheduler implementation. We have 3 threads but each is given different priority. In our example, it's thread 3 that never gets CPU time. The way you break free to give yourself time to innovate is to ignore the system and show your work after your prototype is complete. This may mean locking yourself away for a few days until your work is done. It may mean getting a negative review or worse getting fired. If the system of managing software development penalizes you for developing innovation, then the system is the problem.
As I said earlier scrum works well but only when metered and executed properly but who pulls that off? For example the schedule must allocate time between sprints for the sprints to be effective. The in-between time is critical for performing non-scheduled activities. Of course that lasts until a manager sees the schedule and says "hey why is there all this idle time between sprints?" which inevitably results with the "brilliant" observation that butting sprints against each other will "boost productivity". Sprints are a great idea so why not make every day a sprint day right?
Over the year we got a lot done so on paper we were very effective and productive, but it came with a cost--never ending recruitment and over taxed, under staffed teams. In the last 18 months my team has experienced 50% turnover. One teammate moved to another team and 2 others left the company. From what I can gather the story was the same during the previous 18 month block of time. You have to understand this is a big deal because in this company 100 resumes results in 1 phone screen; 100 phone screens result in 1 offer. It will take 6 to 9 months to replace the missing three so the remaining 3 teammates are facing those months of supporting 3 very large complex systems while simultaneously trying to do new development while on pager duty. For one of those 3 systems no one understands it because it requires specific technology experience and the 2 domain experts left. When the new hires come on of course there will more time wasted on training.
Related but with Microsoft as an example instead. Anyone think Bill Gates could pass the Microsoft SDE interview process?
Stylus. Yet one more thing left out of the iPad. ;)
Heavens. I offended the Apple Gods. LOL. Regardless, it was a serious post at the time I wrote it. :) I forgot how sensitive the fan boys were.
Is that the 3rd actual use for the ipad? Portable electronic sketch pad. Too bad no stylus though. It's easier to sketch with a pencil like stylus. Given 1st is glorified MP3 player and 2nd book reader.
I find it funny that many put down cowboy coding as an atrocity--worst of the worst sins, but how come many revenue positive startups are built on top of cowboy code? It's because it works if the developers are good and passionate, but if not the code churned out will be a mess of spaghetti. Corporate profitability is priority #1--not code quality. Code quality is probably #3 or #4 on the list.
yer tryin to sell shit to people who think everything is free. Duh.
I'm not sure I understand what the big deal is with worrying about some "pendulum". Sometimes I have time; sometimes I don't. (Given hard means it requires more time.) I just like games. It's not an either or proposition.
There is nothing to worry about here. The casual game market was just an expansion to reach a previously ignored segment of players: the very old, the very young, and the very busy. Your hard games aren't going away any time soon and neither will your easy games. Stop fretting over it.
Yes. I can blame them and I do--harshly. This is a forum for ideas and debate--not a forum for devising critical computer algorithms. Although syntax parsing may be precise, it's a very unforgiving mode of thinking and highly irritating when done by humans because it's indicative of a poorly developed ability for abstract thought. Near perfect emulation of algorithmic processing is not what I consider to be a rich form of intelligence; it is robotic intelligence.
Abstract intelligence is the one that's superior because it's capable of comprehension even when the information stream is noisy, irregular, or ambiguous. Abstract thought can exceed expectations; robotic thought can only meet expectations.
Come on.
What's with the obsession with parsing words around here? Jesus. You guys are getting out of hand. I think it was clear the OP was not saying "at the same time". It was clear he was describing cause and effect over time. Apply a little intelligence the next time you read.
Re-read my post and stop making up lies. I said we support the ones that come with better testing tools. We support Firefox, Safari, and Opera. There is no concerted effort not to support IE. This is very different from a top-down corporate mandate for IE only support. Apparently I have to repeat myself for this to sink in with you. We just don't have the time.
You are the most ignorant I've seen in quite some time. http://upload.wikimedia.org/wikipedia/commons/7/74/Timeline_of_web_browsers.svg
I'm sick of these table debates so let's cut to the chase. The answer is CSS is deficient so sometimes tables are needed but they should be avoided where possible. Pass this answer around so we can stop these stupid, incessant CSS versus HTML table debates and retarded generalizations such as "you should never use tables" comments.
You probably commute to work and do all your shopping in a car (or perhaps the bus/train/whatever) which is a type of mechanical mule. How come it is that you don't use a horse and buggy for doing all those tasks? The answer is the same for both cases.
The strange thing is where I work IE is the least supported internally. Developers here don't support it for the main reason that it consumes too much precious time to make it work right due to non-standards and very painful testing tools. It's not due to anti-MS sentiment. We just don't have the time. When your schedule is overloaded the natural tendency is to cut the more difficult platforms and do primary support on the ones that come with better testing tools and tend to work right on the first try.
For any organization still boxed in with IE6 or IE7 then I say they were arrogant and ignorant and now they're getting their just deserts. These were the crusty companies with idiot managers dictating technical standards--not a good sign when doing the job search. Unless the option is going jobless and hungry, I will avoid pursuing a job with them like the plague.
So what happens to men with permanent penis implants. Will it show as a strange device?
Naive attitude. This is a sovereign nation with borders and the right to self-preservation so placing controls on who can enter falls entirely within those rights. You are advocating opening the flood gates and creating a free-for-all by letting anyone in who merely requests entry--essentially nullifying the impact of controlled, selective, and orderly immigration. A massive, sudden swell of immigrants is a disruptive force on the economy due to the finite availability of jobs, housing, and public services. We need immigration controls to throttle the incoming rate so that markets can self-adjust. Case in point: average salaries for carpenters in the American south west plummeted due to unfettered Mexican migrant workers. In 1980, wages were $15 to $17/hour. In 2005, $12 to $15/hour.
Your utopian plan will never be adopted by Americans because it is just plain stupid.
Still smarting over Air America.. huh? :)
I think that's true for every college.
Now. I can't speak for the performing arts and fashion design. Some say the correlation exists there. I just didn't see it in any drawing, painting, ceramics, etc classes.
I took some art courses working on an undergrad Fine Arts program at 2 different colleges and I didn't see an unusually high number of gay students. I honestly don't know what you're talking about. I suspect you're peddling bullshit stereotypes you picked up from watching some lousy TV sitcoms.
Oh no. We better get greenpeace on that to put a stop to that nuclear nonsense.
If only that happened in reality. Here's what really happens:
A core set of developers develop some convoluted flaky system and end up moving to to other teams to work on something else. New hires come on and get the "honor" of maintaining said system. What you end up with is a bunch of recruits barely familiar with the code supporting the oncall. They continue beating their heads with resolving tickets and doing mundane band-aid deployments for a year before they quit or suffer performance problems due to burn out.