![]() |
Re: Ethics 101: To re-use or not to re-use?
The intent of the rule is obviously to try to put software on the same sort of footing as hardware. This is not an easy thing to do well, for a number of reasons, but prohibiting reuse of code developed before kickoff is pretty close to prohibiting reuse of mechanisms assembled before kickoff.
Copy and paste of last year's code is too close to pulling a spare assembly from last year off the shelf. Retyping the code, line for line, is very much like fabricating an exact duplicate of a mechanism from last year's plans. The code design can certainly be reused without breaking the rules, and I think running the actual code through a student's eyes and fingers on the way to being compiled is a very good way to expose him or her to the design of the software. I haven't given it a great deal of thought yet, but there could well be a legitimate way to reuse the exact .c and .h files from a previous year's software project. If you make it readily available to everyone, you could probably make a good case for treating it as an "off the shelf component". That's approximately what happens with the code so helpfully provided by Kevin Watson. But unless you're also willing to support such code, I wouldn't suggest making yourself a test case. |
Re: Ethics 101: To re-use or not to re-use?
Quote:
The rule is what it is, but I'd prefer to talk about WHY is it that way, and does it make sense? If we're not allowed to re-use prior year's code, then where does code from Kevin Watson and others fall? If we're trying to equate the code to a physical, mechanical part then shouldn't we require teams to purchase the code from Kevin (and require him to be an approved vendor, and require teams to re-purchase it each year)? Or, if it's given away free, then the "fair market value" of it should be charged against a team's budget. (You have any idea what his code is really worth and how fast THAT would chew through your $3500 limit?) I wish people would stop trying to draw parallels between robot code and mechanical parts, and instead focus on making a different set of rules which really make sense for software. Requiring teams to re-type is stupid and represents tons of wasted busy-work - I contend that no one learns anything from blindly re-typing code. Re-building a mechanical design allows the builder to learn how to operate the machines, etc. necessary to build that part. However, the other extreme (re-use no code, no re-typing allowed) doesn't make sense either, because then you're throwing away valuable design work that is invariably tied to the code. What interest would it serve by requiring teams to completely start over on the software each year? Don't give me any excuse about being fair to new teams (who wouldn't have software from last year to re-use) because they also don't have the library of mechanical designs that other teams have either, and no one is talking about taking that away. I guess my opinion on this matter is that the change to the game each year necessitates enough code change on its own. It's highly unlikely that a team could completely re-use code from a previous competition season without at least some modification, and if they can re-use it entirely then they're likely pretty close to the default code anyway. I think the nature of the game changes each year already ensures enough changes are made to the code that there is no good reason to attempt to "legislate" that more be made. |
Re: Ethics 101: To re-use or not to re-use?
Paul,
You started the thread with a reference to rule #71, the terms of which are clear and with which you find fault. What is generally accepted is that year to year, software must be treated as if it were a part for the robot. The statement "Just as designs for hardware COMPONENTS may be reused from one year to the next, software algorithms and designs may be reused" indicates teams will "reuse" software. But just as all parts for this season's robot must be built during the build period, so shall software. It is not to put you or I on the same playing field but to put both of us on the same field as a rookie who has no code from last year from which to copy. I don't think FIRST is a sad organization because of the rule book. The rule book is the means to the end of building a robot for competition. This is much more than a competition, we are building (or trying to build) the next generation of scientists, engineers and other professionals to make this world better. 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. I know it is hard for a young person to imagine but many of those people are now well into their seventies and eighties and beyond their ability to work for themselves. They worked diligently when they could and sacrificed in order to not be a burden on anyone when they retired. Those people have watched as 40 years of their hard sork and sacrifice were flushed down the toilet by a couple of guys in Texas who didn't follow the rules. |
Re: Ethics 101: To re-use or not to re-use?
Quote:
Consider this: right now (as I understand the rules), we are allowed to re-run a CAD design on a CNC mill to produces an EXACT DUPLICATE of a part from a previous year. The best software design document in the world will not allow you to write a brand new program that produces an EXACT DUPLICATE of the binary output of the compiler. Apples and oranges, apples and oranges. |
Re: Ethics 101: To re-use or not to re-use?
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?
I draw the line between design and "fabrication" a little higher. The way I see it, the design is in the structure and the algorithms, rather than in the specific way those algorithms are embodied in actual lines of code. I think it's the .h and .c files that correspond to the frame members and sprockets. Sure, there is usually a particularly obvious way to write a function to implement an algorithm, especially when the structure of the program is well-defined in advance, but that just means the next embodiment of the design will come out looking the same as the previous one most of the time. The software rule from last year means you're not allowed to pull a module out of the version control system and drop it into this year's project unchanged; you're required to re-implement it. That's a perfectly reasonable rule in my worldview. It means someone has to actively do some programming in order for that functionality to be available. If you want to consider that wasted effort, fine, but I think it's the same sort of effort required to assemble a KOP gearbox when you already have four assembled ones sitting on a shelf from the previous year. I write software for a living, and I definitely consider software to be a part of the robot. Is your position otherwise? |
Re: Ethics 101: To re-use or not to re-use?
I write software for a living and I agree with Dave Flowerday. Having kids retype C source from season to season is not an effective use of their time. Software is fundamentally different from hardware and it should be treated as such. It should be an established team's right to leverage their accumulated experience by reusing designs from previous seasons. Since the effective manufacturing "cost" of software is zero, treat is as such and allow reuse.
|
Re: Ethics 101: To re-use or not to re-use?
It really doesnt make alot of sense for someone to have to re-create the wheel on there code. If you spend hours coding a way to interface some sensors why should you have to throw it all out the window and redo it all. Its a complete waste of time.
|
Re: Ethics 101: To re-use or not to re-use?
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?
|
Re: Ethics 101: To re-use or not to re-use?
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: Quote:
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 |
Re: Ethics 101: To re-use or not to re-use?
Quote:
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. |
Re: Ethics 101: To re-use or not to re-use?
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? |
Re: Ethics 101: To re-use or not to re-use?
Quote:
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 |
Re: Ethics 101: To re-use or not to re-use?
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.
|
Re: Ethics 101: To re-use or not to re-use?
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. |
Re: Ethics 101: To re-use or not to re-use?
Quote:
If it's an inconvenience to follow a FIRST rule, and a mentor tells the team to ignore the rule merely because it's inconvenient, then logically what will prevent that mentor or those students from deciding it's an inconvenience to follow school rules against cheating, local laws against speeding, or state laws against shoplifting? And that therefore, it's OK to ignore those rules? For example, some people think it's inconvenient to not have enough money, so they decide it's OK to enter someone else's house or car and take whatever they find. And they often don't think there's anything wrong with doing so, unless they get caught! The values mentors and teachers convey to students are critical. If adult leaders give teenagers ANY justification for breaking rules, even stupid rules, many teens will take that little "permission" and run away with it. Then, when they get into trouble, they'll blame the adults who said it's OK to break the rules. If they can break one rule, why not break the other rules? Back to the rule under discussion-- Did anyone ask for clarification of this rule in the Q&A? |
| All times are GMT -5. The time now is 13:49. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi