Ethics 101: To re-use or not to re-use?

[ntroup]

As it seems that this should somehow make a difference, I, as well, write software for a living.

With that said, I have to agree with those agree that software is different than other components. Yes, I agree that software is a part of the robot, and, in fact, it is a integral and critical component. But it is fundamentally different than hardware.

I see a few arguments to that. One being that re-typing the code allows one to support this rule. But how is that really any different than copying/pasting, or checking out a version from your favorite source-code repository. There isn't a difference, other than potentially introducing typos that require more time to debug. This doesn't seem like a productive use of time for teams.

If you have a known good design/algorithm/function, why try to re-invent it. You only have to invent the wheel once, then you use it, because you know how it works. The same goes for Omni-Wheels, Transmissions, etc.

As said before, if the argument is that it is faster for teams to copy/paste or checkout a version than rookie teams, then how is it fair for teams to have CAD files that will generate all the components needed for a mechanical design at a moment's notice.

The rule says this:

However, the specific lines of code must be customized for each robot each year.

Since no game is going to be the exact same each year, this is going to always be true. The code will have to be customized for that game. As Jack eluded to, I doubt there will be PoofBall throwing robots next year. BUT, I can definitely foresee teams needing to track lighted objects on the field. To have to completely re-write that from scratch, as others have inferred, would be pointless AND difficult.

Each year is a learning experience. And each year, teams learn and perfect various pieces of their robot. To have to force team's to re-perfect any component each year, be it hardware or software, seems like a step backwards in where this program is aiming to go... to create those that go one step beyond.

-Nate

[Mike Martus]

So where does this put programs like Easy C. They have many modules already written and ready to drag and drop. For us NON programmers this was a savior for my students.

So easy to use, re-creating a new code from scratch for 2007 using existing modules within the program is the way to go, once we design the robot of course.

I think this meets the rules. Am I wrong?

[Dave Flowerday]

Originally Posted by Alan Anderson

Dave, I infer from your posts that you consider the source code for a software module to be the equivalent of the blueprint for a hardware assembly, and the compiled bits to be the equivalent of the assembly itself. Is that a fair assessment of your opinion?

Not really - my point is that you cannot equate the software directly to a mechanical piece. I contend that a software implementation (especially in C) includes elements that are roughly equivalent to the design of a mechanical part AND elements that are roughly equivalent to the fabrication of that part. So all I'm saying is that it's unfair to treat the software as either the direct equivalent of mechanical design or the direct equivalent of mechanical implementation.

I feel strongly about this topic because treating software as if it were equivalent to an implemented mechanical part is an error that is being made not only here in FIRST but in industry as well. Many companies are starting to treat software implementation as a manufacturing job - something that is able to be farmed out to any group which claims to be able to write software. The fact of the matter is that software engineering is a very immature discipline - unlike other engineering practices, the tools and processes in software have not been developed to the point where the design and architecture can be cleanly separated from the implementation. The tools and processes we have to do software design with right now do not allow us to create a design which can be implemented blindly by someone writing the code without them having to interpret the design, "read between the lines", and generally know how something is supposed to work.

In FIRST, you can take a blueprint (either one you created or something you're borrowing from another team), send it out to a machine shop, and they can send you back a finished part. This machine shop really doesn't need to know anything about how the part works or how it fits into your robot or anything. Right now there is no equivalent to this with robot software - there is no artifact which your team has that you can ship off to a 3rd party software shop and have them build you the exact same software that you had from a previous year.

So, I come back to my original point, which is stop trying to equate it to something from the mechanical world and instead focus on making rules that makes sense and address the underlying concern. To be honest I'm not sure 100% what the underlying concern really is (if someone truly knows please respond here and fill me in), but I suspect it has something to do with wanting the new kids to learn and have the experience of writing the software that the kids from last year did. Now, if this is the case, how is reusing software from last year (which the new kids didn't write) any worse than using Kevin Watson's software (which the new kids didn't write either)? How is it any different for my team to reuse camera code that we ourselves wrote in a previous year than to use Kevin's? What problem are we really trying to solve with this rule anyway? Is this just another attempt to make things more "fair", even though Dean repeats often that this competition is not fair?

When a similar rule to this first came out in 2005, it was clarified that year that anything written after ship date would have to be retyped at competition. We diligently followed this - we had 4-5 people sitting at the top of the stands furiously retyping code at Boilermaker on the practice day. Many people came by and asked what on Earth we were doing. When we explained that we were retyping all the code that we wrote after ship date, they almost all said "Oh, I didn't know we were supposed to do that. We didn't retype ours..." So, it's great that people are talking here about what high standards everyone holds in FIRST and everything, but I personally believe the vast majority of teams really are just ignoring this rule, which ends up punishing the teams who honestly try to follow it.

[aaeamdar]

Originally Posted by Al Skierkiewicz

We have to get people back into the mode of realizing rules and following them, automatically. We know what happens when people don't follow rules. Lay, Skilling and others not only lined their own pockets they did so at our expense and the millions of people who depended on their retirement accounts to get them through their golden years.

