As we've stated more than once here, this is matter of communication and respect for the user. I fully agree, however, the issue is deeper than that based what I've seen here and on my years of experience in the corporate world. The problem is we have people who are very smart but have no clue about processes and impact on the users. They for one, whoever they may be at N3V, don't use the program and don't care to. They've never experienced the long validations, or a dorky interface. For them the program works, and they will make changes to suit them rather than look at the full picture before considering updates and process changes.
This then causes other issues. Since they have no forward-facing job, don't use the program other than to test code bits, and only work in the technical aspects of things, they don't have the ability to consider the impact of change. In part this could also be arrogance and selfishness, but I think it's more just inexperience and cluelessness. I saw this while at Oracle and even Polaroid way back when. One of the more important things to learn is the impact of a process on the outcome, weigh the differences and see if the end result is worth the effort. In other words test the waters and see, and don't do things during critical periods!
What also comes out of this is business impact. The first thing my manager told me at Polaroid, and reminded me again at Latran Technologies, the spin-off from Polaroid' Graphics Imaging division , was never do anything at the quarter-end, month-end, or year-end, that will impact the business cycle. Being a technician and server guy, I had no clue that that a server upgrade during this time could impact this critical time of year for the company. A patch came in; it was time to install it. For me I wanted to put it in during the day, whether it was May 15th or June 30th. Why these periods? This was the most critical time for the company to close sales and close the books. I didn't fully realize this impact until I worked in order admin and financial reporting where I was responsible for running the reports for upper management and finance as well as setting up the general ledger accounts and other boring stuff.
Oracle suffered, and probably still suffers from, the same issue we're seeing now. Why on earth did the mail server (Oracle Beehive) group decide to do a major upgrade during the 4th quarter end? Hello! My phone, being in support at the time, was ringing off the hook because the sales people couldn't send the final documents to the field operations to close the sales. Us technicians had no advance warning (Sounds familiar!) that the Beehive server was going down for many ours and may impact operations. It took a phone call to the helpless desk to determine the cause, and the answer was "Oh Beehive is down for maintenance and upgrades". Gee, thanks! We were stuck in the water as their major link was shutdown or severely impacted. We struggled through this and I got on the phone with my manager. She was quite influential and spoke with the people in charge of this. Soon after that all server upgrades were planned and executed outside of these critical times. The problem is the people in the server group are at a 100% disconnect from the rest of the business and the impact on business.
So here we have a group of smart folks who don't use the program at any real level. This also explains why there are still those unrefined things such as layers and other oddities we have faced since day one with Surveyor, or the long validations and poorly planned or thought out impact of the DLC process and servers. Sure they work because we've figured out how to attach the bailing wire to the chewing gum, but the real refinement has never been implemented. This also explains the lack of proper documentation. The programming geeks know what goes on, but documentation is never one of their top skills. It never will be and it truly is a rare find to have a programmer who can write documentation too, and even document changes as they go along. For most of these guys and gals, it's the farthest thing from their thought. They'd rather play with the code and let mold grow out of old coffee cups instead of putting things together as a package. This is why many companies hire tech-writers, and a full staff of them too, to put together the proper documentation and user manuals.
This also explains the lack of communication regarding changes. The schedule is done at their convenience without looking at how it may impact the users. I agree an advanced notice on the changes we experienced this weekend would have been more than welcome. The change isn't the issue, though it's a sticky wicket in many respects, but knowing the curve ball is coming is better than none at all. This also explains the surprises we see with the service packs, and the grand fiasco we had with SP1 for TS12. It all boils down to poor planning and implementation more than ill will towards the community.
I could go on with many more examples from my past experiences as well as those we've all experienced here in the Trainz community. What would I do differently?
* Implement business planning meetings (yet another meeting!) between the development team and management. Where upcoming patching and software cycles can be discussed with all parties. Marketing and Community Support really needed to know about this... This is more than just discussing patches and new toys. This is to discuss future plans and let management know so they can investigate and look at business impact if any.
* Actually have the developers use the program for once. Make them go through the full gamut from installing, patching, building routes, downloading; everything! If they see what we go through, perhaps they can change things. Just seeing the little bits under a microscope isn't actually using the full package.
* Be more open about upcoming changes... (What's the big secret?)
and so on...
John
