M. Adam Davis wrote: > On 4/26/07, Adam Stambler wrote: > > Hi everyone, > > > What type of factors do judges look at when they are determining > > "technical merit"? > > They use technical merit for nearly every contest. Check out the > previous winners of the past contests, and check out all the entries > that are available - you'll find that some excellent entries didn't > make it due to various issues such as poor documentation, little > technical merit (ie, another MP3 player with nothing to differentiate > it from other MP3 players) etc. I have been a past judge of Circuit Cellar contests. I don't know whether I'll be involved in this one -- I'd like to, but I haven't discussed it with Steve yet. The important thing to remember is that regardless of which company is sponsoring the contest and which technologies they require in order to qualify, the contest is about good design engineering and what it takes to incorporate that technology into real products. This is what the magazine is all about, and it's what the sponsor is most interested in. Documentation is key -- a lot of engineers seem to go through life thinking that the prototype is the ultimate goal of their work, and that's completely wrong. The prototype is simply a means to the true end, which is to produce the high-quality documentation needed to produce a product. This includes things like schematic diagrams, bills of materials, mechanical drawings, assembly instructions, source code, test procedures and operating instructions. There are two other important documents that are not used in the production process. I call them the functional specification and the implementation guide. The functional specification describes the product in terms of what it does, its external interfaces (including user interface) and performance levels. When you're working in industry, this document becomes a kind of "contract" between you (the implementer) and the people describing to you what they want (marketing and/or upper management). As such, it pays to put as much relevant detail as you can into this document, so that there are no misunderstandings later. The implementation guide describes the product in terms of how it's implemented -- the technologies used, the internal interfaces (including the hardware-software interface) and higher-level (more abstract) concepts about how the product works internally. This might include things like dataflow and state machine diagrams, pseudocode for the software, etc. This document is important when you (or anyone else) have to come back and support or enhance the product later, so again, put all the details in here that don't appear in other places like the schematics and the source code. A contest write-up will not necessarliy include all of these things as separate documents, but it should touch on all of these topics in order to rank higher in the judging. Also, a contest entry is usually in the form of a proof-of-concept, using evaulation boards and other items that would not be part of a real, sellable product, so some of the topics I've outlined above will be necessarily incomplete. But you still must be able to convey a clear vision of how they would be accomplished to the judges. Technical merit is harder to describe. It's a combination of having a product that actually meets a need, and using the underlying technology in an effective way to meet that need. An extremely important part of this is having definite goals for the product AND CONFIRMING WHETHER YOU HAVE MET THOSE GOALS. I can't emphasize that enough. 99% of the contest entries that I have seen never show whether the final design ever met the performance specs and other goals that were outlined at the outset. Originality and cost-effectiveness tie in with technical merit. Originality to a point is good, because it makes a product that is more distinctive and sellable, but taken too far, you end up with something that no one would actually want to have. The bottom line is this: I don't care whether your product is a simple toy with two buttons and a beeper, or a complete robotic vehicle for the Darpa Grand Challenge -- if the documentation is good, I'll rank it high, and if it's poor, I'll rank it low. In some cases, contestants would have been well-advised to scale down their projects so that they could have done a better job on a simpler product. Also, keep in mind that a good contest write-up is also a candidate for becoming a feature article in the magazine, regardless of whether it ends up placing highly overall in the contest. There's a certain amount of money and a certain amount of fame associated with that as well. -- Dave Tweed -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist