OT: Bug versus Feature
 

Whether something is a bug or a feature is based off the rule of unintended consequences. You design something that results in an unintended consequence. If that consequence is positive, it is a feature. However, if that consequence is negative, it is a bug.

Using a specific example: Drones were designed with no "move to" capability resulting in the unintended consequence that drones can not do recon. Since I think that the majority of people believe this consequence is negative, this consequence is a bug.

Yes, drones were designed with no "move to" capability, but that does not mean the design didn't cause a bug.

Bugs can be caused by
Sloppy keystroke entry (syntax)
Poor programming design (logic)
Poor concept design (unintended consequences)

Re: OT: Bug versus Feature
 

<blockquote><font size="1" face="Verdana, Arial">quote:</font><hr>Originally posted by Jourin:
Whether something is a bug or a feature is based off the rule of unintended consequences. You design something that results in an unintended consequence. If that consequence is positive, it is a feature. However, if that consequence is negative, it is a bug.

Using a specific example: Drones were designed with no "move to" capability resulting in the unintended consequence that drones can not do recon. Since I think that the majority of people believe this consequence is negative, this consequence is a bug.

Yes, drones were designed with no "move to" capability, but that does not mean the design didn't cause a bug.

Bugs can be caused by
Sloppy keystroke entry (syntax)
Poor programming design (logic)
Poor concept design (unintended consequences)<hr></blockquote>

I would have to disagree with calling current Drone functionality a bug. Disagreement about a design decision doesn't make it a bug.

The designers vision of Drones was attack only, he designed it that way, he coded it that way, it works that way.

Unless there's a user requirements specification we signed off on to say that drones should have "go to" capability then it's not a bug in my usage of the phrase "software bug".

Re: OT: Bug versus Feature
 

"unintended consequence that drones can not do recon."

Who says it was unintended?

In any case, that will be my sole shot into this thread. I really doubt this will decide anything at all http://forum.shrapnelgames.com/images/icons/icon7.gif If you really want to get something done, email MM and *politely* *ask* about adding the move-to function to drones.

Note the politely.

Phoenix-D

Re: OT: Bug versus Feature
 

First: The definition of “bug” is not correct IMHO. It does not depend on the consequences if something is a bug or not. Else the graphics of SE4 are a bug. Or is there anyone out there that will really argue that the graphics of SE4 can compete with state-of-the-art graphic? I know, this was done deliberately but your definition only ask for the consequences and these are negative – it is not as good looking as it could.

Second: Drones were designed not to recon. Aaron KNOWS about it. It was done as it is nevertheless with a seeing eye.

Third: Ask MM to change it if you don’t like it.

Re: OT: Bug versus Feature
 

Jourin,

I totally agree with you that one should at least be able to mod drones to have "move to" ability. And I think you are right to be disappointed.

However, I don't think "bug" is the proper term. I would call it a "design mistake" or "error in judgment" or "concept problem." I think MM made a poor decision, but I don't think they cheated anyone.

Your definition of "bug" is too broad. Someone might say that guns without integral trigger locks have a "bug" because a child might shoot it with bad consequences, contrary to the designer's intention. And if the designer fixed that, then someone else might cry "bug" because a child could still get hold of the key. And if the designer then made the gun so it only could be operated with adult-sized hands, then someone else might cry "bug" because now midgets couldn't use it but teenage boys still could. So then the designer fixes the "bug" by putting fingerprint ID into the gun. Finally someone sues the gun maker because a properly registered and IDed adult gun owner kills his neighbor's yip-yip dog with it at 2 am. Clearly the gun was defective since it produced consequences that someone didn't like.

Is McDonald's coffee "buggy" because it is served piping hot, and some idiot might try to drive with it between her legs?

You need to remember that Aaron is a normal human being with professional pride. He is not likely to respond well to accusations of cheating people, and may very well become obstinate about the issue. Hence, people are getting on your case, telling you to cool it, shut up, act nice, etc. I think that with time, if enough of us ask politely and often, that Aaron will give you what you want.

Re: OT: Bug versus Feature
 

I have done 3 years of telephone support for Microsoft. I presently do desktop, (in person support) for computer Users.
The following definition of “Bug” is the one accepted by the vast majority of computer professionals and Users in general.

