We were starry-eyed and visualized designing a variety of hi-tech structures¹ during final year undergraduate Civil Engineering course. A couple of those shot-down by my professors were: a curved cable-stayed road-over bridge, and an air-cargo hanger.

My school committee didn’t bend rules to accommodate another head for what we thought was an ambitious project. Our group of four was just far too many to be assigned to one task. We parted ways; I formed a smaller team that produced a design solution using a reinforced catenary shell. My buddy Bharath formed another, and they went on to create a fantastic tool for designing shallow foundations.

In addition to working on theoretical solution, we also programmed stuff ourselves. On hindsight, I realize we compromised. The stuff we produced in the end lacked finesse, and left much to be desired. In the end, it remained just a solution. We could never really convert them into professional tools we’d have much loved to.

In over twelve years of my professional life, I’ve seen (and continue to see) tools with great potential end-up as poor implementations. People good at both core competencies—theory, and programming are simply few and far in-between.

I often think about my school projects, and how different they would have turned out if we had a multi-discipline team. A lot of design work involves heavy automation. If I was in school today, I’d do things differently:

We’d have a team of four: two civil engineering², and two computer science (CS) students. Each discipline would produce their own project, just married in concept, and challenging enough for both. Both works would be complementary to each other.

Civil team would work on theory, and solution. CS team would apply their innovative skills in developing something ground-breaking in programming that solution. Each team would attend others’ ground work sessions. This would help in more ways than one: We’d learn from each other’s skills, appreciate individual challenges and come-up with out-of-the box solutions. Indirectly, this would also have the potential to go the entrepreneurial way—if the teams decided to.

My time may be up to go back to school and do it again; but not yours. If you’re a student, get your buddies together to think about it. Throw ideas at your professors and see what they think about inter-discipline collaboration.

1. To us at that time c. 1992. [←]
2. This could well be your own core discipline; I am just mentioning Civil since that’s my background. [←]

Related posts

Following list is auto-generated, based on this post's context as possibly related. You may, however, occasionally find some in this list unrelated, but nevertheless, we sincerely hope that you'll enjoy them too.

• Power-up those intranets
• Wikis are really meant for intranets
• Front end engineering and design
• Group domain
• Graduation
• Sky Radio via the internet
• Sunday morning links
• Knowledge Management: How not to
• Python in school
• The pool