Why Can We Automate Boring Engineering?

by Luke 17. November 2009 10:26

So why do we think we can automate boring engineering when we haven't seen anything like this before?

We have two - make that three - reasons for the claim. First, "boring" is a key part of why we can make progress. Creative tasks are usually engaging to people and keep them interested. It is the boring parts that are tedious and un-challenging. In short, boring work doesn't require a lot of creativity. And problems that don't need creativity are usually not as hard to solve with computers.

The second reason is social. Our challenges aren't just technical. Rather, we are working to see our tools used in engineering shops everywhere. Boring tasks are a bad way to introduce junior engineers to the work environment. Today's junior engineers are often skilled at computer programming and can make short work of the tasks that used to keep such team members busy until they had a chance for promotion. Instead, we can provide an opportunity for inexperienced engineers to learn from experience faster than they could have before. By automating the tedious work, young engineers can see more alternatives and more quickly understand the trade-offs that need to be made for a design to reach production. Our tools can change the way engineers learn on the job - instead of spending time crunching numbers and observing the work of others, they can spend that time exploring designs and understanding the strengths and weaknesses of them.

And the third reason that I almost forgot to mention was that we've already been able to use this approach in our case studies. For more information, contact us for one of our whitepapers that describes real-world scenarios where we've been able to use our tools. We think you'll be impressed by what we've been able to do.

ORF Reflections

by Luke 5. November 2009 07:14

As expected, October Rules Fest was excellent. For any other companies using or thinking of using rule based systems, I strongly recommend attending this conference next year. The focus is very much on real-world work being done in several industries using this technology. In a few months the conference papers should be released publicly, so check back and I'll try to provide a link.

One of my favorite talks was by Mark Proctor on the future of rule engines. His thoughts squared with many of our thoughts on rule-engine and language design, and we will be implementing several of his suggestions in the coming months to improve our systems.

There were also many other excellent presentations, but I'd like to see even more AI style expert-systems developers at the conference next year. Much of the use today is in algorithmic trading and processing by financial firms - the place where rule-engines seem to have found a home after the AI winter. But like so many technologies from that era, rule-based expert systems have quietly spread into a wide range of applications. We'd like to meet more of these developers and learn about what you have been up to.

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.

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.