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.

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.

Mindviews Labs Blog

Sharing about the future of automated engineering.