7 myths non-techies have about software development

Many of the businesses I deal with are non-technical and sometimes I am their first experience where they are hiring someone to build technology specifically for them, based on my dealings I have come up with the list below of a few misunderstandings on software development I have encountered from clients as well as family and friends on what developers do and what is important in creating software.

1.Programming is like it is depicted in the movies

Like most professions, I am thinking Lawyers, CSI agents, Police etc. The depiction of the jobs on TV are glamorized and over simplified and software development is no exception. Movies have a way of making software development seem action packed with lots of typing, exclaiming and hi-fiving. This usually makes non-technical people think programming is probably closer to playing candy crush than it is to writing a book. But I must say though, some of the worst scenes about computers on TV are hacking scenes. I usually try to explain that writing software is similar to writing a book, you have to plan the outline, think about how all the different aspects will work independently but flow as a whole and there is way more thinking than typing in the process.

2.The number of lines of code matter.

Bill Gates has a famous quote that goes: "Measuring programming progress by lines of code is like measuring aircraft building progress by weight". People have tried to convince me that a developer has done an outstanding work because of the thousands of lines of code they have produced. At this point I usually release a sigh, the type you hear from a father when his child asks him what is the meaning of life and the father just realizes the amount of work ahead of him. I find that analogies work best here in educating the person. Following Bill Gate's quote I would try to explain that this is like saying a book must be interesting because it is more than 2 thousand pages long. Lines of code do not speak to the amount of work or quality of the code, it is just an attribute of code. It is actually more of an indicator for a complex and hard to understand code than it is an indicator for quality.

3 Developers are computer experts

Last week over drinks a friend of mine said "... I knew he sucked at programming because he couldn't even make a decent powerpoint presentation". This is like saying the carpenter that built the chairs in your house must suck because he did not know how to use your stove. There is this inherent belief that if someone is a developer he must know EVERYTHING about computers and how they work. I think it stems from how cryptic computers are to non-tech people and so anyone who understands any part of this mystery box must understand all of it. While most developers understand a lot about computers and how they work, this usually comes from their personal interest and curiosities in computers as a whole and nothing really to do with their ability to develop software. So I always try to educate people that a developer is not a network engineer, security expert, app installer and website designer. They may know a little about everything but that is really just extra, not a requirement for developing good software.

4. Things that sound easy must be easy to code.

In my experience, non-tech people think a feature would be easy to code just because it is easy for them to wrap their head around the feature, and something is hard to code because they cannot fully picture the abstract nature of the feature in their heads. Ask a developer about how fun it is to manipulate dates in programming...it sucks. Dates are something humans understand inherently from a young age and can easily describe and manipulate in our minds but can get quite cumbersome when coding, while something like geo fencing (triggering events in a specific location) sounds like a complex task, companies like Apple and Google, have great API's in their products that handle this for you and most developers that create products that do this only need to interface with Apple and Google products for the most part, so although it sounds complicated, it can be easy to implement in an app today. So I try to explain that how complex something sounds is not an accurate indicator to how long it will take to implement.

5. It takes X amount of time to add Y feature

One of the worst questions to ask a developer is "How long will this take?". With experience and completing similar tasks multiple times, a developer can give better estimates, but they never can give you and EXACT time. Coding is not like baking, you do not set a countdown and come back X minutes later. It is more like writing an essay or a book, we know it wont take 2 weeks but it definitely will be more than 2 hours.

6. Developers jobs are boring

The more I explain the realities of coding to people, they usually start to say, that sounds boring, that does not sound like it is for me. I guess if someone tried to explain the process of writing in the time of Scribes long ago, I would probably think writing was boring too. To code you need to change your emotional thinking to that of logic, and programming languages are the ways to speak in logic, this opens up a whole new way to see the world and tools to solve problems and create things. Not to mention, the tech world has its own eco-system with its own drama that can keep you entertained once you understand that world.

7.Developers may steal my ideas if I tell them about it

Imagine the life of a developer, the day she finished her first program. The day she realized she could create almost ANYTHING she imagined. That she is now armed with the same information and power as the people that created Facebook, Instagram or flappy bird. Imagine all the thoughts that pass through her mind on a daily basis. It is like when someone asks you "What would you wish for if you have three wishes?" but this is like what will you create if you could create anything. Imagine when she lets her family and friends know she now has this power, they all tell her about this app they have been thinking about that is like a million dollar idea. Quickly the developer realizes that the makings of a hit app is not a list of hot features, the same way you cannot guarantee a New York Times best seller by someone telling you the plot lines of a book. Hits are based on the execution and excellent execution comes from passion and deep understanding of a domain. A good developer has too many ideas they want to implement, than to bother stealing yours and the ones that do go ahead and steal someone's idea are usually not that creative anyways and will crash and burn soon enough.