Bug: A feature within software, firmware, or hardware that does not function as the designer of that product intended.

I can state that it in no way has anything to do with weather or not the user of that product likes the feature.

I agree with: "Make a polite request to MM".

Re: OT: Bug versus Feature
 

I am not saying that MM cheated me, and I really do not want to debate whether drones have a bug or not. I was trying to define the difference between a bug and a feature. I was trying to educate people so they would not make false or inflammatory statements, nor assume that I was making false or inflammatory statements.

I am an application and processes designer. Although I started as a program writer and work closely with them, I no longer actually write the code. I am like an architect who designs the house that the builders build, or in this case an application or process that the coders code.

If I design something that is programmed and coded perfectly, but the result has a negative impact on the process, then I have designed a bug into the system. Just because the program was coded perfectly per the design doesn't mean the program doesn't have a bug.

If I design a house with a grand cathedral ceiling, that is built exactly to specifications but the result is undo stress upon a weight bearing wall that makes the ceiling unstable; is the house not defective? Does the house not have a "bug?"

The problems with most software applications and computer games are all design related. The application or the game has a bug because of poor design not because it was coded poorly.

The statement that a bug can not exist if the program was coded per design is false, invalid, and incorrect. A bug is a problem whether it is caused by poor coding or poor design. In fact, most bugs are caused by poor design which is why they are so hard to find.

If you don't accept this definition that is your choice, but then you are letting all the designers off the hook and do not complain when you receive poor quality product. I am in no way implying that SEIV is poor quality.

The only time I was not polite was in replying to what I perceived was a flame attack.

Re: OT: Bug versus Feature
 

Jourin,

You can attempt to change the perception if you wish, but you did accuse MM of cheating you when you stated that you had paid for apple pie and received apples instead. How else could that possibly be taken? And most reasonable people would have taken that as an impolite remark. And it was the reason for your being warned, not because of your opinion about the facts of the discussion.

Your analogy of the house is flawed. SEIV gold is not unusable because drones can't "move to". You are simply wanting them to do something they were not intended to do. It really is as simple as that no matter how hard you try to change the terms of the debate.

This is not a result of poor coding. It was a concious and direct decision on the part of the programmer. Given enough input from the customers, MM may infact decide to modify drones to allow them to "move to". We will just have to wait and see.

Things such as the fighter stack bug, and the counter intel bug were bugs. They were a result of mistakes in coding, or the result of unintended consequences.

Drones only fit into that Category if one accepts your definition of the word "drone", which requires by nature that they be usable in those ways. That is circular logic. You cannot prove anything that way.

Geoschmo

[ 07 February 2002: Message edited by: geoschmo ]</p>

Re: OT: Bug versus Feature
 

Ya, I think Jourin means "design flaw", not what most would call a "bug." Trying to stretch the term "bug" to include flaws "by design" is likely to just cause confusion.

PvK

Re: OT: Bug versus Feature
 

<blockquote><font size="1" face="Verdana, Arial">quote:</font><hr>Originally posted by Jourin:
The only time I was not polite was in replying to what I perceived was a flame attack.<hr></blockquote>

I don't know if you took my post as a flame attack. If so, I would like to apologize. I never intended to flame you. I'm sorry, if I offended you.

The whole "bug" things resolves around which persons view on the working mechanism counts. You say, it is yours/the customers, I would say in the first place the view of the programmer/designer. Of course it would be wise of the programmer to unify his view with the view of the customer...

Re: OT: Bug versus Feature
 

This is a bit off-topic for this topic, but actually gets back to the original topic, so here goes:
Who else besides Jourin and his two nephews would dearly love to see drones have the "move to" order (at least optionally, either through a checkbox or a mod)?

It has my vote, so that makes 4 of us.

(And it wouldn't be hard for Aaron to do, now that he's got drones.)

Re: OT: Bug versus Feature
 

I work with internal customers and they call anything that doesn't work whether it is a design flaw or poor coding as a bug. If the program or application does not work as expected then it has a bug.

I can never tell my customers that the problem is technically not a bug it is a design flaw. I would rightfully get my butt chewed.

