• Welcome to Redshift Project Depot.

Reflections on the season

Started by Louis L, April 06, 2018, 11:56:33 AM

Previous topic - Next topic

Louis L

The season isn't over yet (we still have BattleCry) but I want to write some thoughts down while I still remember them! These are not in any order.

  • Let's not forget the KISS principle. Keeping things simple doesn't mean it can't work well. Simplicity should not be confused with lacking in functionality; things can be simple and effective. Simplicity also does not mean that we're not aiming high. Aiming high is about achievement, not implementation or complexity. A simple design that achieves a lot is aiming high. A complex design that achieves little is just a poor design.
  • We can learn a lot from failure. How we bounce back and recover is also a good lesson. Looking back I like the idea of making a major change post-first-event more and more. Rather than wait until the following year to say "here's what we learned last year" we shorten the cycle and say "here's what we learned at the last Event". And a more immediate turn-around means a more quicker feedback. Of course, this is only good if the team is willing to absorb the results and learn from it.
  • Also important is to make sure that whatever went wrong in the first design is not carried over in the remake. We don't want to double-down and repeat a mistake, that would defeat the goal of learning from them! This statement may seem obvious but I can tell you that habits are hard to break, and convincing people not to repeat what they feel is "right" is even harder.
  • It's not personal. Whether a design works as intended or not is just that. If it fails to deliver, so be it. Lots of designs have been tossed by the wayside in the annals of history. It's not personal.
  • We all have bad days. No big deal. Everyone has them. The key is not to make them over and over again. That's the difference between between having a bad day (and realizing it) and always having bad days (because things are never changed for the better).
  • We need to finish in 5 weeks. So let's PLAN for 4 weeks. We know there will be issues which will stretch it to 5 weeks. Then we integrate, test, optimize in week 6. Our best years have been when we accomplished the 5 week schedule. We can not afford to ignore the time it takes to integrate and test. If you think of the time it took to get rid of the bugs at an Event, what if that time had been spent in the workroom instead? Naturally this has a tremendous impact on the design, the schedule, the availability of students due to midterms, etc. We need to learn to work within these parameters.
  • We're still afraid to think outside the box. Each year we talk of unique mechanisms for specific tasks and each year we bail out. When will this change? Ex: climbing this year.
  • Everything has weight. And it's not our friend. We need to design with weight in mind. Weight cutting at the last minute is what they do in boxing and MMA; it's not something we want to do with robotics!