R
B
code

Robert Tamayo's Code Blog

Who Built That?

A coworker just finished a project he had been working on for weeks. The product manager sent out an email congratulating him, and then gave a demo of the new product. As he was demonstrating it, I thought to myself, does he think it was he who built this, and not the developer? And would that actually be true?

If it's true that the manager is the creator and the coworker is not, then it means that every time I built something at work, I was actually not responsible for it. It means that although I think I "built" something, I didn't. And that's depressing.

Even though I don't like it, I propose that it is in fact the manager, and not the developer, who is responsible for building it, and I'll explain why.

What is the Application?


I remember all of my coworker's struggles with building and coding the new product over the past two months. He did work very hard on it, and came up with many innovative solutions and workarounds to solve edge cases and unforeseen problems in the original specification. 

Yet, it was the manager who designed the product. The manager created the initial mocks that decided how it would look. The manager decided what the application would do. The application came from his mind. The application is not the code that runs it, but the idea itself come to life.

The manager decided he wanted an application that accomplished some task. Then he defined how it would look and how it would work. A month later, it was in front of him, doing exactly as it was designed.

The manager is responsible for the creation of the idea, and the worker only for the implementation of that idea.

The implementation could be done by anyone, and in different ways. An easy analogy would be music. Different bands can play the same song. The same song can even be arranged in a different way. But the songwriter, who may never have played a chord or touched a key, is the creator nonetheless.

The implementation of the idea doesn't matter when it comes to who is responsible for creating the final work. 

Ideas are Separate from their Inspiration and Implementation


Some people say that Steve Jobs didn't invent the iPhone. They will usually argue that he didn't invent the iPhone because the iPhone is actually just a collection of various technologies that already existed at the time. Another argument would be that he didn't invent it because he didn't build it; it was the engineers and designers who technically put it all together.

The problem with the above arguments is that they don't separate the idea from either its inspiration or its implementation. 

The idea is the iPhone, a device that makes calls, plays music, connects to the Internet, has a touchscreen, and has applications that can be downloaded to easily expand it's abilities. The inspiration may have come from existing technologies. The implementation may have involved existing technologies. But the idea was something new; it was very clearly not the existing technologies.

It doesn't sound right to argue that Thomas Edison didn't invent the lightbulb simply because he didn't invent glass, or vacuums, or burning.

What does this mean to the developer who worked so hard coding a new application, only to realize that they aren't actually credited with its invention?

The Male and Female Aspects of Creation


Ideas are separate from their implementation. But, to make a idea exist, it involves work. The formula is that an idea plus work makes something exist. The creation of something new involves two separate parts.

It still feels difficult to say that the implementation has absolutely nothing to do with it, however, partly because building the thing is at least just as important as coming up with the idea for the thing in the first place, at least in order to bring it to life.

That's why I propose that bringing an idea to life is like procreation; it involves two parts: male and female, or idea and implementation.

Bringing the iPhone to life involved two parts: the idea and the implementation. Likewise, a song must be played to be heard and experienced, and the lightbulb needed to be assembled.

Understanding this, at least developers can take solace in knowing that they are at least part of what brings the application to life. Without them, there is no application.
 
Comments:
Leave a Comment
Submit