Comments like "bugs can not be caused by poor design" or "its a feature not a bug" did get me upset. I took those comments as resistance to the idea of drones having recon capability and wondered why all the hostility to the idea. I then felt that my idea of using drones for recon was being attacked and that any criticism of SEIV was taboo.

I think I was wrong, but as some of my Posts were interpreted incorrectly, I may have interpreted other Posts incorrectly.

[ 07 February 2002: Message edited by: Jourin ]</p>

Re: OT: Bug versus Feature
 

<blockquote><font size="1" face="Verdana, Arial">quote:</font><hr>Originally posted by dmm:
This is a bit off-topic for this topic, but actually gets back to the original topic, so here goes:
Who else besides Jourin and his two nephews would dearly love to see drones have the "move to" order (at least optionally, either through a checkbox or a mod)?

It has my vote, so that makes 4 of us.<hr></blockquote>
I would like to see it added.

Re: OT: Bug versus Feature
 

Jourin,

Criticism of SEIV is encouraged here I think. I dont think anyone was attacking you for your opinion that drones should have "move to" ability. In fact many of us agree with that opinion.

A design flaw or poor coding would be defined as a bug by just about anyone. The difference is here that drones not having "move to" is neither of those.

This is not a bug anymore than fighters not being able to warp, or units not being able to carry cargo are bugs. These are things that many of us would like to see implemented, but they aren't bugs.

I don't think anyone was hostile to the idea of drones having recon ability. Some have disagreed with it, but most of them even agree it would be nice to have as an option in the settings. Some people may have expressed the opinion that it is unlikely to be changed, but the only opinion there that matters is Aaron's, so it's not worth getting upset over.

Many of us on the beta team asked to have drones given the ability to do recon. In fact drones in the original beta patches couldn't even be given new attack targets when the first target was destroyed. I do not know whether that was a specific decision on his part, or an "unintended consequence", but either way that was changed. Now if the original target is destroyed they can be given a neww target to attack.

If anyone got defensive at you it was not because of your opinioin, but because you seemed to be personally attacking MM's programing ability or his intelligence. It appeared as if you felt that drones HAD to have recon ability, and if they didn't they were broken, and anyone who felt otherwise was a rube. Of course you didn't say that, but that was the impression people were getting from your comments.

It's good that we can now discuss this without all the empotions. That is the way to get things done in a constructive manner.

Geoschmo

Re: OT: Bug versus Feature
 

geoschmo,

Thank you for your insight into drone development.

Reference fighters not being able to warp: If your expectations were clearly set that fighters would have the capability to warp, and when you discovered they couldn't, you would have a legitimate reason to consider that a bug, independent of the fact that fighters are not designed to warp and are functioning as designed. However, I believe the fighter capabilities were clearly stated, so do not believe this could be considered a bug.

I have a clear expectation that drones would have the capability to provide warp point recon, clear warp point minefields, and do pre-warp point assault bombardment. In a series of e-mails with Aaron in Jun-Aug 1998 time frame I sent in some ideas for improvements to SEIII/ideas for SEIV.

Based on the novels In Death Ground and Crusade, by David Weber and Steve White based on the Starfire system, I requested a missile probe to recon warp points, a mine sweeping missile, and a warp point assault missile. I received an e-mail back from Aaron that said something like, Great idea, see drones in SEIV. My expectation at that time was set that drones in SEIV would have these capabilities. Nothing I have every seen or read has changed that expectation. Also the name drone implies, to me, recon which continued to reinforce my expectations.

My first reaction was that the code is not working and Aaron will fix it prior to the Gold release. Then from a lot of Posts, I got the impression that the Beta Testers, for some unknown reason, talked Aaron into removing this capability. Couple this analysis with the irritation of "it can't be a bug if it was designed that way", and "its not a bug, its a feature" and you have the basis for my responses.

The analysis was flawed and so I apologize for some of the comments I made. Currently I can not fathom why Aaron did not design the other drone capabilities from the start.

PS: One of my other recommendations was that fighters have the ability to move in system but not have the ability to Warp - sorry.
Of course I am not the only one who made recommendations.

