9 Beliefs Developers Hold That Are Not True

Nine commonly held yet erroneous beliefs that developers tend to have about work, employers, other departments, and more. While it is not an exhaustive list everything from interacting with others to interacting with databases, to changing specs mid project, and misunderstandings about how business works are covered.

These are the sort of critical mis-communications and non-optimal behaviors that distinguish a less experienced and less professional developer from those that have played the game a while and gotten some life experience. Being aware of these will help improve your employer’s (and fellow coworker’s) perception of you, as well as steer you away from problems that can cause you grief later.

It’s not a big deal when software fails.

Failure of software even a small feature of the software can lead to lost customers. Lost customers leads to lost sales. Financial disruptions to people that are counting on you and the software matter. These financial disruptions have lead to the failure of companies both large and small. Company failures have lead to people losing homes, going bankrupt, or even committing suicide. A fixable bug left unfixed can have long term consequences.

Knight Capital Group suffered from this and lost twice the previous years net capital in 30 minutes in 2012 due to placing untested software in production. In 2003 a hospital in Michigan sent notifications so Social Security and insurance companies of the death of over 8,000 patients that were all alive and well. Even more serious during the Gulf War a software failure in the Patriot Missile System lead to the death of 28 soldiers.

While it is not likely that you are working on a system that can cost lives if software fails the effects can still be devastating to those relying on the software to function. This doesn’t mean you should panic over bugs in software, but it does mean that you shouldn’t just let them slide either.

The database will have to be switched out from under an application.

This almost never happens. Most cases are partial switches and that is for performance.

If it does happen, it’s impossible to avoid at least some rewrite of code. In their documentation Oracle suggests setting up a staging database then switching the live application to the staging database while you are making the transition.

Use of ORMs (Object Relational Mapping) allows for abstraction of the database. However, they do not provide transparent switches of databases. Also, writing code that generically works across different databases often misses some of the best features of a particular database in favor of being generic. Performance and stability suffer from use of the lowest common denominator.

Specs can’t change while coding.

Uhhh… No!

Sounds great on paper but isn’t true. Even NASA changes specifications as new information is learned.

Where data is stored, how the UI (user interface) looks, how it communicates, and security can all change in the process of development. Developers have the idea that “we’re already coding this you can’t change the specs.” It’s painful to change and does have a cost. Discourage arbitrary changes or ones that could have been part of the planning.

Just like NASA launches a rocket into space, you are launching an app into the regulatory environment. Complex systems like Earth’s atmosphere, the government’s regulatory environment, and the financial systems change too quickly to be static.

Employers care about pedantic coding arguments.

Unless it makes a quantifiable difference to the business, it probably doesn’t matter to the business owners. That is not something that is important to them, it’s not their world. It can become a problem when it is important to them but it’s not expressed in a way to convey the importance to the business.

Important matters can be expressed in terms of technical debt. This is the concept that extra programming work (and therefore extra cost) will arise when code that is easy to implement in the short term is used instead of planning for the long term with usage of best practices.

When you are constantly arguing over minutiae, your arguments over important matters won’t be heard. This is the whole developer who cried wolf scenario. Focus on what’s important and save the rest for private conversations with other coders.

New technology is necessarily always better.

Many developers are early adopters and fast adapters. Developers should stay on top of current trends in technology. Showing knowledge of the newest tech can help boost a resume.

Resume driven development is not an accepted industry practice. New tech and frameworks are volatile. Resume driven development should be restricted to personal or side projects.

Some very old technology is running critical infrastructures. There is a reason the older technology is still in use and still supported. It has survived the hype and proved stable. Be cognizant of the actual strengths and sustainability of both new and old technology.

A snapshot of data tells you everything you need to know.

Particularly insidious when writing to a database. Many times developers will write an app that creates a record and makes multiple changes to a database and feel the app is done because it reads and writes to the database. However there is no logging.

Would you accept your bank only being able to tell you what your balance is, versus listing out the transactions that got you there?

Logging is a first order concern of an application, it needs to happen from the outset. Some of the most valuable data you can collect is the data as it is happening. When collecting data for a system think of building fountains not statues. The steps of how the data moves has business and diagnostic value.

The difficulty of scaling an application is linear.

An ant can lift 50 times it’s body weight. An ant is very small. If that same ant were the size of a human, it’s own body weight would break it’s legs. Scale is extremely important.

Tight optimizations that work at smaller levels of scale don’t work well at larger levels.

Scaling an applications is linear, until it isn’t…

Go and look at how many people hit Google’s home page. At the time of this post Google averages 3.5 billion searches per day. If you have a CSS class and you can take out 2 bytes from that class. Change the class name from logo to lg. That’s 7 Gb of network traffic saved by just 2 bytes.

A project rewrite is typically a good idea.

Project rewrites are very expensive and very dangerous. They are a good way to lose data or break entire system. In essence rewrites throw money away to get something that may not be as good as the original. Project rewrites might fix outstanding issues, but they will introduce NEW bugs. Now under a time crunch to release so new bugs are not fixed. Backward compatibility often does not get carried over.

While you rewrite, your competition improves. You are running for months to stay where you are, while everyone else in the market runs to get ahead of you. Think back to an old browser that isn’t in the market any longer. The Netscape team decided to rewrite due to too much technical debt. In the meantime other browsers came out and moved forward.

Good relations with people from other departments don’t matter.

Most frequently between developers and sales. Sales teams are sociable, happy, and outgoing. To them a problem is an opportunity for growth. Developers however tend to be isolated and pessimistic. They see problems as more work and try to predict them before they happen.

A good salesman walks across the street and doesn’t even look.
A good developer looks both ways on a oneway street.

The function of the sales team is to make promises to the customer to bring in money that pays the developers. The issues ensue when they make promises that cannot be kept. A good working relationship between development and sales teams can not only lead to better sales but knowledge of what customers want and ideas on where to focus development.

Engage with other departments, go to lunch with them. Get to know the people and learn how they do things within your organization. Putting a name and face to the people in other departments humanizes them and creates a better understanding for how they contribute to the overall health of the company. Open a dialog for better understanding and communication.

As stated earlier this is not an exhaustive list but a few key beliefs that are held by many developers that need to be changed. Not all developers believe these and not all that do believe all of them. If one of these nine points hits a nerve with you ask yourself why? Why do you believe this or why do you disagree with this post? Listen to the episode for even more detailed explanations and a lot more examples. If you still disagree let us know in the comments. If we left out something that you feel is important also let us know.