September 4, 2012 at 10:07 pm
Comments posted to this topic are about the item Rogue Algorithms
September 5, 2012 at 6:58 am
Something to worry about when algorithms are being used to control our cars:
http://jalopnik.com/5648126/volvo-pedestrian-avoidance-crash-test-fails-spectacularly
...
-- FORTRAN manual for Xerox Computers --
September 5, 2012 at 7:07 am
I'm about half way in to Automate This which is a book about the rise of the use of algorithms and it is a very interesting book. It can be pretty spooky when if then else goes wrong.
Cheers
September 5, 2012 at 8:37 am
"Even more unfortunate is the fact some managers never learn that. "
Actually, that is very easy for them when they are only concerned about themselves first.:-D
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
September 5, 2012 at 8:42 am
Knight Capital is useful ammo when countering dangerous management demands on your development time lines. Usually management tries to hide 'problems' like this, but that one was just too big. We don't know all facts yet, but I'm willing to bet management was the primary culprit. Risk management is their game and they obviously dropped ball. To survive, they had to sell a large piece of their equity to their competitors like TD Ameritrade who now basically own them. Too many shops think change control is source control or that prototyping in production is somehow clever (or some other crazy short-cut) but I would argue that every software manager should have a healthy appreciation of the core elements of the System Development Life Cycle like planning, analysis, design, testing, etc. In my universe, these concepts are as immutable as gravity or electromagnetism. Ignore them at your own risk.
September 5, 2012 at 9:56 am
If you code what you think and not what you know the eventual result is failure. Best read and understand parts of TAOCP vols 4 and 5 to get background and then find other particulars unique to the challenge you are faced with.
I fear for those who have "no fear" and 'just do it" when it comes to development of personal or cowboy algorthms in real business.
You have to understand the business, and the data to make information and informed choices. Without the application of true wisdom we are condemed to foolishness and folly.
End rant, restart work!
M.
Not all gray hairs are Dinosaurs!
September 5, 2012 at 12:39 pm
Miles Neale (9/5/2012)
If you code what you think and not what you know the eventual result is failure. Best read and understand parts of TAOCP vols 4 and 5 to get background and then find other particulars unique to the challenge you are faced with.I fear for those who have "no fear" and 'just do it" when it comes to development of personal or cowboy algorthms in real business.
You have to understand the business, and the data to make information and informed choices. Without the application of true wisdom we are condemed to foolishness and folly.
End rant, restart work!
M.
Agreed. When I was a junior programmer, I was sent to the business unit I was going to be supporting and spent the next 6 months learning the business. After that it was almost 6 months of doing nothing but learning the change control process inside and out by moving code in and out of test for my team. Probably doesn't happen anywhere any more. While there are probably more efficient ways of doing it, the general idea is still very valid. (Sorry for the old geezer story....but man I'm not that old! )
🙂
September 5, 2012 at 6:36 pm
Miles Neale (9/5/2012)
... Best read and understand parts of TAOCP vols 4 and 5 to get background and then find other particulars unique to the challenge you are faced with. ...
Huh? Sorry, I don't get this at all, what is in Volumes 4 and 5 that specifically applies to this discussion?
I have in fact read every bit of Knuth's master work that actually exists. Volume 4 is on Combinatorial Algorithms, and Volume 5 doesn't exist yet. So what are you talking about and why wouldn't volumes 1, 2, and 3 apply equally well?
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
September 6, 2012 at 8:54 am
Steve,
I'm surprised no one mentioned algile development practices. It seems like agile is another word for minimal testing. That's fine when the consequences of your code are small but maybe not so much when it's a stock trading program. Do you know if they used 'agile' development. In the Seattle area it is the buzzword.
John
September 6, 2012 at 9:06 am
John Hanrahan (9/6/2012)
Steve,I'm surprised no one mentioned algile development practices. It seems like agile is another word for minimal testing. That's fine when the consequences of your code are small but maybe not so much when it's a stock trading program. Do you know if they used 'agile' development. In the Seattle area it is the buzzword.
John
I suggest you read up on agile programming. Unit testing and acceptance testing both play big roles in the process. Anyone who uses agile to mean "develop and deploy" with no testing whatsoever isn't doing agile. That's cowboy coding. See: http://en.wikipedia.org/wiki/Agile_software_development#Characteristics
September 6, 2012 at 9:22 am
Scott D. Jacobson (9/6/2012)
John Hanrahan (9/6/2012)
Steve,I'm surprised no one mentioned agile development practices. It seems like agile is another word for minimal testing. That's fine when the consequences of your code are small but maybe not so much when it's a stock trading program. Do you know if they used 'agile' development. In the Seattle area it is the buzzword.
John
I suggest you read up on agile programming. Unit testing and acceptance testing both play big roles in the process. Anyone who uses agile to mean "develop and deploy" with no testing whatsoever isn't doing agile. That's cowboy coding. See: http://en.wikipedia.org/wiki/Agile_software_development#Characteristics
I think that many people view Agile as a way to speed development and if that speed causes a lack of testing, that's OK.
I think it's managers that need to read up more on Agile, CI, and other practices.
September 6, 2012 at 9:29 am
I laugh and laugh. Agile often means (to the managers in charge) get it done and skip whatever you think you can. That may not be the book definition but it's how many companies operate and I bet not a one calls what they do cowboy coding. I will say that the bigger the company I've worked with the better it gets (I worked as a consultant for almost 20 years) as in more testing etc.
September 6, 2012 at 9:40 am
John Hanrahan (9/6/2012)
I laugh and laugh. Agile often means (to the managers in charge) get it done and skip whatever you think you can. That may not be the book definition but it's how many companies operate and I bet not a one calls what they do cowboy coding. I will say that the bigger the company I've worked with the better it gets (I worked as a consultant for almost 20 years) as in more testing etc.
Then they aren't using Agile as it is supposed to be done. Testing is still an integral part of the development process.
September 6, 2012 at 9:49 am
So far we have "it's management's fault" and that's all? I agree that's probably more often the case than not but doesn't the person writing the code bear some responsibility for what they've created?
September 6, 2012 at 10:02 am
Not at all. The people writing the code are responsible for what they write, but they also have to answer to management. If management doesn't give them the time or resources, what are they supposed to do?
Viewing 15 posts - 1 through 15 (of 28 total)
You must be logged in to reply to this topic. Login to reply