As cliché as it may be, you're comparing appples to oranges. The crimes perpetrated by the Enron execs were by no means victimless. Lay and Skilling lined their pockets, but at some level, they must have known that what they were doing was wrong.

Personally, I've always been one to question authority. That's just the way I am, and it's not likely to change. I go to a school with a philosophy that rejects arbitrary authority. If you can show me someone who would be hurt by a team re-using previous years' code, I'm all ears. However, FIRST does seem to be asking us to reinvent the wheel each year (to a certain extent) while at the same time giving us large sections of code that we're not even meant to look at, much less understand. How is it a valuable use of time for teams to re-type code from last year?

Furthermore, if FIRST is looking to really level the playing field between rookie teams and veterans, there's a whole lot more that they could be doing. Veteran teams, if you're really looking to burn their time, could be forced to fill out long questionaires during each build season. How is this better than asking teams to re-type code?

To those who are saying that it's silly for FIRST to require teams to re-invent the wheel (as chris31 seems to be saying), do you think that this is what the rule says?

Thanks for all your collective input,
Paul

[ewankoff]

From the way this discussion is going it looks like many people are not looking at the real intent of this rule. FIRST's goal is to teach student about technology, science, and engineering. When a part is fabricated student gain expierience with that part and machines used to make it. The rule inquestion, I beleive, is to force students to learn how to program and create code that works. If a team has already perfected code then this rule does not outlaw reuseing but only forces teams to re-implement it. The re-implementing of the code forces students to figure out how to make that specific code work with this years robot. If a team was required to retype or copy and paste then no-one benefits and does not coincide with the goals of first. The only thing that should be taken into consideration when copying code directly is that students should learn how it works and what makes it tick then the goals of FIRST are being fulfilled.

[Not2B]

Here's how I look at it...

The algorithms and designs can be re-used, but not the actual code. Thats GREAT!

This means you can let the new students look over the design or psudo-code, and see if they can build the software as a way of learning the program, and the older students can check and guide the new students.

Re-using the code seems like a lost opportunity. But then again, we aren't out there to win the game, just win... stuff for ourselves.

[Steve W]

I am convinced that rewriting software is now bad and copy and paste is good (tongue in cheek). Now the fact that I am a builder I can use the same reasoning for using a new drive base that our students have spent all summer and fall fixing and building. Why should we have to rebuild an already good working unit? I would even say that because the students built it that it has more validity than coping someone else's software.

[seanwitte]

Originally Posted by Steve W

I am convinced that rewriting software is now bad and copy and paste is good (tongue in cheek). Now the fact that I am a builder I can use the same reasoning for using a new drive base that our students have spent all summer and fall fixing and building. Why should we have to rebuild an already good working unit? I would even say that because the students built it that it has more validity than coping someone else's software.

That's not a valid analogy. The rule states that you can not reuse existing hardware or software, but you can reuse the design. This is a flawed system because the manufacturing costs of the two artifacts are different. Once you design a part, the cost to manufacture it, both in time and money, is roughly the same from that point forward. You may be able to make it a slightly faster or slightly cheaper, but the up-front investment has already been made. Writing software from scratch is completely different. No matter how good your design or algorithm is, reproducing a complex piece of code does not scale the way a mechanical component does.

[EDIT]
I want to clarify my position. I think this is a bad rule and it does not serve the program. However, it is a rule, and cannot be ignored. When you choose to participate in ANY activity you agree to follow the rules, whether you like them or not. This is especially important when the rules are not enforceable.
[/EDIT]

[Steve W]

Originally Posted by seanwitte

Writing software from scratch is completely different. No matter how good your design or algorithm is, reproducing a complex piece of code does not scale the way a mechanical component does.

I agree that writing from scratch is different but that is not what has been said I don't believe. People are saying that they think it a waste of time to re-type which is legal so why not just cut and paste? I believe that it just that people don't want to do what is in the rules because in is an inconvenience. I too would like to make my job easier by reusing parts from last years robot. After all they would have to be modified to fit on the new robot and adjusted for the new game. Why do we want to rebuild an already good unit?

[Dan Zollman]

Originally Posted by ewankoff

The re-implementing of the code forces students to figure out how to make that specific code work with this years robot.

I am not a programmer and I am not responding directly to the rule itself. I want to suggest a different way to think about this, but I hope I'm not off the mark with this opinion.

Some, if not all, teams document their code development like any other engineering project, including everything from the problem statement to reasons for choosing certain solutions to a description of the final product. If you're documenting a program, you would explain why each detail of the code was written the way it was, and why it solves the problems of this year's game and this year's robot. You haven't done a good job with your documentation if you say, "This code has worked before..." or "This code worked on last year's robot/another robot...so we decided to use that code for this year's robot."

Even if you would use your code from a previous year, or if you would use someone else's code, it is much better--and common practice--to explain the details of that code, show why each one is appropriate for your needs and goals, and show why you chose this code instead of writing your own. (Also acknowledge it when your code isn't original, even if you think that would affect a score.)

