My department was also not very big on Object-Oriented programming. Most of us could write procedural code in C till the cows came home, but we were not comfortable working in true C++. There were some who came with a lot more object-oriented programming practice than others because of graduate school projects and so on, but our department did not really care whether you could do object-oriented programming or not.
If you started a brand-new project and could put together a team that was good at object-oriented programming, you were welcome to use C++ and OOP on the project. But, if you were enhancing an existing project written in C, or if your team had members who were not comfortable with C++, it was back to C for you too. C was kind of the lowest common denominator in the department when it came to programming projects.
The new project I was heading up was a little different from other projects that our department usually handled. This project would need, indeed, rely on, real-time data from the company's operations world-wide. The data architecture for getting us this real-time data had been a C-based in-memory cache that our IT department has decided does not meet their "standards" anymore.
They barely support this C-based data-layer and it has slowly become less and less useful over time. It contains only a small subset of the data that goes into our real-time databases. Even within this subset, if the data format of one of the fields changes in the system from which this cache pulls data, IT has decided it would be too much trouble to update this cache with the new data format. So, recently, when one of the fields in the database went from a 4-character string to a 5-character string, IT simply stopped passing the data on to this data cache.
So, the signals were clear: any project that relies on real-time data would not be able to rely on this C-based data cache going forward. After years of dithering over the replacement for it, the IT department finally decided that it would be moving to a Java-based object cache in the future. They have started a bunch of projects to build up bits and pieces of this cache (which would include an enterprise data bus that would keep the cache as well as all our sytems of record in sync).
Since my project would rely on this Java-based object cache for all its data input, it was decided that our team would get trained in Java and object-oriented programming. I was in charge of researching and coming up with the ideal Java course to send the team to. Now, I love projects like this: searching on the internet, comparing alternatives, coming up with spreadsheets comparing the alternatives, presenting them coherently to management along with recommendations, etc. So, I bit into it with gusto and came up with three alternatives that were equally good. A choice between them would come down to little more than personal preference.
As part of the research, I had gotten in touch with coordinators at each of these three training establishments and negotiated detailed rates for on-site as well as off-site training of the entire team. This was all done back in May and early June. I had dreams of actually getting the Java training delivered to the team by mid- or late July.
Bureaucracy disposes what man proposes, though. Since the training would involve more than $10,000 in expenses, the purchasing department of our company had to be involved to actually finalize the details. I had had previous experiences with our purchasing department, and I tried my best to find a loophole that would allow us to get this training arranged without purchasing being involved, but ultimately nothing worked.
I forwarded my email conversations with the three training establishments along with summaries of my phone conversations with them, to our purchasing department. I checked with my manager every couple of days, then every week, then every couple of weeks, but there was no apparent movement at purchasing whatsoever. I pretty much gave up on this and asked my manager to tell me whenever they came back.
Ostensibly, the reason purchasing wants to get involved in a big purchase is so that they can throw their weight around and negotiate lower prices for whatever our company was trying to get. So, I assumed that the long silence on the Java training was due to their intense negotiation with these three training organizations. Well, I was wrong. The representatives with whom I had had email exchanges at two of these training organizations kept sending me emails asking me what was going on. I told them our purchasing department would get in touch with them soon. But after a few weeks, I just told them it was out of our hands, and we could not proceed without somebody from purchasing being involved. They stopped bothering me after that. The third organization probably had enough business on hand, so they never bothered me to ask for progress reports.
So, what exactly was purchasing doing? I honestly have no idea. Ultimately, a month back, they triumphantly came back and presented our department with three options. Guess what, they were the exact same options I had presented to my manager back at the end of May! There were no price concessions, no course details that were altered, nothing. No changes from what I had negotiated single-handedly over the course of 2 weeks of email exchanges! Purchasing had sat on the process for 4 months and achieved exactly nothing!
Obviously, these were bureaucrats intent on taking bureaucracy to new heights! I was furious, but my manager was more realistic. He thanked purchasing profusely (as if they had practically invented the Java language and found us somebody to train us in this esoteric new art, all by themselves), and had them set up the dates for the training with one of the three organizations. One of our team-members had attended one of their training sessions a long time back and found it useful, so given that the monetary terms of the three proposals were roughly the same, we decided to go with the known devil rather than an unknown one.
The training was set up for the last week of October with Hands-on Technology Transfer (HOTT). In the week before the training, I got in touch with the trainer and discussed our requirements in detail. In particular, I told him that he would be training a bunch of C programming experts, not programming newbies. We would be using the language to do hard-core mathematical programming, but no database access or GUI development. However, many would have no idea about object-orientation, encapsulation, and other such concepts.
Based on these discussions, he came up with a 4-day course that was satisfactory to me, my manager and the entire team. It was going to be on-site training, so I made arrangements to book a suitable classroom, arrange for a projector, and do other preparatory stuff.
One of the things I was tasked with was making sure that everyone on the team had their laptop set up to undergo training. Our IT department used a customized version of the Eclipse IDE to develop Java in, so that part was relatively easy. But getting the Java compiler and other stuff on the laptops was anything but.
The Sun Java website is a poster-child for how not to design a website. Everything is jargon and acronyms with no explanation as to what exactly one needs. What a mess! There is Java SE, Java ME, Java EE and JavaFX. Then there is glassfish, the SDK, the JDK, the JRE and a million other TLA's (three-letter acronyms). Where do these people learn web design? And then they have the audacity to complain that people are using C# and other alternatives instead of Java! I truly hope Oracle does take Sun over and tears this website to shreds and puts something up that is a little more meaningful to non-experts. And I hope they fire the sorry lot of web designers who put this site up, and bring in their own talent to put something a little more intelligible, together.
After some guessing and checking with our IT department, I did manage to get all the laptops all set up with the right software. The training went off pretty well last week and everyone in the department now feels capable of coding in object-oriented Java (though obviously nobody feels 100% comfortable in it yet). The instructor was a bit of a rambler who tended t0 go off on wild tangents at the drop of a hat. He never stuck to the lesson plan and tended to pull in material from advanced chapters into the early chapters, confusing quite a few people. Ultimately, he managed to get through all the material, but left everyone with nagging doubts about what had not been covered.
He tended to wander off into philosophical discussions in the middle of technical discussions and some of these discussions turned out to be more confusing than enlightening. He was also a trainer in several languages, so sometimes he would get stuff mixed up between languages, adding to the confusion.
He also had this "technique" of getting everyone back into the class from breaks on time, which consisted of giving the class some tech tips right at the end of the break that they would miss if they weren't back on time. Problem was that either the tips were lame, or there was so much discussion about them that we wasted more time at the end of breaks than we would have if he had just started his teaching about 5 minutes after the end of each break! Some students deliberately returned late from breaks just to miss his "bonus insights"! Towards the end of the 3rd day, even he was returning late from breaks and then sharing his bonuses with us, so this entire "bonus insight" concept became not only meaningless, but a big drag on our punctuality and productivity.
I think enough people felt uneasy about the training that they emailed or spoke to my manager about what was going on. He then sent me an email wondering what was going on in the class, and asking me to confront the instructor about his progress and that of his students. I had to take on the uncomfortable task of checking with him about progress, and what he intended to cover over what time-period, and report back to my manager that things were still on track.
To my great relief, we were finally done with the training on Thursday. I now know enough Java to be dangerous! I now have to practice it so that I know what I am doing before I apply it on some real project that will require maintenance 5 years from now. New programmers tend to get carried away in the new features of a language and produce code that is a nightmare to maintain. I know from personal experience, having inherited such code from others.
After all the fluff is blown away, good, maintainable code comes down to if-then-else blocks that are easy to understand, and loops that are easy to understand. More importantly, it comes down to using easy-to-debug data structures like arrays and lists. Yes, trees are very nice in theory, but anyone who uses trees in a real project (rather than an academic one) deserves all the abuse that maintainers down the line will heap on him!
My task is now to supervise a whole team of new Java programmers and beat enough sense into them early on so that they stick to the tried and true programming techniques instead of experimenting with esoteric concepts that make the code impossible to maintain down the road. They are obviously free to experiment all they want on personal projects if they want, but I want them to forget all the esoteric features of the language and stick to the basics when it comes to work projects. Let us see how this cat-herding works out!