Re: Aren't Government employees neutral.
>> Can you register for both/all parties to take part in all primaries?
It depends. There are open primaries, closed primaries, semi-closed primaries, and top two primaries.
103 publicly visible posts • joined 18 Oct 2009
>> Can you register for both/all parties to take part in all primaries?
It depends. There are open primaries, closed primaries, semi-closed primaries, and top two primaries.
First, good enough programming. We were all taught in the 1990s that good enough was good enough when Windows 3.x took over the world. It was okay that it crashed, sometimes multiple times per day. Crashes are okay so long as they don't reach a certain threshold, which is spongy and subjective and the subject of whim. Oh, look - flying toasters!
Second, Deadline Driven Development. Of course the software has bugs, but it's good enough (see above) and we've got a deadline! A meaningless deadline! A meaningless, arbitrary deadline!
Third, management engagement. As covered elsewhere in this comments section, software reliability is just one of management's many concerns and it may very well not be at the top of the list. The top of the list of course is the current deadline (see above).
Fourth, testing and code reviews. This requires a time investment that, given deadlines (see above), is one many organizations believe they cannot afford. This is a management and cultural issue.
Also, let us not forget that use-after-free and wild pointers are not the only categories of bugs in the world.
I did not attend the conference in question, so I don't know the entirety of what Ms. Easterly said. But the phrase "flawless code" does not appear in any of the article's quotes of her.
Drop the straw man of "flawless, perfectly secure code" and start with "more reliable, more secure code." Close the holes, fix the bugs, one by one. It takes years, and it's generally thankless. Welcome to your tech job future.
...who told me he had a user area pushing back against paying for database image copies. I explained these were to be used in case of a disaster. He replied, "I'll tell them it's like an insurance policy, something you pay for but hope never to need." No more pushback. Sometimes, people are sensible.
This seems like the outsourcing trend all over again.
Management has been saying "Who will rid me of these turbulent programmers" at least since the 1982 publication of _Application Development Without Programmers_.
I have no doubt that many unfortunate IT staff will lose their jobs, and those that remain will be told they have no excuse for not taking up the slack because they have been provided with Copilot or some other such tool. Time will pass, there will be turnover, and eventually there will be another hiring wave.
Kind of like insourcing after the outsourcing.
>>
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.