Do the Devs even test their code anymore?

O'rly ?

The national research council didn't get a memo from you, perhaps you should send them one.

http://sw-eng.falls-church.va.us/nrc/nrc-contents.html

Nice that you can get government docs as ebooks these days. I still remember paying through the nose for the standards and working off xeroxed copies.

What a gift for understatement you have. ADA, isn't just designed to be more structured and modular, its designed to make it nearly impossible to write unstructured code, and difficult to write non modular code.

If you could why don't you explain how having the largest customer for software in the world demand that all its new software be written using a language that forces certain practices on the programmer doesn't affect the profession ?


You would have to be insane to think they weren't pushing software engineering methodologies forward.

Must be nice to be able to speak ex-cathedra. Especially when standardization is a quality issue, for software. ITs also great that you have completely missed what the impact and lasting effects of the mandate were and are.


The problem was never the change, the problem was that nobody bothered to do the calculations relevant to the change.


The industry neither grants nor revokes professional engineering licenses. They are issued by individual states and are under their regulatory control. Which in Missouri's case means a politically appointed board.


Edit: Its amazing how much the post I am replying to resembles the OSI onion. I read it and was completely overwhelmed by the first layer while letting the mention of the OSI layers hit my personal snooze button. How can you can you compare a conceptual model to mandated programming language is beyond me. I can build network application that violate the OSI layer willy nilly. TRY to write an ADA program or A java program that violate their modularity models and you have real problems.

While not addressed to me, this comment makes me ask once again; what about all the text bugs/typos that have been in the game for years that I have personally reported via in-game ticket. Sometimes it's the minor details that color our opinions on something.

Again, we all love the game and most of us will continue playing until it loses that magic feel, but putting on blinders to existing inadequacies does nobody any favors.

Of the Ada directive? Honestly, I have no interest in addressing this particular topic with someone completely unqualified to discuss it. Its frankly offensive.

Standardization is a quality issue? Ahahahahaha. Unfortunately, I can't punish you for your stupidity, so I'm just going to have to take it out on the next idiot that suggests it. Standardization can be a tool to improve quality, just like documentation can be or pencils can be. But standardization does not, in and of itself, promote or enhance quality. In fact, a higher degree of standardization doesn't correlate to higher quality except extremely weakly: those that enact standardization efforts in some areas tend to have better habits in others.


The problem was the change was signed off on by the engineering team without *any* review. But to focus on the calculations is not understanding the lesson of the event, which is supposed to be obvious enough that anyone that doesn't shouldn't be talking about it much less be in a position to reproduce it. The change should have been rejected without a single calculation being made. The only thing calculations would have done is remind them that they were not supposed to do something that dumb in the first place. You do not "accidentally" sacrifice 50% of your design strength because you forgot to whip out your pocket calculator.

Might I ask, where those companies writing software to count money? Were they focused on keeping people alive, perhaps?

As I mentioned previously, there MUST be a rigorous commitment to such software as a base requirement or it won't work.

That same commitment is completely different from creating entertainment.

The goals, at a fundamental level, are different.

The flaws you see as a programmer are generally not even noticed by the average player. My friends that play, non programmers, never even noticed the map bug until hours of play had passed. They could not care less.

Another analogy, for example, from my personal experience. I was the lighting designer and electrician for a theater company. To this day, I cannot watch a live performance without critiquing the lighting infrastructure. My wife never even notices where the lights are and just enjoys the show.

Well, despite the size of the DoD-related government contract industry, the impact of their practices appear to have had little to no effect on programming in general, at least not in the US. Of the hundreds of programmers I've met and/or spoken to in three decades, not one of them has ever programmed a single line of ADA, been subject to the standardization methods articulated by ADA, or known anyone affected by them. The view from my 30-year perch is that ADA was created for, and used by a single isolated industry (non-financial government programming) and had virtually no bleedover into other software domains. Not scientific, not educational, not commercial, and certainly not entertainment. C and C++ dominates computer programming the world over; and I see no evidence that there are any hard and fast rules for best practices adopted by the majority of those paid to do it.

