Yesterday we participated in the Delft Design & Engineering Award event. We were among the 20 semi-finalists with our WebDSL project. This award is a university-wide event of our university. A notable few co-semi-finalists were:
- The adaptive robot hand, a robot hand that can pick up any smallish object without breaking it, especially useful for picking up fruits en vegetables
- Delfi-n3xt, a mini satellite that they are going to launch a couple hundred of next year
- Bio-concrete, self-healing concrete (for streets and stuff)
- VertiGO, an electronic motorcycle that’s fast and good-looking
- DelFly Micro, a tiny electronic “insect”-like device, that can fly into dangerous areas and deliver streaming video
- DAISY, a technique to more effectively solve strabismus (cross-eyedness) in children
See what I did there? I explained in one sentence what these projects were in language that your mother would understand. Everybody will immediately see the opportunity and social impact of these inventions. Cure poor cross-eyed children, streets that frickin’ repair themselves, satellites, world peace!
Oh yeah, another project:
- WebDSL, a domain-specific language to reduce the amount of code you have to write for web applications, thereby reducing costs dramatically
Sure. That’s ok. But does it cure babies? Can you send it to space? Does it solve the climate problem?
Nah. It’s computer stuff, it’s supposed to be used by nerds that build web applications.
No, we didn’t win the award.
A week ago we were at my parents’, a friend of theirs that I hadn’t seen for a few years was there to visit.
“So Zef, I hear you’re doing a Ph.D., what is it about?”
Now, in situations like this I no longer panic. Early on I came up with an analogy that seems to work:
You know how before before constructing a building, an architect makes an architecture of the building, right? So he draws pictures of what the building should look like and how it is structured. When this is done, the construction company takes those drawings and builders build the actual building.
Building software is much the same: people first draw pictures of how the software should work and then programmers actually implement this architecture. This programming takes up a lot of time and money, similar to the construction of buildings. So what we try to do is skip the programming/construction parts and let the computer do that for us. So we take the pictures that lay out what the software should do and generate all the programming code to make it work. It’s like letting a big machine automatically build the building for you, without human intervention.
People typically appreciate this explanation, as generic and oversimplified as it is.
“So you actually draw pictures of software?”
“Well, we represent those pictures as text in practice, that’s what many software programmers prefer.”
And confused faces return.
People do not understand software, or the effort it takes to produce it.
It doesn’t speak to people, it’s too abstract. It’s not something they have been confronted with or are likely to be confronted with in the future. Unless your research focusses on preventing their Windows to crash or killing computer viruses. And even if it doesn’t, they’ll conclude: “Right… so you know about computers, right? Because I have this problem with Word…”
A project like ours is never going to win a design & engineering award because it’s too abstract, people simply do not care.