Re: OT: Bug versus Feature
 

While I don't like apple pie ( http://forum.shrapnelgames.com/images/icons/icon12.gif ) I sure would like recon capacity for drones.

Can anyone point me towards Aaron? Easiest by email?

Re: OT: Bug versus Feature
 

Jimbob - malfador@malfador.com will work.

I want "move to" and "warp" buttons for drones too, or ideally, options for whether those should be available or not (though I don't think I'd ever turn those abilities off, myself).

There are so many basic precedents for recon drones that I don't see why these should be disallowed. Earth probes like Voyager and Viking, the recon robot at the beginning of The Empire Strikes Back, modern real-world recon robots, etc.

The few people with reservations about it seem to want them to be harder to control that ships... maybe if "move to" orders could not be cancelled (as current drone attack orders can't be) that would appease these misgivings.

PvK

PvK

Re: OT: Bug versus Feature
 

<blockquote><font size="1" face="Verdana, Arial">quote:</font><hr>Originally posted by PvK:
The few people with reservations about it seem to want them to be harder to control that ships... maybe if "move to" orders could not be cancelled (as current drone attack orders can't be) that would appease these misgivings.

PvK<hr></blockquote>

I think this is an accurate statement. The concerns that I have seen raised are that this would blur the lines between ships and drones.

If you could make swarms of no-maintenance drones and control them the same way you would ships, why would you build ships? The inability to resupply is not enough since you could put a QR or solar panels on them and wouldn't need to resupply.

I would still like to see the move-to order added, but I can understand that reservation to it.

Geoschmo

Re: OT: Bug versus Feature
 

Perhaps we should be requesting a sub class of drones or a different unit alltogether, maybe call them probes, that can receive more complex orders such as move-to, wapr, and sentry, but cannot be fitted with weapons.

Geo

Re: OT: Bug versus Feature
 

"The inability to resupply is not enough since you could put a QR or solar panels on them and wouldn't need to resupply."

Simple enough solution- don't let them carry those items! http://forum.shrapnelgames.com/images/icons/icon7.gif

Phoenix-D

Re: OT: Bug versus Feature
 

True. And I haven't double checked the files, they may not be allowed now, but it would be a simple matter to mod them in to be able to if they can't now. And I suppose that would be the responsibilty of the modder for making them a possibly destabalising element.

I was simply explaining what I believed to be some peoples reason for not wanting the ability, since it was mentioned by a couple that they couldn't understand why everyone wouldn't want it.

Geo

Re: OT: Bug versus Feature
 

You know, a "Probe" class would be awesome, especially if higher-level Versions were long-range, fast, and maybe long-Lasting.

And what would be REALLY great, would be if these were fitted into a proper diplomacy system. So, probes could pass through fleets, minefields, and systems of non-enemies without requiring permission or generating ill feeling. But warships could NOT do that. They would either need special permission or would need a higher level of treaty (e.g., partner). Also, maybe you should need to be in actual contact with another race to send Messages. ("Actual contact" here means you have a ship, planet, or probe in the same system as a ship, planet, or probe of the other race. One problem would be the "loss-of-contact amnesia" that the AI suffers from. But that bug ought to be squashed anyway.)

Re: OT: Bug versus Feature
 

Nice probe idea. I wonder if the AI gets mad about drones in its space, currently. If drones had movement controls, you could include probes by making them small drones with certain settings.


I understand the concept of not wanting drones to be too much like ships, but I don't think giving them move orders would really do that.

Quantum reactors are not allowed on drones in Gold. Solar collectors are, but Sol Col III gives 150 supplies/turn, while a drone burns 200/turn even if it does nothing, and takes 20 kT of space.

Even if Q reactors were allowed, or a player uses 40 kT of drone space on two solar collector III's and/or keeps them in binary/trinary systems, I don't see these being confused with ships, or it being a balance issue. Quantum reactors are kind of expensive for a dinky drone (1000 mins) and take space (20 kT), and drones are small things - it'd be a big investement in a weak escort-sized vessel. There would be advantages over building actual escorts with Q reactors in the peculiar drone speed bonus, and the weird effect that drones are units and so don't suffer partial damage effects http://forum.shrapnelgames.com/image...s/rolleyes.gif and are not targettable by missiles or torpedoes http://forum.shrapnelgames.com/image...s/rolleyes.gif . However, in addition to being expensive, these drones are vulnerable to point defense, could not be retrofit, would not gain experience, would not be usable in fleets (hence no fleet experience), and couldn't carry cargo or the many other components not allowed on drones.

Personally, I'd think with a moveto order, that I might like to allow Q reactors on drones, just because it could be an interesting system to try to use. Of course, it's only about a four-keystroke mod.

PvK

Re: OT: Bug versus Feature
 

Pvk,

These are all good points. The one thiing you are not mentioning though that drones have over ships is no maintenance. While you are correct that drones would not be a lot better than escorts, but considering you could have thousands of them, and pay no maintenance on them, they would be very econimical in the long run, if given enough solar panels to stay supplied indefinetly, or if they were modded to allow QR's.

Geoschmo

Re: OT: Bug versus Feature
 

I'm keeping that in mind. However, even if you put two solar collectors on a drone, using 40 kT, that only covers the supply use from the per-turn expense - they'll still tend to burn their supplies up when they move or, if they have weapons, fight, or if they have to go in a system without a star. Even if this seems like a problem to some players, I don't think the answer would be to remove the move-to order option. I mean, as they are, drones can still be accumulated in thousands and given solar collectors. The lack of a move-to seems mostly like a separate issue, to me anyway. It seems like if you don't want to have long-lived solar collector drones, then mod a drone Version of solar collectors or something, or ask that to be changed in the standard set.

PvK

P.S.
Furthermore, no other units die when they run out of supplies, and only fighters even track supplies, and they can refuel at depots, while drones can't (I assume). Having a thousand move-to solar collector drones may be a nice no-maintenance asset and an interesting alternative to thousand escorts (which I can hardly imagine anyone building in the unmodded game set, anyway). However, the resource cost to build them doesn't seem like it would necessarily be better spent than on ships, or weapon platforms, or whatever. In fact, I'd be really surprised if it were not quite inefficient by comparison, except for its particular strengths. Most of the expense would be going into engines and other no-real-gain components, compared to a butch Gold-mount weapon platform, warship, etc.

PvK

[ 13 February 2002: Message edited by: PvK ]</p>

Re: OT: Bug versus Feature
 

While I keep in mind that this is Sci Fi and does not represent todays world.
There are "drones" used today that are so small and built like powered gliders that most lower tech "sensors" can not pick them up. These drones can be programed to:
Move To XY
Use Pasive "Sensors"
Record the data internaly
Return to Base
Where the data is extracted
The observed parties never know it was there.

In referance to the AI minding the presence of drones in its system:
I would love to have short range hard to detect "reon drones" that could be reused X number of times.
I could see these drones being so small thay could move through mine fields and past satelites with out being detected.
The one limit would be:
You can't get the data till they return to your system or a "Mother Ship"
Again, this is based on drones being given a "Move To" about which I feel indifferent.

Re: OT: Bug versus Feature
 

Nice idea and with Move-To, quite moddable (including bypassing mines). The idea of giving delayed-information reports saying what was there when they were is cool, but probably way too much work for MM to patch in just for this. Maybe if we get dated system information at some point.

Another major point is that no one suggesting move-to has suggested Clear Orders - units whose orders can't be cleared are certainly a lot less flexible than ships.

An additional restriction might be that the only way to give a drone an (non-attack? or all?) order would be if in the same sector as a friendly ship/base/colony - this would mean you could use move-to for exploration (especially if you could use the Explore order and stack it or set it to repeat), but drones would have to return to a friendly location to get new move orders.

PvK

Re: OT: Bug versus Feature
 

FWIW, the CIA has been using remote-control drones in Afghanistan for both recon and attack. (They have 2 Hellfire missiles.) Granted, this is remote-control, but we're not yet ready for interstellar colonization either, so I think drone manufacturers have some time to develop more independent operation.

Slightly off-topic: One drone killed a group of Afghans that included a tall guy with bodyguards. They are now comparing the tall corpse's DNA against the DNA of bin Laden's relatives. I kid you not.