Would anyone have any objections to copied and pasted code if the team members can thoroughly explain why the code has been written in the way that's right for this year's robot?

[RyanN]

I see this rule as you cannot use the exact code from last year. Let's say that in 2005, your team had the perfect, most efficient camera routine ever made in the history of man, then in 2006, would you use it? If it was my team, I would use it. Why would I settle for less than what we already have?

[Steve W]

Originally Posted by CircularLogic

My answer to the last question of "is it acceptable to dodge a rule you simply dont like" is yes. I do believe that too many people are into the cult of FIRST rather than the actual issue of the things they are supposed to teach, i.e. technical expertise, programming expertise, or actual robotics. Following this type of rule to the letter represents being too caught up with the organization of FIRST and not necessarily what it teaches.

Rule violations will always happen, unitentional and intentional. Things break, changes in the pit almost always leave with some type of violations, and some teams have to knowingly use a diffent gauge wire when they only have 3 minutes to fix it, but that not the point. The point of this program is not to pay incredible attention and respect the infallibility of FIRST, but to learn from it. When people are too caught up in the cult of FIRST, I feel that we miss the important parts of the program as in the actual robotics part of it.

p.s. I always copy and paste lines of code. Its quite annoying to have to write entire drive algorithms over again when you have the same drive train.

FIRST is not just about robotics. I believe that it has a higher standard. Gracious Professionalism is just part of it. There have been many threads about following rules. I will state again here that a rule is a rule. It is meant to be followed. It is there for a reason. It can be changed if the powers that be deem that you have a valid point. It is wrong to intentionally break a rule. It is a violation even if it is not intentional. If you break rules then you must live with the consequences.

It is also your responsibility to pay attention to all of the details. If you don't in the real world then you won't last long. As for people being caught up in the "cult" of FIRST, that is not a bad thing. Being caught up on ones self and putting them self above all others is.

I am glad to see that you admit breaking the rules. This will make it easier for the inspectors to find those who intentionally break the rules.

Is it a good rule? Probably not but it is still a rule. It holds the same intent and validity as only 4 CIM motors.

[Jack Jones]

Originally Posted by Steve W

I am glad to see that you admit breaking the rules. This will make it easier for the inspectors to find those who intentionally break the rules.

Note to 2007 inspectors: Be on the lookout for Poof Ball shooting robots!

Seriously, we need to follow the rules – even this one – in order to show respect and fair play toward the competition. If we succeeded in breaking a rule and later succeed in wining a match or three, then what have we won? None of us should want to cheat our way to hollow victory. It is way better, win or loose, to have played fair.

Acting up about this rule isn’t like the Founding Fathers tossing tea into Boston Harbor, or Rosa Parks sitting where she pleased. This is not about tyranny or oppression; it’s about honesty and fair play. Feel free to speak up against it, but respect us all enough to follow it.

[Pavan Dave]

Originally Posted by Steve W

FIRST is not just about robotics. I believe that it has a higher standard. Gracious Professionalism is just part of it. There have been many threads about following rules. I will state again here that a rule is a rule. It is meant to be followed. It is there for a reason. It can be changed if the powers that be deem that you have a valid point. It is wrong to intentionally break a rule. It is a violation even if it is not intentional. If you break rules then you must live with the consequences.

It is also your responsibility to pay attention to all of the details. If you don't in the real world then you won't last long. As for people being caught up in the "cult" of FIRST, that is not a bad thing. Being caught up on ones self and putting them self above all others is.

I am glad to see that you admit breaking the rules. This will make it easier for the inspectors to find those who intentionally break the rules.

Is it a good rule? Probably not but it is still a rule. It holds the same intent and validity as only 4 CIM motors.

One of my I was gonna post. FIRST stands for a little more than you are giving credit for and help spread Gracious professionalism along with other skills you need to suceed in the real world.

Although some rules seem pointless they are rules none the less and you MUST follow them. But than again programming is often very simlar. What are you going to do? But I believe that the point of this rule is so that the rookies learn how the program itself works and get to work on it and learn something about programming rather than just cut and paste.


Pavan.
118 - Controls

[seanwitte]

Originally Posted by Pavan

One of my I was gonna post. FIRST stands for a little more than you are giving credit for and help spread Gracious professionalism along with other skills you need to suceed in the real world.

Although some rules seem pointless they are rules none the less and you MUST follow them. But than again programming is often very simlar. What are you going to do? But I believe that the point of this rule is so that the rookies learn how the program itself works and get to work on it and learn something about programming rather than just cut and paste.

It's the difference between building up a body of expertise from year to year and starting from scratch. Do you want to start next season where are are now or where you were last December? If you're rebuilding the codebase every season there will be limited opportunities for innovation because a large percentage of the time will be spent rebuilding basic components. It's like writing a GUI library every time you write a windows app. You'll get better at it, but you still have to DO it every time. That time should be spent doing something useful, but that's just my opinion.