Engineering a System

Doesn't make a difference if it doesn't work

It was about a year ago, I was working on this  engineering class project. Everything was finalized, we had the product and all we needed to do was to demonstrate it on the final presentation. I was silently confident that we would be able to see this one out as we had put quite an effort to build this one up. On the final day, as we were about to show the work (it had to be interfaced with the computer), our laptop's charger decided to take a day off and we ended up only showing a lifeless, motionless hardware. Prof Lee, who's now the dean of engineering, looked at us with a sly smile and embarked on saying something that has stayed with me ever since:

"No matter how hard you try, how much time you have spent developing that, if you cannot make it work, its pointless."

Those words felt like someone just took an aim at my balls with a paintball gun and blasted several rounds of severely dark, depressing bullets. I did escape with a very nice, glossy grade from that class, but the reality was that our project, or rather my project, was a failure; not a total one but a failure nonetheless.

What I realized though, was that lessons like these are very hard to learn. Extremely hard. You see, an impressive amount of projects that engineers do take on result in world class failures. Even if they do manage to pull it off, most of them don't seem to have a clue how they managed to make it work in the first place. It is painful to realize how many sleepless nights an engineer had to go through to put a car on a street. Its a good, fully functional, successful and well documented (in their company) product. Imagine the iterative failures that person and his team had to endure to make it happen. 

It's Paintball in Hulk scale we are talking here.

Having recently gone to a conference and done a poster presentation on the CanSat mission we had for the annual CanSat competition, I got to talk to students from KAIST who had participated in the same competition and had managed to clinch the spot right above us. What I saw was simplicity in the way they approached their project. While we were packing components after components into our design and making it as complex as we possibly could, the other team was more focused on taking a simpler approach and making it work. Given the fact that we only managed to make the system work ten minutes before the launch of our satellite, you can see which fared better. We were just very relieved that cutting down on some components actually payed off eventually. 

So here's what I can really state with some measure of confidence; the process of making a system depends on making a system alive with as less components as possible and then deciding on building on that and not the other way round of component acquisition first and putting them all together to make a giant mess. 

Ironically, that's the trouble I am having with my current work.