In a speech given by Michael T. Nygard at the W-JAX 2014 conference last November (see Speech) but was again recently posted at the “JaxEnter” site, he postulated as to how Information Technology needs to change itself to adjust to the working realities of business.
I can agree with many of the things that Michael presented in his talk. However, as a forty-something he can be forgiven for not realizing that much of what he presented was also presented in many articles and similar talks 20 years ago. Nothing has changed.
As a 65 year old senior software engineer, this precipice in life is felt when someone much younger is touting a technology that may be the latest new thing since “sliced bread” but for one who has done so much in the field is just another form of redundancy since the underlying technologies on which this new thing is supposed to exist on hasn’t changed all that much. As a result, I am very much a proponent of the “Old Ways” when it comes to such things because they are simpler and easier to work with.
In the early 1990s as the emergence of the Internet was upon us I listened to many such talks about how to use technology and technology personnel effectively. The London Financial Times (probably one of the few mainstream papers worth reading on the planet) at the time had a very extensive article on new organizational structure that should be considered to make companies more effective. It suggested basically the very same things that Michael suggested; a cross between the centralized and the non-centralized operation. No one listened then and no one will listen now. Why?
The concept of structural change whether it be for an entire business or an organization within it such as IT is not something that can be simply implemented from a logical construct. This is because organizational structures are sociological in nature and not in any way logical. They may appear to be logically constructed but the people who make them up are not.
The organization no matter what size, especially in the United States with its celebrity, narcissistic culture where I live and have spent my career, is not an entity that is run in a logical fashion. If it were, people like Michael wouldn’t be giving talks such as the one posted here and neither would have his predecessors. His ideas and the many similar ones of his earlier counterparts would have already been considered and tested with an eye for actual improvement.
But corporations simply don’t like change because they are now (and have been for a long time) centers of power for many and are run mostly by corrupt psychopaths with their own agendas. And psychopathy is found at all levels in the management infrastructure. The best of the documents that have substantially proven this point is the small book, “The Corporation”, by noted Canadian jurist, Joel Bakan. And there is an avalanche of corroborative documentation on the subject. The US 2008 stock market crash was a classic case in point. To review an in-depth psychoanalysis on the subject, please see, “Snakes in Suits”, by Babiak and Hare (available at Amazon).
Trying to restructure such entities has been attempted numerous times over the many years our profession has been in existence. In some instances, even the corporations themselves attempted some of these changes on their own knowing that there was good reason to do so. All such endeavors have been complete failures. At one major financial institution where I was a software engineer I actually participated in the process of such change only to see it all blown up in my division by a foolish senior manager whose only interest was to pay lip-service to the corporate, sanctioned process.
This level of intransigence has resulted in the continuation of attempts by IT analysts (like Michael and many others) to foster change within IT to satisfy the ever increasing and nonsensical requirements of business management. This too has failed since an IT organization within a larger construct must adhere to the overriding cultural aspirations of the overall entity. So what we get out of all this began with the completely failed “Extreme Programming (XP)” paradigm (read the history on this ridiculous excuse for idiocy), which then morphed into “Agile” and its variants. And now we have a new buzzword, “DevOps”. So far none of these development paradigms have changed the fairly consistent project failure rate in the Information Technology profession (a good 70% since the inception of statistical recording on this matter; Michael states in his speech a failure rate of 66%). Why?
There is good reason to believe that corporate structures do in fact have their definitive part to play in this situation. However, added to this constricting influence we have the Information Technology profession itself whose many technical professionals are as much to blame as their business-user counterparts. Many professional technical personnel engage in a constant game of personal and organizational suicide every time they promote a new technology because they believe it’s the latest innovative technique or tool to provide benefits to existing problems.
Well guess what? The business problems that every professional developer and engineer face on a daily basis are the same types of problems we have all been facing since the advent of commercial IT. The idea that somehow such problems have morphed into something unique and new in the 21st century is all marketing hype for vendors to sell new products.
It is this way because the corporate entities, which we serve, never change. Solving old problems with constantly evolving tools has been the “battle cry” of “innovative” technical personnel and vendors throughout our profession’s rather short history.
Every time technical personnel push a new tool and\or technique they also push to eliminate entire mature knowledge bases that have been built through long years of personnel working through the bugs and idiosyncrasies of these products. And with the removing of the old so too is everyone forced at some point to begin learning how to basically do the same thing all over again but with different methodologies and tools. Again, a new knowledge base is created, which in turn will be tossed aside when the cycle repeats itself. Pretty stupid and there is not a single argument that can support this constant change except by those ignorant enough to think they have one.
The disastrous result is that the Information Technology profession has no real standardized knowledge base to refer to and train new personnel with. The end result is that things never really get better they just keep on going the way they are. In short, the entire profession is a bloody mess of cross-purposes and self-interest, the combination of which inflicts horrible technical wounds on everyone involved. “Change is part of the profession!”, so it is often said; its done a bang up job of making things so rosy. At least Michael can look forward to giving more talks on the subject.
Maybe we should apply such change to the ever modernizing aircraft Boeing builds or the latest in tank weaponry that Russia is creating. Maybe we should ask all those engineers to throw out long known principals to try something new and see how far we get. What we did get in fact was the new Boeing 787 Dreamliner, an excellent plane but fraught with some serious issues or earlier, the F-111 fighter-bomber of the Vietnam War that killed more of its pilots on takeoff than in combat.
The fact of the matter is, if you want to change the world stop trying to change it; it will eventually change itself in due time.
In other words, stop throwing out “the baby with the bathwater” as has been done with many new software tools and techniques; my personal favorite is the move from ASP.NET to ASP.NET MVC, which the latter brings nothing more than mind-blowing complexity to basically simple straight-forward processes.
In short, ASP.NET is one of those “simpler tools” that Michael talks about in his speech and we have acquired a 10plus-year knowledge base along with it. ASP.NET MVC shows up on the horizon and everyone starts rushing for the new idea, which is nothing more than “Classic ASP” wrapped up in a shiny, new package. Suddenly, standard ASP.NET is no longer good enough to compete with the shiny new paradigm and its tools. Yet it has done quite a good job for over a decade and can still do a fine job of helping developers create complex web-sites. What happened; something change in the universe of business besides more stupidity?
Michael forgot to mention one very critical factor at making IT work properly with its surrounding organizations. It is not about new paradigms, techniques, or simpler tools. It is about using common-sense; something that Humans and all their new smart-devices have in very short supply these days (Yes, that has been well documented also.).
Common-sense approaches have been outlined for many years by prescient software engineering analysts and in 1996 Stephen McConnell wrote the standard on the subject with his “Rapid Application Development” publication. It is still in print and it’s concepts are still very much in use in the software engineering world; at least in those areas where software engineering is taken seriously. Why mess with success?
I have worked in all types of companies, large and small and on all types of projects. And what I have found is that while professional technical personnel are currently busy slitting their own technical throats, technical management is no better. No other engineering profession has the host of stupidity in its management ranks as that of Information Technology; people who have no idea as to how to control their own projects properly let alone their own supervisors who make increasingly preposterous demands of them, which are in turn then passed back to the developers to implement. If this weren’t true, cars would simply die on the road, trains would derail (And they do quite often from such ridiculous reasons such as a lack of funds for safety measures. Its a public service, it is supposed to be safe!), airplanes would fall out of the sky, and ships would sink.
It’s a dance in which the play-card is never used up…
The finest example of a truly great software engineering project was the software systems developed for the Boeing 757/767 aircraft in the 1990s. Everything was very tightly controlled with one very unique attribute attributed to the project director; he knew how to say no to unnecessary requirements; the project won the “International Project Management Award” in 1995 for excellence. And this was before all the new whiz-bang development paradigms entered the lexicon of our profession.
So where Michael’s suggestions are quite cognizant his emphasis is in the wrong area. Instead of trying to change existing organizations, younger professionals should endeavor to start their own small firms where the bureaucratic morasses of their much larger counterparts are non-existent. To build quality software products, like in any engineering profession, you need to use time tested tools and techniques that both the Microsoft, Java, and other communities have been successful with in the past that already have deep knowledge bases and forget all of the paradigms and techniques you thought would save the world of your profession. It simply is not going to happen and real software engineers who have built great products will tell you that. Besides, true software engineering has all of the techniques and methodologies you will ever need for every situation you will face. It’s standards, principals, and practices, all tested over a long period of time have been around much longer than most professionals today…
TECH NOTES 