ORF Coming Up

by Luke 23. October 2009 09:39

October Rules Fest 2009 is rapidly approaching and I'm putting the final touches on the papers and slides for my two talks. I will be giving presentations on "Graph Based Knowledge Bases and Rules" and "Designing a System of Rule Based Agents".

These papers cover some of our secret sauce that I mentioned in the last post. These technical innovations in rule-engine design/use have been key to our automation systems. These tools have given us the performance and scalability improvements we needed to make our software for automating boring engineering viable.

I believe many young technology companies are too secretive about their competitive advantage. Unless you've signed an NDA, the most you'll learn about their process or technology is that "the magic happens" and then you get the result. The software equivalent is "security through obscurity" which any security expert will tell you is little better than no security at all - in fact it often provides the illusion of security thus leading to overconfidence. So why is the analogy important?

We think hiding our secret sauce would work against us. We are working on hard problems with real technological innovations. The sharing of ideas and feedback will make our work better and help us build the tools we need to automate engineering. Our competitive advantage isn't in our secrets, it's in our execution. We're doing something hard. We're doing it well. And we challenge anyone to do it better.

Secret Sauce

by Luke 19. October 2009 06:36

Sometimes when I describe this company to someone for the first time, they ask me for the secret ingredient that makes our work possible. I get the impression that they are expecting one big breakthrough that I can point to, but I don't think that's the way most innovation works. So I have to disappoint them a little with my answer.

Instead of a single big secret ingredient, I think of it as several small innovations mixed together into a secret sauce. The recipe for us needed just four main ingredients: 1) better knowledge representation tools, 2) better knowledge capture methods, 3) modern expert systems, and 4) modern computing power. The first two ingredients are about managing complexity and the second two ingredients give us the performance we need.

Engineering problems have a key property that helps us manage complexity: many kinds of engineering decisions are not ambiguous. They can often be represented mathematically and that makes the job of teaching the computer to handle it much easier. But even simple engineering tasks can consist of dozens or hundreds of decisions that link together to make a solution and finish the work. The network of decisions on information creates complexity and that has always been one of the most difficult challenge for systems such as ours. We've created tools to manage the information complexity for our engineering domains and we've learned how to help human engineers teach computers what they know.

As for performance, much of that depends on how well we manage complexity and find ways to break large problems into smaller ones. Being able to run modern expert systems in parallel and over a network gives us the raw computing power we need to tackle many small problems at once. With good computation performance and a handle on complexity, we have the main tools we need to build automated engineering systems.


by Luke 12. October 2009 06:29

An "Aha!" moment is simply the last in a long series of steps that prepare you for when inspiration strikes. I want to share my "Aha!" moment with you - the one that led me down the automating engineering path that we're on today. Here is the spark:

Make software that performs work.

I was doing some research on expert systems and listening to a talk given by Larry Smith, an Economics Professor at the University of Waterloo, when I heard that message. To paraphrase his take on software opportunities, "We don't need more software to let us talk to each other. Make software that performs work." And I was struck by how true, yet unappreciated, that sentiment is.

The story of the internet billionaire warped the expectations of software developers everywhere. Google, Facebook, and now Twitter are all about communication and those are the imagination-grabbing examples that ambitious developers want to emulate. The job market for a software developer looks like a choice between the "glamorous" examples above and all of the "boring" line-of-business work going on within companies all over the world.

I agree that we have more than enough people working on communication tools. We've also spent the last two decades on the "boring" work of automating business processes (e.g., order processing, payroll, inventory management). But the third choice, the often overlooked choice, is to automate any of the other work that people do.

We can do amazing things by making computers perform engineering work. That was the realization I had when that final message clicked into place. That was my "Aha!" moment.

Automating Boring Engineering

by Luke 8. October 2009 11:35

While the long-term goal is to automate engineering more generally, we need a starting point for our work. Having looked at many different paths to that goal, the one that is most promising is the one that gives us something to work with today. The start to that path focuses on automating boring engineering.

What do I mean by boring engineering? Usually that means some task than an experienced engineer would find tedious. Maybe it's finding and plugging numbers into a well-known equation. Maybe it's repeating the same task over and over until the answer is reached. In short, any task that is much more tedious than creative is a candidate. That's what "boring" means in our work. And that's the place we're starting at.

