Programming

Tell Them No, Just Never Use that Word

I was at an agency meeting some time back, when the head of the company addressed the sales team requesting they take programmers to client meetings as needed. It was at this point I witnessed a lead salesman turn to his colleague and say, “not a chance.” This event didn’t go unnoticed and got around the IT department fast which led to a few conversations. The one concern we got back from the sales team is that the IT people always say no. There is a solution to this, but we need to understand the problem first.

From the time we are little kids, we live in a world of no. No dessert until you finish your vegetables. No, you didn’t clean your room. There’s a lot of big frustration around such a little word. We all want to run around and do what we want. As children, the first part of being punished for misbehaving starts with your parents yelling the word no. It takes our heads out of the clouds and puts our feet back on the ground.

As adults, no gets internalized. We don’t kick and scream when we hear it, although that would be funny to see a board room full of executives “expressing” themselves. Under the calm veneer of professionalism, we are all emotional animals that get mad when we don’t get what we want. That’s not to say we are all boiling under an icy exterior, but telling someone no has real consequences.

No comes from the head, but goes straight to the heart. A programmer rationalizes why something can’t happen because of logically based perceptions. These opinions are not formed out of malice or petty dominance, but far too often are treated like they are.

Before you whip out the big N-O, remember it’s an emotionally charged and potentially damaging word. People are scared to hear it. In the world of business, you will be judged for using that word and the negativity will come right back at you. People will make up all kinds of reasons why you told them no without diving in to deeper issues. It can be a little ridiculous, but it’s the world we live in and we need to adapt.

There are ways to disagree without saying no.  And before you call me out on being manipulative, I am not advocating any level of political doublespeak and clever misdirection. Not because it doesn’t work, but because programmers are smarter than that and we don’t need to lie. So you take no out of your vocabulary, but what happens when you find yourself in a no situation?

The two situations I normally encounter are when requests are literally impossible to achieve and the other is when they makes no business sense whatsoever. Programmers are problem solvers. So use your talents and think about what can happen and what does make sense. Focus on the reasons why something won’t work and develop a solution that fixes those problems.

A common situation is being given an unrealistic deadline. So instead of saying no, tell them about what you can accomplish in that timeframe. Figure out how to stage multiple releases and let the client know that you will concentrate on getting the core functionality right. This helps the team focus on what’s important. If you come up with a better solution, everyone wins.

It’s an educational process that involves the programmers, account service, and the clients. Don’t be mad at them for not knowing. You have to educate them about what reasonable possibilities are and they will educate you about what their problems are. When you fully understand the problem, you should have the confidence to offer up an alternative if what they are asking for doesn’t make sense. And remember, you’re employment depends on your company’s ability to sell something. I would rather be coding than playing salesman, but a good team has to help each other out.

Sometimes a dumb request can be a smart one with a little work. And sometimes despite everyone’s best effort, our clients won’t be persuaded at all. Even if you fail, the best part is you learn what will and won’t work. In time you find ways to shelf the word no in favor of a conversation, at least that’s what works for me.

I love the responses I get from my posts. What I would like to do this week is for those of us out there who have had success in dealing with these situations to post how they handled themselves to help others who might be struggling. After a week, I will take my favorite top three and repost to the main blog as guest entries. Thanks!

The Business of Beautiful Code

A little while back I had a technology director tell me it doesn’t matter how well code is written as long as it works without breaking and gets the job done on time. Why sweat it using complicated techniques that not everyone understands when there are more simple ways to do the work. After all, things can look the same on the surface regardless of it being well engineered or put together with duct tape and glue.

This guy liked the intellectually lazy, brute force approach. Don’t think. Just start coding now and get it done. Copy and Paste are now your two best friends. Well, mankind did build the pyramids with Stone Age technology. So I suppose there’s a lot you can accomplish with brute force, but I prefer to use my brain.

Writing software is a very creative discipline that requires a lot of abstract thinking about organization and performance. There are thousands of ways an application could be engineered. It first involves thoughtful planning at the beginning before a single line of code is ever considered.

Writing beautiful code is not just some nerdy game programmers engage in to see who can sit atop nerd mountain with their 4x scepter of insight. It’s about pure design that solves a problem. And there’s a real benefit to business. Beautiful code saves money. Beautiful code makes money. Ugly code gets work done quicker, but it’s like winning the battle, and losing the war. In time, bugs pop up and clients make changes that are impossible to accommodate. Sounds like time for an analogy.

Web sites and applications have a lot in common with cars; they both have a purpose and a personality. Just as we judge a car as being good or bad for a multitude of reasons, we can draw our analogy from these similar evaluations.

A car is designed around the driver, but for many it’s what’s under the hood that counts. Engines can be a mystery though. Sure, people get the basics, but it takes a mechanic to be able to take it apart and put it back together and an engineer to create one from scratch.

When we run a piece of software we look at obvious performance issues. Does it run? How often does it break? Most people you work with will get it up to this point. And from what I have seen, they only care about it up to this point. But, what about real performance?

In the automotive world, performance is well marketed to consumers. They take a certain feature, give it a name, and tell the consumer to want it. Traction control, dual overhead cams, and fuel injection are sold to the public regardless if they have a clue about what it means. The car nerds understand dual overhead cams makes for a more powerful engine. The general public just knows it goes faster.

Beautiful code is high performance. And everyone wants that because it’s faster. Google markets their speed. Type in any topic and you will see at the top of each page a list of how many things were returned and how fast you got them. It’s really impressive when you stop to consider how much data is being sorted to return relevant information. It doesn’t matter if you are writing code or building an engine, you can’t get good performance from a lack of engineering. Speed is good, but maintenance is even more import.

Cars are expensive to maintain and so is software. A study conducted by Human Factors International found that 80% of software life-cycle costs occur during the maintenance phase. Okay, cars aren’t as expensive to maintain as software, but you get the point. Well written software is designed to be updated, changed, bitch-slapped or whatever. It should take it like a man. There are real financial consequences when code takes a long time to update. It can even cancel a project. What I have noticed over the years is regardless of what I am told; I always end up having to go back into something to make edits. As important as this is, there is one more reason why the quality matters.

If an engine is well built, you can put it in several other cars. Good reusable code works the same way. If it’s done well, it can be placed in many applications. There is a business law that states the cost of products and services go down over time. It’s called the experience curve. Businesses find cheaper and quicker ways of getting the work done. When a cheaper way to do business is found, a company charges less to increase volume, or operates with higher profit margins. Either way competitors are adversely affected. Beautiful code can become that competitive advantage to manage the curve.

It’s all about money. It usually is. Ugly code may look like the practical choice. It’s an easy solution when you become defined by deadlines. Some programmers work that way, but surviving isn’t thriving. For businesses to grow and stay competitive they have to have a culture that prizes beautiful code.