MechHack

Building better together

311 0

Putting smart people in a room to work together on solving problems is a proven formula for building better products. Add potential customers to the mix and you might create real magic


According to an old saying, “If you think you’re the smartest person in the room, you’re in the wrong room.”

As much as I don’t want to mess with this pearl of wisdom from the great Confucius, I can’t help but notice that the Chinese philosopher doesn’t seem to offer any advice on what to do when you find yourself at the opposite end of the intellectual scale.

A big part of my job involves being in rooms with incredibly clever people – those at the top of their game, operating at the pinnacle of human ingenuity and innovation. In some cases, they’re literally rocket scientists. Some of them build wondrous physical products from nothing. Others create the tools that support the work of product designers and engineers.

Either way, it’s a far cry from my previous job, in which I used to interview sports people. Believe me, I was far less scared of provoking the fury of an 18-stone rugby player than I am of stepping into a room full of intellectuals.

As a result, it was with some trepidation that, earlier this summer, I signed up for a weekend hackathon focused on mechanical engineering software that was being promoted on LinkedIn. The event – MechHack – was organised by the team at Vanellus, a Cambridge-based start-up developing simulation tools for thermal analysis, and hosted by Halkin, a flexible workspace company based in London.

My day at MechHack

I found the initial presentations gripping, as attendees talked about their current projects and what they hoped to get from the weekend.

Advertisement
Advertisement

Many of them represented software start-ups and were looking to solve issues with their product. Others were there to find work-arounds that might help them overcome the challenges of existing software.

Everyone was friendly. These software engineers, from a range of different backgrounds and organisations, had all given up their free time to attend and work together on solving issues.

During the first coffee break, I got up the courage to shuffle around and introduce myself, by now palpably aware that I was not in the same intellectual league. I barely speak the language of coding. I’m not a programmer and I’m not sure how to discuss the topic with someone who is.

After teams were assembled and laptops were produced from bags, the groups set to work on a number of very diverse projects: an OpenFOAM language server to make editing config files less painful; VTU visualisation on the web using the Bevy game engine; and using AI and computer vision to tag CAD part assemblies for automated compliance checking.

What did I have to offer in this environment? Well, some perspective, I guess. I had ideas about what those customers using an end product might think of it, where it might fit in the wider industry, where it might be most useful, and how it might be future-proofed. It might not have been much, but at least I had contributed some food for thought.

Listening to customers

As the earlier conversation dwindled away, replaced by the tapping of keyboards, it struck me that if you’re the dumbest person in the room, then once the serious work begins, the smartest thing to do may be to say your goodbyes and make for the exit.

As I walked back to the train station, I began to think of the people who might one day use some of the software created in response to that MechHack event.

While most designers and engineers are aware of the skill and talent that goes into creating the world-class CAD packages on which their work depends, there will be few that haven’t at one time or another cursed the people and companies that created them.

Customers are often baffled as to why an issue wasn’t fixed with the latest update. They’ll spend hours on the phone berating a reseller about lack of support. They’ll curse and moan when software crashes, losing hours of their work.

All this is perfectly understandable. Software is always going to disappoint or even mess up. None of this detracts from the passion or skill of the people who created that software.

Still, there’s hope yet. The adoption of cloud software means developers can collect more real-time data about customer use of the product and use this to spot defects (and identify easy improvements) far faster.

And then there are events like MechHack, which provide great environments for moving new design and engineering software further along the maturity curve.

What I’d love to see would be more end users attending such events to share their frustrations and needs – and maybe even acting as the focus for such meetings.

After all, feedback loops of surveys and beta testing don’t seem to solve all the problems.

By bringing software developers and end users closer together, maybe we might also bring brighter ideas to light.