Very Interesting

Krisfr · 12th March 2012, 06:54 PM

DF96 · 12th March 2012, 07:58 PM

This appears to be from the 'monkies and typewriters' school of programming. My experience, as someone who used to be a professional programmer, is that everything which makes programming 'easier' also tends to make programmers lazier and the main result is faster production of lower quality code. Sadly, this now seems to be the norm in IT - one reason why I changed career direction about 10 years ago.

IT managers are always looking for a magic bullet. There is no magic bullet. You just have to employ the right people and give them sufficient time to do a good job. Oh, and don't keep changing the user requirements.

tvrgeek · 14th March 2012, 01:50 AM

DF, Dead on. Nothing but kids that think Java does everything and trust Hibernate to solve all their DB issues. They are so clueless with their easy abstracted open source tools, they don't understand that "select * from * " is a bad thing. Oh boy, do they want to get paid as "software engineers". Nope, script kiddies. Give me a couple of old guys who think an IDE is xterm and emacs and let then do it in C. It will run, run quickly, and actually stay up.

Instead we get simple problems that contain several million lines of code that no human has seen, assembled from FOSS libraries by who knows who and no support. Then they blame the performance on the platform. Cary the pager for their code? You have got to be kidding. Actually test the million lines? Not a chance. C++ was a bad joke and Java was the worst thing that ever happened to programming.

In my world, requirements change. So we moved to agile methods where we give business needs to the old guys who have it done today, clear box and integrated tomorrow, on the floor by Friday. They needs may change next week. There is no such thing as locking down the requirements and take time. It is about the right people and a process that lets them do their job. The old waterfall concepts and line item requirements never actually worked. Incremental deployment, component level.

Bibliophile · 14th March 2012, 02:56 AM

Quote:

This appears to be from the 'monkies and typewriters' school of programming.

"Ford, there's an infinite number of monkeys who want to talk to us about this script for Hamlet they've worked out."
Authur Dent from Hitchhikers Guide to the Galaxy by Douglas Adams

12th March 2012, 06:54 PM	#1
Krisfr diyAudio Member Join Date: Nov 2007 Location: near the House of the Mouse	Very Interesting A Better Way To Program __________________ Thanks Never give a Systems Analyst a screwdriver or hammer

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
This is very interesting	jmateus	Everything Else	11	9th October 2008 06:51 PM
Quite interesting	onis_uk	Multi-Way	11	9th February 2008 06:44 PM
Interesting...	fredos	Class D	3	26th November 2007 06:45 PM
interesting amp & interesting problem	m6tt	Tubes / Valves	9	14th August 2007 06:28 PM

New To Site?	Need Help?
Register to Participate Search Privacy Statement Contact Us	Frequently Asked Questions Did you forget your password? Mark Forums Read


	Please consider donating to help us continue to serve you. Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving

12th March 2012, 07:58 PM	#2
DF96 diyAudio Member Join Date: May 2007	This appears to be from the 'monkies and typewriters' school of programming. My experience, as someone who used to be a professional programmer, is that everything which makes programming 'easier' also tends to make programmers lazier and the main result is faster production of lower quality code. Sadly, this now seems to be the norm in IT - one reason why I changed career direction about 10 years ago. IT managers are always looking for a magic bullet. There is no magic bullet. You just have to employ the right people and give them sufficient time to do a good job. Oh, and don't keep changing the user requirements.

14th March 2012, 01:50 AM	#3
tvrgeek diyAudio Member Join Date: Dec 2009 Location: Md	DF, Dead on. Nothing but kids that think Java does everything and trust Hibernate to solve all their DB issues. They are so clueless with their easy abstracted open source tools, they don't understand that "select * from * " is a bad thing. Oh boy, do they want to get paid as "software engineers". Nope, script kiddies. Give me a couple of old guys who think an IDE is xterm and emacs and let then do it in C. It will run, run quickly, and actually stay up. Instead we get simple problems that contain several million lines of code that no human has seen, assembled from FOSS libraries by who knows who and no support. Then they blame the performance on the platform. Cary the pager for their code? You have got to be kidding. Actually test the million lines? Not a chance. C++ was a bad joke and Java was the worst thing that ever happened to programming. In my world, requirements change. So we moved to agile methods where we give business needs to the old guys who have it done today, clear box and integrated tomorrow, on the floor by Friday. They needs may change next week. There is no such thing as locking down the requirements and take time. It is about the right people and a process that lets them do their job. The old waterfall concepts and line item requirements never actually worked. Incremental deployment, component level.