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.
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.
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.
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.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.