When my better half bought an iRobot Roomba, it came with an invitation to develop new programs for it. It's fun to watch one of these when you first get it, in part because there are just a few easily identified floor coverage algorithms. And they're way different than anything I expected. Maybe all it can be programmed for is movement patterns, but for 400 USD it might be fun and you would see some tangible results.

The missing period is what makes it pointless.

Maxx said what I've been thinking. Sometimes old or bad tech solutions are good enough to satisfy business requirements. Management often has a belief that faster is better when delivering a working solution, and they don't worry about maintenance effort until it becomes necessary. There's also a huge difference between solo developers working in isolation on a focussed problem and team developers working on a large application where they have to use current technology. I've seen cases where programmers weren't willing to make the stretch to adopt newer methods. I have actually talked with an assembly programmer from early mainframe days who never made the transition to 3GLs because he thought they were inefficient and pointless. I also worked with a COBOL programmer who learned structured programming and never used it because she couldn't see any advantage over her GoTo code. I swallowed hard and left her code alone, because it was the only way she could maintain it, even though I had produced structured code for over 20 years in organizations where it was absolutely required. No one with newer, better ideas was ever going to reach these people, and it's possible that this know-it-all isn't interested in changing either. My advice is to find some way to respect the guy if at all possible. His solutions do work, even if they are suboptimal, and he's able to sell them. If you choose to approach him, make it about the work and not about personalities or competition or personal gain. Who knows, your enthusiasm for better methods might be contagious. But don't count on it. The principle of "Praise in public, critize in private" applies here. Your position is inherently critical of his approach, so it is less risky to approach him alone than to confront him or his ideas in a meeting with others. If you want to lead the organization in new directions, the best way is by demonstrated success in your own area of responsibility. Make sure your own managers and coworkers understand the reasons for and advantages of your technical choices. At some point there should be value added because your solutions are scalable, enhancable, or optimized, and it might pay to point that out occasionally.

Don't forget the shampoo girl!

:thumbsup: Seconded. Once a promising app dev tool, now complete garbage.

Amen, it's a relief to work in COBOL after seeing some other languages. Languages fall along a spectrum: Pascal tries to enforce structured programming, COBOL permits fully structure programming, FORTRAN forces unstructured programming. So the quality of COBOL code depends on the programmer and the organization's development standards. The textbooks and manuals never captured the reality of how COBOL was used, and there were some elegant systems developed with it. I think the beauty of COBOL is it allows the programmer to focus on business rules and express logic very similar to pseudocode. Its datatypes are currency-friendly and it handles rounding and value comparisons with more economical code than FORTRAN. One place where COBOL falls short is its inability to handle variable length strings; parsing files with foreign formats such as XML is a nightmare. One of the reasons it endures in Fortune 500 companies is it handles complex and high-volume batch processing very effectively. It's hard to beat for an application such as cranking out a million invoices for a utility company. Grace Hopper has always had her detractors, some with credible reasons. Nevertheless, she was an influential leader for data processing, a pioneer for progressive development tools, and her efforts helped build respect for software development as a profession.