I used to work for a company that made very specialized real-time hardware for the civial aviation industry. In many countries civil aviation is actually a government-run entity, subject to whatever standards those countries have chosen to impose on such things. Not a single one of them, as a customer, dictated the language to use, the coding practices to employ, or the testing procedures to undertake in order to win a contract. And this included U.S. airports under the aegis of FAA custodianship. We programmed in C and C++, we adhered to our own (certified) ISO9000/9001 documentation requirements, and we had our own in-house QC department with its own testing protocols. The existance of ADA did not have a single bit of influence over how we wrote our code, and I am pretty sure nobody on the team, aside from myself, even knew the language (though I'm sure some of them had heard of it).

The only reason we had any stringent practices at all, such as they were, was because without a reputation for reliability and performance, we had no customers. Contrast that with the entertainment industry that I work in now where any "professional practices" remotely like I knew from my previous experience(s) are utterly alien concepts. I can only conclude that ADA had a profound and lasting influence on professional programming only in the minds of its architects, who nurture a fantastical notion of its legacy.

Tbh, I really don't get that part at all.
Surely there're enough resources to go in to very specific parts and edit text. Maybe I am wrong, but that doesn't sound like a resource intensive thing.
It seems like it's just "We don't give hoot."

It also makes me suspect that some of the other bugs fall into this category as well.

Not to put to fine a point on it, but for somebody that writes civil aviation software its pretty amazing you never met a programmer from Boeing

http://archive.adaic.com/projects/atwork/boeing.html
,
or any of these compainies.

Beechcraft, Fokker, Lockheed Martin, The Tupolev aircraft company, The Ilyushin design bureau, BAE ?

Its pretty big for life critical aircraft systems.

But anyway, how many people do you know doing commercial coding in Haskell, Refined-C, Algol 60 ?



Then you have been affected by the process and thinking that went into creating ADA . Standardization, heavy use of code review all came out of the methods the D.O.D were pushing with that.

Oh and btw don't take this the wrong way, but what was your product ? I have no wish to get anywhere near an airplane that is reliant on C or C++ code.


I am sure that has nothing to do with the fact that the FAA mandates such practices on anything that flies.

Nice.

And by "nice" I mean exactly the opposite of nice.

The primary impact Ada had on programming was in the thought process that went into the design of the language, for which people eventually picked up and adapted for other languages. But that's just the development of better tools: the impact of the DoD directive itself was to create a lot of Ada cheerleaders in the 80s, most of which were embarrassed into shutting up in the 90s. At one point there were people trumpeting that one day we'd all be coding in either Ada or assembly. It took a decade, but the rest of the world had the last laugh there.

Its not that Ada is a bad language: it has a lot of good qualities. But none of them specifically prevent poor quality or even encourage good quality, because good quality is not something encapsulated in syntax. Take the Ariane 5 kaboom. An Ada project. But if you look carefully, you'll see that Ada wasn't the cause of the failure, nor did it mitigate it. Ada was mostly irrelevant to it, because the problem was not in not obeying the language dictates, but in misusing them. As is true for most programming languages. A language can force people to obey your syntax, but a language cannot influence people to write good code. The promise of a language that will encourage good coding practice happens every few years: Ada, Pascal, C++, Java. Its only taken, what, thirty years for people to figure out that its good frameworks that encourage good programming practice, not good programming languages, because people tend to emulate their implementation.

I suspect that there are people who collect bug reports and throw them into various bins labelled by urgency rather than ease of fix.

Working from the 'most urgent' bin down to the 'least urgent' bin, I suspect you won't get to "spelling errors' for awhile.

I further suspect that you are more likely to get a spelling error fixed by PMing Avatea, Zwillinger, or War Witch than by filing a bug report.

I have a theory about that which I haven't specifically discussed with the devs, so this is just a theory and not the devs talking here. But there is a certain amount of overhead to addressing any bug: you have to check out the right code or resources and fire up the right tools or other utilities necessary to view them, edit them, document the changes, etc. A ten second spelling error could take ten or fifteen minutes for a dev to get into the right "position" to fix. So single spelling errors are actually far more costly to fix than they might appear.

On the other hand, if someone were to collate a large number of them together, with enough information to rapidly and conclusively find them, and put that in a single submission to the devs, that might be something that rose to the level of being worth addressing, because it may be more efficient to address dozens of them or even hundreds of them at once. Their bug system might not collate them automatically like that. A big bunch of them might be something they could hand off to an intern or something and have them go through and do all at once.

I don't know if anyone is actually interested in collating spelling errors, but it might make them likely to be fixed if someone was.

AFAICT, there's a large collection of spelling error reports at the inbox of wherever the bug reports go.

We weren't involved in the aircraft industry. We were involved in the airport security industry.

I think this gives too much credit to Ada. Those concepts were well established within the discipline long before Ada became a ratified standard. Back when software design encompassed much smaller applications, fewer interacting modules, and much simpler hardware architectures, ideas like standardization, code re-use, and self-documeting code were easy to institute on a company-by-company basis. No governing body was required, nor was it available. By the time Ada came to the show, it had already started and was well under way, so to speak.

The product (line) was a series of X-ray machines that detected the presence of plastic explosives (and more comprehensive bomb-like devices). If the fact that they were coded in C and C++, by programmers of all skill levels from extraordinary to barely competent, keeps you up at night wondering if you really should fly anywhere ever again, I don't blame you.

And, no, the FAA did nothing of the sort to mandate production practices on anyone in that particular branch of the airline security industry. We were not government contractors to the FAA or the US Government. We were merely a vendor that the airlines bought product from. All the FAA did, and it took them almost a decade of constant harrassment from the very Congress that mandated them into action following Lockerbie, was institute a dubious process (defined mostly by politics, not quality performance criteria) for certifying systems purchaseable by airlines in the US.

Sure why don't we have every programmer working on a project use their own somewhat idiosyncratic method of having their modules talk to everyone else's and while we are at it, lets not document them or write anything down.




That is what I said glad you agree.

So the way you do things, is when the people putting your design together tell you its unworkable, and propose a change you don't even check ? I suppose it should bother me I find this believable.


No doing the calculations would have told them they were way out of building code requirements for the design and had a design that was inadequate.

ADA was certainly part of the wave that was going on at the time. You had serious work being done on provably correct systems, there was IIRC a microprocessor built for the British military that had a provably correct instruction set. Maybe ADA didn't have that big an influence, I can't look at java and not see the misbegotten child of ADA and C++.

I certainly see ADA's big philosophy of preventing the programmer from having detailed knowledge or the ability to exploit the platform they are programming to all over the place.


The product (line) was a series of X-ray machines that detected the presence of plastic explosives (and more comprehensive bomb-like devices). If the fact that they were coded in C and C++, by programmers of all skill levels from extraordinary to barely competent, keeps you up at night wondering if you really should fly anywhere ever again, I don't blame you.

When you said real time life critical, I thought avionics.

OMG you are actually uncertain about something. Isn't that a first.

Indeed, maybe Ada didn't have that big an influence after all. In my estimation, it certainly can not be credited as having changed how an entire profession did/does its job.

Moreover, I still think it is odd to call it "ADA's big philosophy" since most of what Ada encapsulates conceptually is just the culmination of ideas already put into practice for years, whether formally or informally. It seems more honest to simply say that various "best practices" evolved over time, culminating in a language called Ada, which was then applied to one particular corner of the discipline, and then promptly ignored by the rest of the profession in favor of other great concepts du jour like Rapid Prototyping and Extreme Programming.

Well, I did say real-time. Never said life-critical. Our systems had to be real-time because no airport in the world wants their operations slowed down for a machine that looks for plastic explosives. Maybe if they looked for vibrators in flight attendants' luggage, but nothing short of another terrorist incident involving a bomb on a plane was going to make real-time performance--even at the cost of detection accuracy--anything but the very top priority.

That's an over broad generalization of what I was trying to say. My statement was in response to

The ADA mandate forced change down a significant portion of the profession's throat.

The above its even sillier when considered in the light of the discussion that has come after. There really isn't any profession where a practitioners great mistakes are bandied about unless they are too obvious to hide. When we have big disasters that are traced back to software failures changes are made. The problem is in talking about software engineering, or any engineering as one profession. People who write search engines, aren't really in the same profession as people that write software for running a LASIK, and they aren't in the same profession as people who write financial applications for banks.

The Hyatt regency disaster itself didn't affect the entire engineering profession or even all the civil engineering profession. I don't know for sure but I would bet that few if any states other than Missouri changed their laws because of the disaster, if even Missouri did.

In software , the big mistakes were taught even back when I was learning the craft and we didn't have as many to study yet. If you want to hear about them you can just read any of the software engineering journals. Why software fails is a perennially big topic

So did the ADA mandate have an effect ? It certainly made many people think about concepts they wouldn't have otherwise. There are many industries that embrace ADA and the methodologies that went along with it now, life critical applications come to mind.

On the other hand we live in a world where COBOL won't die.

I think what he was saying is that game's developers responded to the players' demands that ALL the bugs be fixed before they released new content.....and no new content came out ever again.

And that caused players to quit until the game was shut down for lack of profit.

How long would CoH be around if they decided to drop everything else they are working on and work on bug fixes until every last bug is gone? That means a potentially infinite cycle of bug fixes, because fixing one bug frequently creates a new one somewhere else.

At some point you have to say "Screw it, we'll fix that one later. The game still works, so it's not the end of the world.", or you'll end up in the circle of bug fix hell.

Originally Posted by Dechs Kaison See, it's gems like these that make me check Claws' post history every once in a while to make sure I haven't missed anything good lately.

Yeah.....that's pretty aggravating.

Originally Posted by Dechs Kaison See, it's gems like these that make me check Claws' post history every once in a while to make sure I haven't missed anything good lately.

This rather well sums up why I gave up and uninstalled the CoH Beta client. I got tired of being prompted to update an install that was very apparently useless, as far as its stated purpose was concerned.

The last time I experienced this much of an apparently deliberate case of willful deafness, I ended up divorced...

To be honest I wasn't even surprised or mad. Yeah that sucks a lot, but it actually did not surprise me one bit to the point that I just thought 'meh I have to put all my powers back'. Not that I don't see a reason to get angry, it's just how my expectations are these days