Developers Need To Fail

Is failure the opposite of success?  If you fail does it mean you didn't succeed?  Does failing bring you closer to success?

Fear of failure is actually worse than failure.  Everyone has a fear of failing.  This often keeps us from doing something with all of our effort.  If we put in all the effort and we fail, does that mean that we are failures as human beings?  Our culture and our media would have us believe that was true.  Our ego would prevent us from coming to that conclusion, so it's just better to not try our best.  We're better off just doing a good job and holding something back.  That way when we fail we can always say "Well, I didn't really try all that hard, did I?"

Let's look at this with an example.  Let's say that your long term goal is to be in a relationship.  You want a girl who is beautiful, intelligent, witty, friendly, and a delight to be around.

You find a girl who meets these qualifications and are excited about her.  Do you ask her out?  What if she says no?  If she says no, does that mean you are less of a human being?  Does that mean you aren't worthy of a girl like that?  What would that do to your self-esteem?  Is failure at getting this girl you've chosen freezing you to inaction?

Here's the most important question.  If you never ask her out, will you ever go out with her?  If you ask her out and she says no, and you silence your ego, doesn't that make it easier to ask out the next girl?  If you ask out three girls and three say no, but the fourth one says yes, did you fail three times and succeed once?  Or are you just successful with women. 

When you've been married for twenty years, will it really matter that three girls rejected you before you found the one you ended up with?  Will anyone list your failures?  Will anyone really care?

But I can promise this, you'll never go out with her if you don't ask her.  It will just never happen, and you'll have failed before you even started.  It is much, much better to try, fail, and improve, then it is to never try at all.

This is a weird post for a software development blog.  My point is that developers need to feel like they are in a safe environment to fail.  If they think that failing is dangerous, then they will never do anything dangerous.  Dangerous things are scary, but when they succeed, they have the ability to change an entire organization, and leave the business stake holders gasping for breath at the magnificence of it all.  

Allow developers to fail and fail often.  Just make sure it is leading them to success and they are learning from it.  Eventually, they will have a bold success.  And that will make all the failures worth it, and you'll make back any lost money and then some. 

Developers who are afraid to fail just write boring code or they just watch YouTube videos all day.  They never do anything awesome.  And awesome is where the fun is.  Awesome is what we really want.

Why Developers Quit

Every time a software developer leaves a job, I always ask them why they left.  I do this because I like the software developers who work with me, and I really don't want them to leave.

Every time I have this conversation, I'm surprised at the wide variety of reasons why developers leave.  Most, however, leave for the following two reasons:

1)  They are bored with what they are doing.

2)  They don't like their new manager, or there was a change in leadership and they didn't like it.

I always expect them to say "I left for more money" or "I left because I hated the company."  I hear those reasons after layoffs or firings, but I hardly ever hear those reasons because someone quit.

As software development leaders, it is important that we address those two issues.

The first one is easily solved.  Keep your software project fresh, using new technology, and keep your company competitive by always pushing the envelope.  This will benefit the developers and keep the company profitable and current.

The second one is a lot tougher.  I wish I could answer how to be a good leader in one short blog post.  I am writing a book on the topic, where I will go into more depth and provide more information. 

I think one thing that covers a lot of what software developers like in a manager is as follows:

1)  Shield the developers from the chaos of the business.  Don't tell them stories about how there is so much change in the organization and no one knows what they want.  Don't confide your troubles in them.  Don't blame others when projects get cancelled.  Stay positive.

2)  Give clear direction on what they need to do in order to be successful.  They shouldn't have to guess on what their top three priorities are and what order they are in.

3)  Hold them accountable.  If you remember what you asked them to do, and you check in on them and how they are doing, you are not micromanaging them.  You are actually showing them that what they are working on is important and that you care about them.  You are showing them how to be successful and worth all that money you are paying them.

4)  Tell them what they have to do to earn more money.  Give them a way to earn money from you and not all their side projects.  If they don't have a way to increase their income with you, they will start taking work from other sources and they won't talk to you about it.

This is just the reality in an industry where 100% of the good developers have jobs and never have a problem finding more work.

This post doesn't give all the answers, but if you are struggling on how to keep your top talent, minimally addressing these things will go a long way in helping you with that goal.

I Love Lucy: A Lesson For Business Analysts

In this episode of I Love Lucy, a conversation is taking place between two people who don't understand each other's languages.  They struggle to find someone who can translate between french and english, which they fail to do.  Instead, they find linking languages between them.  So the translation goes from French to German, to German to Spanish, and finally Spanish to English.

The episode is hilarious, and it highlighted to me how difficult it is for software developers and business stake holders to communicate.  Executives, Directors, and other leaders are often fluent in their line of business.  They are also fluent in general areas of business.  Words like cash flow, just-in-time manufacturing, and copywriting are thrown around frequently, and often are lost on engineers and software developers.

Conversely, software developers speak in terms that business leaders find foreign and awkward.  Words like source control, unit testing, and SCRUM are thrown around frequently, and business leaders find themselves equally lost.

Companies often struggle with these two different languages  and rather than putting in the time, effort, and energy into investing in being somewhat bi-lingual into these two worlds, they hire a translator.  Called a business analyst, these translators specialize in speaking both languages fluently.  This is an acceptable solution to the translation problem, but it is less than ideal.

Business Analysts create the following problems:

