Being “Jim Rockford” in the Modern Technological Landscape
August 13, 2015 Leave a comment
The last essay written by Black Falcon Software and subsequently also published on the “jaxEnter” site (“Is Technology Killing Us?” It’s Dark Side Is…) was pilloried by a small but vocal minority for being short-sighted and/or overly conservative in a rapidly changing technological world. The comments, surprisingly, were from people who appeared to have read a completely different essay than the one I had published. Nonetheless, the piece was a point of view from one who had been through over 42 years in the IT profession across a very wide spectrum of US businesses.
From the late 1950s through 2014 James Garner had quite a string of successful roles that were finally ended in 2014 with his death at 86 years of age. However, what many of us remember him most for was his role of Jim Rockford in the television hit, “The Rockford Files”, which ran from 1974 to 1980 and used many of the plot lines from his earlier success in “Maverick”.
For many the show was a genuine display of the actor’s combined warmth and edginess as the person who James Garner actually was. However, a more clinical look at the show also demonstrated a sociology of US working life.
In “The Rockford Files”, James Garner’s character of Jim Rockford plays al private investigator who does a remarkable job of being quite successful at it while never seeing the financial and personal success that should have followed many of his more serious cases. Up against a world that favored corruption and shallow personalities, the character never seemed to catch a break from both friends and foe alike. Scorned by the police for his misuse of their resources for his good intentions (and eventual successful breaking of many of their cases, which he was never thanked for beyond his friend in the department) along with shallow responses from many of those he actually helped, the character portrayal of the Jim Rockford character mirror many who then and today attempt to maintain, honest professional and non-professional careers in the United States.
In the Information Technology profession, like any other profession, the field’s cultural norms are expected to be followed and conformed to. Thus technical managers are usually people who demand the ridiculous or near impossible from their professional technical personnel not because of any overriding altruistic necessity but merely to satisfy corporate requirements that are rarely thought out properly along with the job-security agendas of the managers making the demands. The Internet is full of honest complaints from professional technicians who have worked under many of these people.
However, many professional developers on the other hand are forced to comply with two sets of cultural norms; those of their own peers as well as those of the managers that supervise them. And for many, trying to apply the inbred logic that the IT profession demands of it’s professionals while supporting the literal stupidity of those that they work for is very much a losing proposition.
This mix of deleterious cultural enforcement is then outwardly represented by many corporations as suffering from a skills shortage, a lack of available talent, a lack of general technical personnel, skyrocketing costs all of which is supposed to be relieved by outsourcing many quality US jobs to countries that can only offer less expensive labor populations but not necessarily the same level quality. And this last has been demonstrated tirelessly by many poorly outsourced US technical projects.
From the professional developer’s perspective, acceptance of new technologies and paradigms that promote faster development cycles while also being supposedly easier to use mixes well with younger professionals and even older ones who are either learning technologies in the early part of their careers or enjoy tinkering with any one of them that appears to be different from what they had been using for so long.
Interestingly enough, despite similar sociological issues, many professional mainframe developers rarely thought about using new tools with the exception of wanting to learn communication skills (CICS). All of us in the mainframe era wanted to build successful applications. And as such we became rather conservative in how we used technologies; if it worked and worked well, we never saw a reason to change even if new tools were available. And if such a new technology were available and promoted easier and faster development cycles, management was terribly reticent try it for fear that a single failure would cost them their position; such was the dominance of the prevailing technologies at the time.
Both Borland International and Microsoft offered a similar potential for the development of distributed systems on microcomputer technology and up through around 2010 this level of stability held quite well even though Microsoft superseded Borland entirely as it became the single, dominant vendor of development technologies. There were others with the competing Java environment but nothing ever equaled the level of original IBM dominance as Microsoft has done up until recently.
Despite the evolution in development technologies over the years, staying the course with common-sense approaches to software development, as Jim Rockford maintained his professionalism in spite of the obstacles placed before him, has always been a difficult approach to take in one’s career development. No one ever gets rewarded for showing the foolishness in another’s methodology or a supervisor’s demand. Often enough those who attempt to maintain such a steady, unyielding level of professionalism are instead ostracized, smeared, and even terminated from their positions. For example, the senior engineer on the Challenger Shuttle, which blew up on its ascent in 1986 killing everyone aboard, was aware of the climatic weaknesses in the “O-Ring” technology used on the craft. His team recommended in severe terms not to launch on the day of that tragic disaster stating that the temperatures had been too low to guarantee that the “O-Rings” would not fail. That senior engineer eventually had his entire career destroyed for his attempt to not only to save the lives of the Challenger crew but for exposing the utter recklessness of the management decision to launch the craft when they did.
Putting one’s career on the line is never easy and those that do in any profession often have a tough time of it and it doesn’t matter the field, the resentment towards professionalism is always the same.
Software engineering practices have been a relatively tough sell to many technical managers in the IT profession. This has been the case because recommending and\or following actual SE standards is very counterintuitive to management. In essence, software engineering tends to offer a standard axiom that by slowing things down, development efforts will often go faster. This is because the nature of software engineering is to eliminate or reduce as much as possible actual road-blocks in development projects. This is why the practice adheres to good requirements gathering and analysis, project risk assessment, the negation of relying on estimates, proper project timeline analysis, which in fact includes a scientific approach to generating running estimates as the project proceeds.
All such practices take time, which have been conclusively proven over many years of research to consistently reduce project delivery schedules when implemented properly. However, to promote such concepts whether before 2010 when development environments were somewhat more stable or currently as they are being deluged with new technologies and lip-service to development paradigms, such recommendations have always run into arrogant refusal to acknowledge such time proven implementations.
This is because the culture of most technical management is to simply disregard anything they may view as a hindrance to simply getting development done while as many technicians are more than happy to comply by attempting to develop paradigms that can help them achieve the utterly ridiculous. So far, all the new techniques have achieved nothing in reducing the ongoing project failure rate of around 70%.
For a quick reality check, there is no such thing in business outside of life or death consequences (which should never fall under business auspices in any event) that has ever required the utter lunacy of businesses’ constant hyping of having to get software development completed “immediately”. No business has ever gone out of business for taking the time to create quality products or quality internal work. However, many have gone out of business or nearly out of business for doing just the opposite. For example, years ago Oxford Health Plans was one of the predominant health organizations in the United States. And many thought they rated a premier status. That was until they decided to rush in a brand new set of administrative applications without proper analysis and testing. The result was that within a short time Oxford was nearly completely devastated and lost its reputation in the interim, which has never been regained.
Since 2010 with the initial popularization of Microsoft’s ASP.NET MVC paradigm there has been a fevered rush to introduce additional technologies to support this web-based paradigm in both the Microsoft and non-Microsoft environments fully supported by the younger technical professionals as they increasingly become overwhelmed by the hype for mobile computing, which has been popularized as the latest in technological innovation. Who doesn’t want to be first in line to reap the rewards either as a business concern or an individual developer?
The current environment for software development is quite similar to that of the popularization of the Internet 15 years ago when it reached its economic bubbled height. At the time nothing was too new to be considered anything but viable when suddenly the entire industry imploded leaving but a handful of Internet businesses still standing.
Recently Apple announced that their “App Store” has 1.5 million “selected” applications for their customers to use on their iPhones. A similar number of “apps” exist for Android devices. With that number of applications available for everyday use what in reality is there left to create for this software arena? More games?
The paradox of all this occurred about two years ago at a company that wanted to enter the mobile computing frenzy and decided upon a major project to allow their field users to directly enter their case data as social workers so that the information could be directly transferred up to the state level as required, without having to send the actual paper work. Several consultants were hired to work along with the employed technical personnel on the project, with the first phase being nearly completed in approximately three months. The project was then presented to the company’s user community, which flatly rejected the results.
There was nothing wrong with the workings of the software as it performed as designed. What happened? No one did any requirements analysis, the first task being to ask the user community what they actually needed. Had they been told that a standard Internet application was being designed they would have been more than happy. However, all of them already did a lot of their work on their laptops and had no interest in having to add an additional burden by doing some of their work on the proposed tablet device while much else would have been still done on the laptop equipment. Two weeks after the project was rejected it was cancelled with a substantial financial loss; this failure a result of no one having thought to ask a simple but vital question of the users themselves.
So the question then becomes that of what was so wrong with recommending the usage of existing technologies, which were still quite viable for production quality development. The answer is nothing and using the existing Internet technologies as is would have secured a successful acceptance of this project.
This situation is not an exception but rather a commonplace occurrence in today’s rapid development environments because few are any longer trying to concentrate on developing and building real applications because the business environments are too caught up with trying to adapt to new paradigms and technologies. And what happens is that many technical professionals are finding it increasingly stressful to accommodate software development requirements while at the same time achieving proficiency with new technologies under deadline circumstances.
Being “Jim Rockford” then is not about eschewing new design and development possibilities but instead retaining a sense of professionalism by questioning the hype surrounding them and understanding that not as much has changed in the business world of software development as all the marketing has been trying to promote. Our job is to create well designed and successful applications, not succumb to the constant frenzy surrounding the latest toys we have at our disposal. And it is our capability using solid, well founded technologies that have deep knowledge bases for our necessary support that are our most important tools for this endeavor.
Think about it for a moment. Without the email, the texting, and constant phone calls, all of which many now consume on a smart-phone, what would be lost if that device suddenly disappeared tomorrow? All of a sudden what remained was just the Internet as it was.
All of us still need to transact our daily business, which means that most established companies would still be there to purchase our needs from. We would still be able to connect with our colleagues, friends, and loved ones. The superfluous things we use such devices for such as directions could still be had by using MapQuest or learning to read a map. In fact, the world would still be operating as before but maybe a little slower, which would probably be a good thing for our health.
Jim Rockford was a realist in his profession and he understood that his primary goal was to help people with their problems. He was a detective in the most down-to-earth sense so though a smart-phone would have been helpful to his work, it is doubtful if it would have changed his primary emphasis towards his job. And it is that sense of professionalism that is so difficult to maintain in a world that has most assuredly gone completely topsy-turvy in the technological realm.
It would do us all well if more of us tried to attain that sense of unyielding professionalism towards our development efforts and the demands of foolish technical managers. Maybe then our profession would finally reach a very much needed sense of maturity…