Posts by cschneid 95 publicly visible posts • joined 18 Oct 2009
>>
I once worked on a project in which a software product originally written for UNIX was being redesigned and implemented on Windows NT. Most of the programming team consisted of programmers who had great facility with Windows, Microsoft Visual C++ and the Foundation Classes. In no time at all, it seemed, they had generated many screenfuls of windows and toolbars and dialogs, all with connections to networks and data sources, thousands and thousands of lines of code. But when the inevitable difficulties of debugging came, they seemed at sea. In the face of the usual weird and unexplainable outcomes, they stood a bit agog. It was left to the UNIX-trained programmers to fix things. The UNIX team members were accustomed to having to know. Their view of programming as language-as-text gave them the patience to look slowly through the code. In the end, the overall "productivity" of the system, the fact that it came into being at all, was the handiwork not of tools that sought to make programming seem easy, but the work of engineers who had no fear of "hard."
<<
- Ellen Ullman
https://www.salon.com/1998/05/12/feature_321/
https://www.salon.com/1998/05/13/feature_320/
The mainframe makes a comeback as people realize that JCL is easier than an unsteady stack of cloud configuration tools. A PCM (Plug Compatible Mainframe) industry re-emerges, with Microsoft and Apple vying for dominance. IBM Z versions of the commonly used office suites are produced by their respective vendors as IBM reveals AI powered transliteration tools to convert C, C++, C#, and most other semicolons-and-curly-braces languages to COBOL. Amazon reveals their cloud was really several geographically dispersed Sysplexes of mainframes all along.
According to a blog entry by Mark J. Barrenechea, OpenText's CEO & CTO, regarding IBM's complaint the "Southern District of New York has just issued an Order, dismissing the breach of contract claim altogether."
I cannot find any reference to the order or indeed the case itself on the court's website but that may just be my lack of navigational skills or familiarity with legal terminology.
There remains Count I, the copyright infringment.
Productivity has always been the justification for the prepackaging of programming knowledge. But it is worth asking about the sort of productivity gains that come from the simplifications of click-and-drag. I once worked on a project in which a software product originally written for Unix was being redesigned and implemented on Windows NT. Most of the programming team consisted of programmers who had great facility with Windows, Microsoft Visual C++ and the Foundation Classes. In no time at all, it seemed, they had generated many screenfuls of windows and toolbars and dialogs, all with connections to networks and data sources, thousands and thousands of lines of code. But when the inevitable difficulties of debugging came, they seemed at sea. In the face of the usual weird and unexplainable outcomes, they stood a bit agog. It was left to the Unix-trained programmers to fix things. The Unix team members were accustomed to having to know. Their view of programming as language-as-text gave them the patience to look slowly through the code. In the end, the overall “productivity” of the system, the fact that it came into being at all, was the handiwork not of tools that sought to make programming seem easy, but the work of engineers who had no fear of “hard.”
- Ellen Ullman “The Dumbing Down of Programming”, Salon, 1998
Maybe you're fine with tightly binding yourself to Google (or Amazon) instead of IBM. But do it with your eyes open. Vendor lock-in, from the vendor's point of view, is a feature.
The parallel test scenario seems like a good idea.
Perhaps taking the results of the Stack Overflow developer survey as representative of whatever point you would like to make isn't as persuasive as you might imagine.
Just as an example, you won't see much DB2 or IMS or VSAM because mainframe developers mostly don't ask their questions on SO. They usually have a support structure built into their organization.
JES3 is now supported and enhanced by Phoenix Software.
I do find it amusing that any government activity is met with cries of "privatize it all, fire all the bureaucrats" and any government privatization effort is met with cries of "outsourcing firms are all crooks" accompanied by stories of their incompetence, contract overruns, nepotism, etc.
If you're going to reduce costs by chasing the chargeback algorithm, you must commit to chasing the chargeback algorithm. Whatever dance you do around the edges of the rules, you must be prepared to alter your steps as the rules are altered. And you are in control of neither the nature nor the rate of change.
There's more here but it's primarily mainframe-focused, which tells you how long this issue has been extant.
By all means, add flexible configuration options to ignore categories of warnings, sub-categories, individual warnings, or any of the preceding in various contexts. Then add the only option anyone in serious need of these warnings will use - ignore all warnings. Kind of like those unit tests that just return true.
When something bad happens software-wise, the first question asked is often "What changed?" This has been going on long enough for "Changes break things" to become an aphorism (it doesn't follow logically, but that's folklore for you). Which led to, "If we make no changes, nothing bad will happen."
Except of course, "What changed?" is only one of the questions to ask; another is, "What didn't change that should have?" The latter has not yet entered the zeitgeist.
And here we are.
The sad truth is, changes too often result in something bad happening. Not making changes also too often results in something bad happening. Things are broken, and no one with the power to fix them has any interest in doing so as they make a tidy living off the current state.
The problem is that changing things breaks things, not changing things breaks things, what we have is broken to start with, and you kids won't get off my lawn.
There doesn't appear to be a solution. Everyone shrugs, says "the perfect is the enemy of the good," and makes do with systems conforming to an ever lower bar designating "good enough."
While the article qualifies the usual assertion of a developer shortage by noting a shortage of good developers, I simply cannot see the difficulty.
We all know the definition of a good developer, it's someone who delivers on time and on budget. Accomplishing this goal merely requires a calendar and a calculator, both of which are included with Microsoft Windows and all the other (admittedly minor) players in the desktop and server space.
The CASE tool renaissance of the late 1980s taught us that the act of writing code is so trivial a task that it can be automated. The Y2K crisis taught us that anyone can engage in the act of writing code having augmented their keyboarding skills with a "Learn language in n [hours|days|weeks]" book.
Disabusing decision makers of the above load of equine excrement is going to be difficult. In the middle of the last decade of the previous century I recited to my boss that old saw about "cheap, fast, or efficient - pick any two." He replied that he'd heard that one, and he wanted all three. I took another offer soon after. And no lesson was learned.
The mindset that software developers are resources to not just be used, but used up is pervasive. That software development and project management are othogonal remains unknown to those who design org charts and compensation plans.
This is not a problem that gets fixed by adding more developers, no matter how good they are.
Possibility three, the world does not work on the "that which is not mandatory is forbidden" rule and therefore companies have the freedom to treat their employees decently even if the law doesn't require it.
Which is the essence of my first reply, do try to keep up.
Ceteris paribus, yes - but not necessarily so. It's more work than it's worth to me to redesign the entire socioeconomic system when the number of thumbs up on the original indicates the masses have already absolved Amazon of all responsibility for their actions in the presence of a government to blame.
There are two flavors of DB2, the one that runs on IBM Z and the one that runs on Linux, Unix, and Windows (LUW). Last I knew, they did not share a code base, or shared very little. This affects the LUW version. In future I would suggest making that clear in the article. Perhaps even the headline.
Yes, yes, I know IBM is a failure as a company because it's losing money (except for Z) and no one uses Z (except those who trumpet about their third 5-year plan to migrate to whatever is trendy these days) and so on and so forth ad infinitum ad nauseam etc. etc. etc.
The problem with this approach seems to be the presumption that there exists something in the world that does what you need. This often seems to lead to evaluating various promises from an assortment of contracted custom development solution providers with an eye towards selecting the least bad amongst them.
A lesson from long ago: if you find something that does most of what you need and a feature is that you can customize to make it do the rest, you will regret your acquisition as the customizations will create no end of difficulty when you eventually reach a point where you have no choice but to upgrade. See, that "most of what you need," that was the easy part. The difficult part, the part that you can't live without, that's the part that is unique to your organization. You can't buy that part.
Application development seems to have devolved into the artifice of mercilessly stitching together tools and libraries into frankenmodules to be tortured into a lurching semblance of functionality.
This isn't computer science, and it isn't really application development either. It shares lineage with overloaded, multi-sheet, macro-laden Lotus 1-2-3 spreadsheets occasionally shelling out to DOS to execute the odd GW-BASIC program or some utility downloaded from PC Magazine. Brittle superstructure resting on shaky ground.
master with main across its services
Agreed, regarding out of date; old != bad, in fact sometimes old is preferable to new when licensing changes in a manner unfavorable to the customer or the latest version insists on phoning home to a server for reasons unknown.
Unsupported is something for risk management to consider.
Insecure still needs to be addressed.
While I appreciate the snark at El Reg as much as the next commentard, sacrificing news and fact for snark is a waste of talent. This reads like someone shouted, "Quick, three or four hundred words on that new Apple thing!"
More interesting would be how it's selling. There's been a trend towards mobiles getting larger and larger as people use them for content consumption instead of communication, how does the market react to a comparably tiny mobile?
If you can't say something interesting, or at least funny, say nothing at all. Points off for quoting this last back to me.
Twenty-mumble years ago, I came into support of a roll-your-own DB/DC system built in the 1970s. It was kind of creaking, but we were in year twelve of the ten year migration out of the system and management wanted no maintenance done. My senior and I ignored that, quietly declaring that any production problem would be met with our intent of making that problem never happen again.
At the time, the system was executing ~2,000,000 transactions every business day during prime shift. We used to say, if it's a one-in-a-million chance, it'll happen today, twice.
It's nice that Google has learned these particular lessons that mainframe people knew decades ago. I wonder if they'll learn the rest?
The modern version of "build vs. buy."
The multiple vendor problem is well known: when the inevitable problems arise the vendors point at each other assigning blame until they ultimately assign blame back on the client.
The single vendor problem is the solution to the multiple vendor problem: have a single vendor so that, when the inevitable problems arise, you have but one vendor to tell you to it's all your (the client's) fault, saving time.
These two positions have been ping-pong-ing off each other for decades, contributing to the fortunes of consultants and vendors, to the detriment of clients worldwide.
There's already outsourcing and cloud here, just add DevOps and you'll have the trifecta.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