1)  In the kindergarten game telephone, a message is whispered around the circle and the original message is compared to the final message, and they are often very, very different.

2)  Business analysts are expensive.

3)  If your job is to bridge the communication gap, then you really don't have a vested interest in bridging the gap, in fact, there is profit to be made in making sure the gap is as wide as possible.  This creates a culture of information hoarding and miscommunication.

4)  When mistakes are made, blame is spread around.  Since the analysts are in the middle, you often hear several different stories on who is at fault and what the problems actually are.

5)  Translation takes time, and therefore delays projects, decreases velocity, and hurts shipping times.

So what is a better solution?  I think business people can spend 20% of their time and get 80% of the value by spending some time learning some basic terms of software development, so they understand the challenges that developers face.  I think developers can spend the same amount of time learning to serve the business they are in.   This investment is just for the initial communication issues.  Within months, these communication problems will go away, and that investment will pay off year after year. 

This small investment has no downside, will increase velocity, and will definitely improve your software ship times, while decreasing bugs and increasing software quality. 

We prefer to have constant access to our customer so we can be in constant communication.  This helps us learn from each other and grow together.  Trust will build, and software will ship.  Everyone is happy and the communication problem is solved.

Trust = Group Execution

It is impossible to grow your business if you are not surrounded by people who you trust.  Particularly, you need to trust people to do what they say they are going to do.

Software developers often erode trust by not meeting deadlines, not delivering what they say they are going to do, and not being where they say they are going to be.  They also lose trust by not answering their phone, not being responsive, and by not communicating clearly when issues are being worked on and resolved.

These problems can be resolved by breaking up very large projects into several smaller ones.  Instead of delivering something major in six months, we should deliver ten to twelve small projects every couple of weeks for six months.  At the end of six months, we'll still have the same amount deployed, but we will gain some benefits:

1)  We will increase trust through constant delivery.

2)  We will be more accurate with deadlines, because small things are easier to predict than very large things.

3)  We will gamble less with company resources, because if we fail, we will fail on a smaller two week project, and not a large six-month project.

4)  Constant delivery creates a culture of constant communication, which also builds trust.

Business people also need to earn trust.  They need to speak clearly, answer questions quickly, respond to emails and voicemails, and generally be equally communicative.  In addition, they need to set clear expectations, and take responsibility when changing requirements delays shipping.  Ideally, they would promise not to change requirements for two weeks, in order to facilitate a frequent shipping cycle.

If trust builds, great things can happen, and the business can grow and be more profitable than ever before.  Everyone can use software as a competitive advantage, but only if these two sets of people have complete trust in each other.

The Importance of Shipping Software

I play piano.  Well, not really, but I like to practice a lot.  Alone, I think I play rather well, but when I try to play in front of someone, it’s like I’m brand new and fumbling over every key.

The more people I’m in front of, the more I fumble.  It’s a funny thing how an audience heightens every mistake.

I also golf.  Well, more like hack.  But I am a better golfer than I am a piano player.  At the range, I can hit flawless shot after flawless shot.  If I immediately go to the course, all that talent I found at the range immediately evaporates.  The fact that I’m not as good as I think I am is a harsh reality.

Golfing on a course and playing piano in front of others does two key things for me.  One, it shows me where I’m struggling, because every mistake is amplified.  Two, it shows me where my actual weaknesses are, instead of my assumed weaknesses.  The more eyes on something, the more reality is impossible to avoid.  

Dealing with reality, instead of fantasy, is the central reason why developers must ship working software as often as possible.  The more they do that, the more they will enjoy it, the better they will get at it, and the more value they will provide to your users, customers, and employees.

Valve Employee Handbook

Another stellar example of phenomenal corporate culture:

Here is Valve's Employee handbook.  It is VERY interesting reading:

http://www.valvesoftware.com/company/Valve_Handbook_LowRes.pdf

My Fair Lady: A Parable in Agile

In the George Bernard Shaw play, Pygmalion, Henry Higgins and Colonel Pickering remake a poor, cockney flower girl (Eliza Doolittle) into an upper-class lady, and prepare to present her at a grand ball.  If this sounds familiar to you, the movie My Fair Lady was based on this play.

As I watched the play, I realized that Higgins and Pickering are agilists.  They would strategize on their product (Doolittle) and then release her at small events leading up to the ball.  As she would enter to mingle with guests, Higgins and Pickering would just watch the interactions.  They would never interfere.  Sometimes they would want to applaud, sometimes cringe, but they would never guide, cover-up, or cajole.

Afterwards, they would discuss what they learned.  They always discovered blind spots.  What they thought would be problems, weren’t, and they uncovered problems they didn’t know they had.  They would polish the rough edges and try again.

After a lot of effort and time, release day came.  The ball was a smashing success.  Watching Higgins and Pickering celebrate their success reminded me of how successful software teams feel when their product goes live.  They are thrilled at success, but glad it’s over.

Higgins called the whole process a “joyful strain.”  

The play ends differently than the movie.  In the movie, it looks as though as Higgins and Doolittle discover a fondness for each other and might begin a romance.  In the play, Doolittle leaves to marry another man.  I think the play is better.  If Higgins is successful in his endeaver to create an independent, educated woman, then of course she would leave her creator and make her own way in the world.  She would stand on her own.   As a software developer, our products stand on their own.  We don’t get to dictate how they are used or why they are important to people.  Like Doolittle, they are free to live their own life.