This is the type of work you might normally assign to someone right out of college. Junior engineers often get tasks that are time consuming (but necessary) and can be easily verified by an experienced engineer - usually with just a few sanity checks. It's usually work that needs to be done but that isn't an efficient use of a high-paid engineer's time. In fact, it's often not even worth a junior engineer's time, but that's who the job has always fallen on because there is no one else to do the work. We are changing that.

We want engineers at all levels to be able to do better work by focusing on the important tasks - not the ones that are just a step above rote memorization.

What is Automated Engineering?

by Luke 5. October 2009 09:28

It is amazing how often science fiction inspires real life. In a way, science fiction is science's imagination - dreaming up possibilities for scientists and engineers to explore.

I never read the Iron Man comic books, but I did love the first movie. I remember the scenes where Tony Stark was working in his home lab/fab designing, building, and testing the components of what would become his Iron Man suit and thinking to myself, "Gee, I would kill for his home computer!" His fictional robotic suit of armor has to easily be as complicated as an airplane and here we've got one guy in his (admittedly high-tech) garage designing the whole system. There's no way one person would be able to do all of the analysis by hand and keep everything organized, so you have to imagine that almost all of that is being handled in software.

No one on Star Trek writes device drivers. When Scotty reroutes system controls, you don't see him sitting down to rewrite the hardware drivers. When Geordi needs to launch a custom-built probe to examine an unknown alien device, he doesn't have to worry about making sure all the components work together. His computer handles all of those little details.

And that's our inspiration. For any of those details that the computer can take care of, it should be the one doing the work. The important insight is that in order to automate engineering, our software cannot focus on just the data.

Engineering expertise is about turning data into information and then being able to make judgments and decisions. It's one thing to have software that can determine if a component will break under a 400g impact. It's quite a more useful thing to have the software determine if the component can survive a fall from a table. Software that does the first can only answer one question about data. Software that does that latter answers the real question. More importantly, systems that answer the "smarter" questions can be joined together to provide much more complex judgments and can ultimately be used to suggest possible designs based on those conclusions.

Raw data is not much use unless you have context. We're giving computers the context so they can make smarter choices and help you do real work by producing not only data, but real engineering design options as well.

Welcome to Mindviews Labs

by Luke 3. October 2009 12:47

Hello, my name is Luke Voss and I founded Mindviews Labs.

I'd like to introduce myself and let you know a few things about me. First off, I'm a pretty big nerd. I grew up on a steady diet of Star Trek: The Next Generation and popular science books to feed my imagination. I was fortunate that my parents and teachers made opportunities for me to explore my math and science interests above and beyond the usual school offerings. I eventually earned my undergraduate degree in Physics and worked at the NASA Jet Propulsion Lab (JPL) for five years.

I am also a member of a small generation that grew up at the same time that the personal computer did. In grade school, one of my playmates was an Apple //e that lived at my neighbor's house, and I went to school with a several Commodore 64's. My parents adopted a pair of Packard Bell computers for me and my sister a few years later and in high school our library had networked computers connected to the internet. As much as I learned from using computers growing up, I was also learning to program and liked to think that I was "teaching" computers something new.

I had a very exciting combination of experiences near the end of my time at JPL. Looking at the space mission design process, the software tools, the work of specialists, and the direction of custom engineering software written in-house, I saw a huge opportunity to make computers help do the work that people have to do by hand today. After two years of experimenting, developing a series of prototypes, and teaching the computers some new tricks, the technology is now paying off and can do some remarkable work. That's why I started this company.

While I expect to be the primary contributor to the Mindviews Labs blog, I won't be the focus. This space is to explain why this company is important and how I hope it can change the world. The tagline for Mindviews Labs is "Automating Engineering" and that sums up the long-term goal of the company. We are inventing the tools that we think will be commonplace in 20 years - an environment where software can do many of the same tasks that a trained engineer is needed for today.

Our challenge has been to find a roadmap to our long-term goal that lets us begin to use that technology today and we think we have one. So we founded the first of many Labs within the company to "Automate Boring Engineering". We are also kicking off a couple of other Labs for data visualization and information analysis. Each lab group we form must meet two basic criteria: 1) it must work toward the long-term goal of automating engineering and 2) it must create products and tools that we can use today.

Mindviews Labs Blog

Sharing about the future of automated engineering.