Who are we?

Redwines Garage is a tinker shop involved in a wide range of specialized apps, embedded software, and electronics projects. We create custom solutions for problems requiring an amalgam of engineering and art know-how, software design, and hardware construction.

We are a very small number of software engineers who also speak the languages of electronics, motion picture production, and graphic design, plus we can call upon friends with expertise in hardware, medicine, music, construction, horsemanship, and fine arts.

We have deep roots — technological and otherwise — in the Santa Clara Valley.

Our Mission

Our current interests revolve around Apple watchOS (and small iOS) apps. The art of graphic design and engineering for the Watch, with its screen size and other unique limitations, appeals to us. Constraints foster creativity — remember the Apple II and Atari 2600?

We tend to get roped into creating custom solutions that require engineering with small to moderate amounts (by corporate standards) of software and often some simple hardware, usually involving a microcontroller directly (vs. Arduino, etc.).

We like to apply quite a bit of perfectionism and loving care to these endeavors. The kinds of things we like to do most are interesting aftermarket plug-and-play devices that interface with existing infrastructure, especially in rough-and-tumble environments such as marine and automotive.

And strangely enough, this all has included a fair amount of (past) filmmaking and (current) winemaking.

Read on for some examples (not a complete list) of our past and present projects:

Some Projects

  • “Smart” fuel pump relay replacement for Dodge Viper automobile
  • Communication software and hardware for SCUBA diving
  • Documentary and Arcadia Publishing Images of America history of Sunnyvale, California
  • True optical-only, arbitrarily-sealable keypad
  • Winemaking
  • See some of our stuff on Instructables.com .
  • See some of our way-old stuff on YouTube here and here and here

For more information, see www.benkoning.com .

And now for a quick (?), obviously-autobiographical rant . . .

Our Approach

First, we believe that small applications and widgets and gadgets of all types should be “yummy”. That is, they should be a delight to look at and operate. They should be simple and beautiful on the outside, yet deceptively complex under the hood. Whatever your opinion of Steve Jobs, you must admit that he was the greatest of all time (GOAT) at this. He said that one of the most important things to know is when not to do a product or feature, if the time is not yet right to do it well … where “well” means “better than anyone else”.

Unlike most programming teams we have met, we take documentation very seriously. Our source code is heavily fortified with comments which strive for an extremely high bar in explaining how and why things work and interact. In many cases, the comments alone would be enough to recreate the program code. The same applies to our hardware documentation. For samples, please see the Instructables.com projects linked above.

Another strong view of ours is that solutions must be responsive. Human interface response time latency — anywhere — should never be more than 250 milliseconds when first called to attention, and no more than 50 milliseconds per keypress thereafter, and in many applications, much less. If operations require more time, progress indicators should be displayed; however, depending on the criticality or public-facing-ness of the application, even those might not be acceptable mitigations, and thus demand higher-level rethinking.

But perhaps the item about which we are most passionate is software engineering. Not merely “coding” or “programming”, but engineering, in the traditional sense of choosing the most appropriate technique for the job.

Sometimes that means very high level coding using polymorphism and multiple inheritance and “program stack”-based recursion, or a cleverly-designed class hierarchy. We like symbolically beautiful-looking solutions and nerding out as much as anyone. But other times that means lookup tables to perform collapsed arithmetic, avoidance of recursion (in the way it is commonly presented in teaching materials), concreteness vs. polymorphism, a solid knowledge of discrete math and scaling, and more.

A solution which, at sophomoric first glance, appears inelegant — perhaps even containing logical redundancies, cross-checking of redundant information sources, apparently unwarranted explicitness, careful attention to preflight and order of tasks, obsessively-complete logging, static memory/resource and execution/threading/scheduling strategies both at build-time and runtime, positive-fault-detectability-proving, rigorous back-out strategies, and more — is often what it takes to deliver the quality and robustness that customers, and indeed the public at large, have a right to expect.

Yes, there are real-time operating systems that have support for such things as hard deadlines. We are not referring to such systems per se. Instead, what we are stressing is that run-of-the-mill, noncritical applications should be held to higher standards.

Nor are we are necessarily talking about perilous applications. Thankfully, critical life-safety and high-loss deployments in fields such as medical, transportation, aerospace, and finance are nowadays given the cautious approaches described above, but, again, we believe that the public should begin calling for higher levels of software quality in all areas.

So far the discussion has only been about code creation. Turning to the concept of testing, we believe that, whether “white box” (IPI, Unit, CI), “black box” (SPI, API), “user-level”, automated or manual, any project that is not “smallest” or where the team is not “a single person” needs (1) at least some elements from all of the above, and (2) a culture where “developers” and “testers” are equally respected and even trade places, in a socially friendly but technically adversarial style.

We hold that part of the problem is undue emphasis in university curricula on dogmatic mathematical aesthetics at the expense of teaching equally mathematical and rigorous real-world engineering judgement.

Regarding privacy and security, we will only say here that software which accepts input of any kind (GUI, files, network, etc) must fully validate all input. There must be no possible input which causes undefined or exceptional or adverse behavior. We worry about mass deployment of OS-in-a-box solutions for embedded systems, such as booting a Linux kernel to control a dam.

Now about schedules. There is no truer maxim than “Quick, Slick, or Cheap — pick any two”. If you don’t believe this, we ask you: What makes you think, in some 100+ (if you start with the looms) years of software engineering, that you will be the first one in history to beat the mythical man-month? You will not be, so stop kidding yourself. Either drop features or extend the schedule, and if you’re inside of a year, you cannot hire your way out of this.

Some things we don’t like:

  • Fads of the semi-decade: Yes, keep the good, make progress, but be skeptical
  • Software architecture decisions motivated by company politics: don’t laugh, it happens
  • The cult of the “star engineer” who “cranks out the code”
  • Excessive research how to use another part of a project, simply due to lack of comments
  • Academia’s throttled competitive access to higher education and research papers
  • Lackluster preparation for the actual kinds of work new grads find themselves doing at firms
  • Intellectually lazy interviewers’ empty-headed coding interviews
  • “Hustle culture”: Stop bragging about how great it is that you don’t require sleep
  • “Developers” who disrespect “testers” [and no, I was not in SQA/testing]
  • “Crunch time”: Looks like you are mismanaging your project
  • “Disruption”: It’s great that you democratized a technology, but it’s not great that your tools don’t operate like they know much about the industry in which they will be used

Instead, we value a more professional, civil-engineering-disciplined, trade unionized approach.

We are sure that you would hesitate to cross a bridge, ride a rollercoaster, receive surgery, or ride in an autonomous (aerial!) vehicle if “coders” working “long hours” for management with a “move fast and break things” philosophy were in charge.