Agile Zone is brought to you in partnership with:

Jared Richardson works at Logos Technologies As a recognized expert in the software industry, Jared has worked with both start-ups and software giants. He's been involved with various open source projects, with roles from contributor to founder. Jared co-authored the best selling book Ship It! and Career 2.0, and founded the Agile RTP user group as a local outlet for the agile community in North Carolina. His personal blog is Agile Artisans Jared has posted 52 posts at DZone. You can read more from them at their website. View Full User Profile

You're a Bad Programmer. Embrace It.

  • submit to reddit

How many developers think they're good programmers? We're not. We're all fairly bad at what we do. We can't remember all the methods our code needs to call, so we use autocompleting IDEs to remind us. And the languages we've spent years, in some cases decades, learning? We can't even type the syntax properly, so we have compilers that check and correct it for us.

Don't even get me started on the correctness of the logic in the code... I'm looking at a chart that shows failure rates for software projects. "Small" projects (about a year for 8 people) have a 46% success rate. That's almost half. Any longer project just plummets down to a 2% rate for projects costing 10 million or more. In other words, our projects nearly always fail.

We constantly write code that breaks existing features. We add features in ways that won't scale. We create features nobody wants.

In short, as an industry, we all stink.

You can fight this. You can summon your "inner lawyer", the voice in your head that always defends you and tells you how great you are. You can take the typical developer's attitude that "it's always someone else's fault". My seven year old does that a lot too.

Or you can embrace it. Admit it... humans aren't good at programming. It's a task that requires extraordinary complexity and detail from brains that don't work that way. It's not how we tick. We might enjoy programming, we might get "in the zone" and loose track of time, we might spend our nights and weekends writing code for fun... but after years of practice, we still need these crutches to prop us up.

Once you've embraced this bitter reality, you can start to move forward. Once you've admitted to yourself that you're a bad programmer, you can stop all the silly posturing and pretending that you're great, and you can look around and find the best possible tools to help you look smarter than you are.

If we know that anytime we touch code, we'll probably break something, then we can look around to see what catches functional breaks in code as quickly as possible? A good continuous integration system combined with a good automated test suite.

Creating a good test suite is a lot like working out though... we all know we should, but we rarely take the time to create a solid, workable test automation strategy. Something like Defect Driven Testing is a great place to start.

If you recognize that we all write the same fundamentally bad code that everyone else does, then you can look around at static code analysis tools.  If you're writing Java, I highly recommend FindBugs.

These tools flag common mistakes... really common mistakes. Things you can't believe you actually do. But somehow we do nearly every day. I've met many development teams who didn't think they needed static code anaylsis. But I've never run a tool like FindBugs without finding a real (read: not theoretical) problem in production code. They hadn't learned to embrace their badness yet.

If you don't know what code is being exercised by your manual or automated test cases, look at a code coverage tool. Cobertura is my favorite, but I'm a bit biased as I had a hand in getting it started. (Why isn't it listed on that Wikipedia page??)

If your team is constantly getting interrupted and pulled in different directions, try tacking smaller units of work. Time boxed iterations, especially the one week iteration, force you to tackle and complete smaller units of work. It's easier to push back on an "emergency" change if you can ask them to wait for only two or three days. If you're on a two month task, they won't wait.

Admit that you're a sorry sysadmin as well and script your deployments. Tools like rake  and capistrano are extremely powerful tools that can completely automate your development, testing, and even production deployments. Once it's scripted, it becomes incredibly easy to duplicate. You'll be amazed at how much time this one will save you.

Of course, if you've automated your code deployments, it'd be silly to keep typing in SQL commands by hand. Ruby on Rail's database migrations may have been the early leaders in this area, but there are plenty of other tools available today. One prominent tool is Liquibase. Here are two good articles with plenty of information. and

How about customer interaction? Yes, we're bad at that too. (Ever used the phrase "stupid users"?) Try moving your specifications into a more precise, and even executable format. DSLs (Domain Specific Languages) provide a wide variety of ways to engage a customer with a precise, but understandable, langage.

There are a great many tools we can use to make ourselves look smarter than we are. Once we stop fighting against the need for the tools, and embrace them, we start looking like we're pretty good developers. I won't tell anyone you stink if you don't tell them about me. ;)

Published at DZone with permission of its author, Jared Richardson.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Nicolas Frankel replied on Thu, 2010/09/30 - 4:35am

The tools, frameworks and methods you describe are great but I must challenge your initial assertions:

We can't remember all the methods our code needs to call, so we use autocompleting IDEs to remind us

Does it mean you're a "good" programmer when you have all the APIs in your head?
I'm looking at a chart that shows failure rates for software projects. "Small" projects (about a year for 8 people) have a 46% success rate.
I'm sure most managers will happily agree with you that programmers are behind these failures but I can think of many reasons that lie at the root of the problem - and programmers are not one of them (try not enough project owner implication, no change management, etc.)

Michael Kimsal replied on Thu, 2010/09/30 - 8:26am

As Nicolas implied, there's many more reasons than programmers why projects fail. I've rarely been on a project that failed because someone on the team didn't know how to write to a file, sort an array, connect to a database, etc. The root issues are always about communication, within the team or with the client/stakeholders. Whether IDEs auto-generate some of that code for you or not is not a *huge* issue, and is often not a factor in project failures. Hitting some deadlines because you're getting up to speed on an API, possibly, but that's rarely the cause of total failure.

I would say your other points are on target - get better with the tools we have. 100% code coverage in tests doesn't guarantee success, but 20% coverage (or no tests at all) will likely be an indicator of bigger problems to come.

Test-driven thinking has given me a new focus in my development efforts. I can't say I'm 100% TDD in all cases, but I'm moving in that direction. I've grown fond of saying "the testing is going to happen, but we have a choice as to when the testing happens. A) Before and during the code writing process or B) Saturday morning at 2 am when the project is launched and broken and causing major issues". I've done both A and B and prefer A for a number of reasons. *Not* testing is a false economy which anyone who's fixed issues at 2am on a Saturday can attest to.

I know a colleague who had a PM telling him what to add on a project. This colleague had spoken to the stakeholders numerous times, and they'd actually abandoned the project 2 weeks earlier - they bought another product. When this was brought to the PMs attention, his response was "they don't know what they're doing - keep working on what I told you to work on". Talk about lack of communication - respect between departments even.

Getting yourself in to some other platforms can help you embrace your badness as well. Learning how other camps think about the same problems you've faced for years will give you new perspectives you can learn and grow from, and take back to your original platform.

Certainly knowing your APIs, libraries, tools, and platforms helps a lot. Communication (written, spoken, automated tests, etc) help a lot too.

Alessandro Santini replied on Thu, 2010/09/30 - 9:18am

I personally liked Jared's irony and think that, at the end of the day, his bottom line is correct: as human being, we need tools that help ourselves with our human inconsistent delivery.

Having said that, I do not understand why Sonar is not one of the tools cited in this article.

Alexandru Repede replied on Thu, 2010/09/30 - 9:34am in response to: Alessandro Santini

"as human being, we need tools that help ourselves"

     it's called leveraging, and we're really good at it :)

Jared Richardson replied on Thu, 2010/09/30 - 9:38am in response to: Alessandro Santini

An oversight on my part. ;) Why don't you post a link and tell us about it?

Jared Richardson replied on Thu, 2010/09/30 - 9:41am in response to: Michael Kimsal

There are so many reasons why projects fail... no doubt. But I'm concerned with the tendency of developers to never accept any blame. We have more tools at our disposal than we realize. Our managers, at least the good ones, know they don't understand what we do. Provide them reasonable options and they'll often take it. If we think that failed projects are ~never~ developer's faults, then we've spotted the problem... let's swing the pendulum back to the middle.

Mark Unknown replied on Thu, 2010/09/30 - 9:43am in response to: Michael Kimsal

Michael, to carry what you said even further. The PM was not just having a communication problem. He(she?) was having a job assignment problem. The PM should be doing Project Management - NOT project leadership. I see that too often. There is just too much to know and understand to have someone non-technical (or pseudo technical) "leading" or directing the project. For instance, where i work, if the amount of work we need to do (programming) is greater than X number of hours, then it must go through the Project Management Office. The problem is that most of them know nothing about application development let alone modern application development. They follow the same process they did on Mainframe applications. Not that they are bad. Just different and different skills. And thus once they get assigned, they are "in charge". A PM typically does not have the skills knowledge or ability to pick the right person or tool or direction to do the job. And yet, they are "in charge" or tasked with doing this.

And Bod replied on Thu, 2010/09/30 - 12:14pm

Yes sir, it's true, programmers are great at finding out reasons why it wasn t their fault, they go to great lengths depicting who did stupid and why. Do you know why they re so skilled at this?(and at this point i regret not having the possibility to write in big red letters ) BECAUSE IT S TRUE. OK. IT BLOODY HELL IS. I ve seen alot of projects fail and only a smidgeon of those were so because the dev screwed up, didn t knew how to write code or was just lazy. The huge majority went south cause of the rest of the team, you know the client relations/ sales guys the team leaders and general crap from crappy companies. Writing code is hard and complex enough , I shouldn't also have to deal with a pissed of customer because the imbecile over at client pr pissed him off or work on a 600 dollars laptop because the cretin supply guy doesn t know what a 7 minutes compile time means. So, sir, i really think that as far as project staff goes the devs are the last ones to have to look at or embreace their failures, way behind the line after all the other lazy brain idiots that are involved in the process. And yes even a mediocre dev is royally alowed to be smug in front of these people as he already knows and understands stuff and basically has flexed his brain more by the age of 23 then these people will do in all their lives all taken together.

Hajan Selmani replied on Thu, 2010/09/30 - 1:47pm

Very interesting article... I agree with many points here, but I think its not all like that. Trust me, I've met a colleague (he has 7+ yrs of experience) who doesn't need intellisense to write a code without any mistakes. However, programming is ART and not everyone can be an artist, even though, many new developers (bad artists) got into this field just because they have heared you can find job easily and be good paid.

As per the project failures, we can't blame some specific group when talking in general. It might be anyone or many that work in the project for the project to fail and is definitely tied to to the specific cases.

Last, the tools that we use to help us in our daily work are built by humans in order to speedup the process of development (as you already know), otherwise many businesses will fail OR the development of IT technology would go much slower! ;)

Thanks for the nice article!

Mario Fusco replied on Thu, 2010/09/30 - 2:59pm

I totally agree with Nicolas. He practically put in words my thoughts. The tools you mentioned are all very useful and indeed I use almost all of them.

Said that, to declare that we are not good programmers because we use autocompletion is like to say that a mechanic is not good at his job because he uses the srewdriver instead of screwing with naked hands. Doesn't it sound EXTREMELY stupid to you?

Michael Kimsal replied on Thu, 2010/09/30 - 6:59pm in response to: Mark Unknown

Agreed, and that's a good distinction I wasn't able to offer to my friend at the time. (really it wasn't me, but I knew the players involved).

Charles Sutikno replied on Thu, 2010/09/30 - 7:27pm

Likewise, I agree with Nicolas and Mario; tools are created (for instance autocompletion in IDE) to help us focus on the logical/design side of things and worry less about lower level details of code (methods need to be called etc). I hope this is not our 'inner lawyer'acting out =P. 

Other than that, a worthy read!


Jared Richardson replied on Thu, 2010/09/30 - 8:07pm in response to: Mario Fusco

Hi Mario... I'd say that a better analogy is a mechanic who uses a screwdriver instead of an electric drill with a screw driver bit. The mechanic who says "I've always used a screwdriver and it's good enough for me!" is the problem. Don't just learn one tool then stop learning. Of course, I phrased a bit more controversially in the article. ;)

There's nothing wrong with using autocomplete ~unless~ it keeps you from really learning what's going on. If you can't function without it, then I'd say you've got a problem. I often suggest developers go on a one week IDE fast. No IDE for a solid week. Learn to function without an IDE and you'll be even more productive with one.

Jared Richardson replied on Thu, 2010/09/30 - 8:14pm

Be careful of ~always~ blaming someone else for our project's failures. If we're really a team, then we all fail together. If you've ever worked at a company that went broke, you understand that. No one group failed, but we all failed as one.

If you've got a manager that's having trouble getting you requirements, how do you reach them? I've found that shorter iterations with working features is one way. Give them something to see and understand sooner rather than later. After all, software is like pornography. Techniques like tracer bullet development let us create "working" demos sooner, then add in real functionality as we go.

Another is using a Kanban-style swim lane or The List. Ask them to edit the work you're doing next. They may not be very good at telling you what they want, but most people love to edit anything you give them... so offer them the next 5 things you're adding. It's a way to extract a bit more information from them. You can do the same with customers.

There are so many ways we can "manage our managers". It's not always our fault, but it's not always their's either. There are many techniques we can use to extract more feedback more quickly, but too often we prefer to withdraw and complain.

Developers in general have gotten entirely too comfortable throwing the blame at managers and customers when projects fail. Grow up and accept your share of the blame. We've earned at least as much of it as anyone else involved.

Jared Richardson replied on Thu, 2010/09/30 - 8:16pm in response to: Charles Sutikno


Tony Siciliani replied on Fri, 2010/10/01 - 5:04am

"There are so many reasons why projects fail... no doubt. But I'm concerned with the tendency of developers to never accept any blame."


That's not what I'm concerned with at all.

I'm concerned with management's tendency to never accept any blame, because that is the most common occurence I've seen. As for developers, they often have no choice, since they end up getting most of the blame anyway.

Christian Vigh replied on Fri, 2010/10/01 - 8:14am

Hi Jared,

Your article somewhat made by jump off my chair ! for several reasons :

1) You are drastically summing up a whole community of developers by presenting them as bad developers. I admit that we are human beings and, as such, we are tending to believe that we are better than we actually are. But, apart from being a personal development issue, this human behavior really becomes a management issue during working hours : it is then the manager's responsibility to make his guys aware of how skilled they are and which directions they should work on in the future.

2) You didn't take into account the maturity level of the developer and how productive he/she can be ; you mentioned some studies about the success rate of software projects with regards to their size. I have in mind another american study that showed a productivity/quality ratio ranging from 1 to 24 among a group of developers. Some people are really made for software development. Most people need some help on that task and, again, this is a management issue.

3) Young developers tend to reinvent everything and bypass certain crucial tasks, such as testing, documenting and so on. They also need time (experience) to be able to climb abstraction levels when designing software, and hold in mind several concepts at the same time when designing an architecture. Senior developers/designers can help them in acquiring this experience during a project lifecycle. Again, this is a management issue.

4) A word about Domain-Specific Languages : I once in my life have been a software developer for a french software company that provided administrative solutions for hospitals and resting homes. When developing new modules we had to interview our customers on their work, and how we could offer them a software solution without any overhead, helping them reducing their administrative workload. Imagine a 50-years old miss working in a small resting home lost somewhere in the middle of France ; She's working on a computer only because her Director imposed her a computerized solution. She doesn't yet see that the installed software is here to reduce her workload for performing day-to-day administrative tasks that occur in the management of a resting home. Imagine now that you are a developer that has the objective of developing a new module for the administrative software and that you have no choice : SHE is the only user that has the knowledge that you need to achieve this goal. Would you show her state-of-the-art really truly professional conceptual models or try to teach her some formalism or DSL ? If you did so, she would consider you for eternity as a complete alien : she doesn't even know the difference between the '#' and '$' signs on her keyboard. It is our responsibility to translate customer needs into a human-readable text (not a developer) and check that with them. Once this step has been completed, we can use whatever formalism we think is appropriate.

5) Project size is not the only factor of risk in a project. Consider the following example : your manager comes to you, developer, and asks you : "how long would it take to achieve this task ?". Based on your experience, your first feeling is 2 months. But your experience also tells you that you need to multiply your estimates by 2.5 (we all know that). You daren't say that it could take 5 months. So you say : 3 months. Your manager, before asking you the question, thought : 1 month. Chances are even great that he already communicated this estimate to his management and that he came to you only for feeling reassured. So what happens ? complete failure. Bad developer.

But you're right : we have to use whatever tools that can help us produce more robust code, more rapidly. We have to fight against the Not-Invented-Here syndrom and, believe me, sometimes a whole life is not enough for that. We have to share the knowledge we acquired while making mistakes.

To sum up, you provided a list of tools that we might not be aware of, and that can be of invaluable help during the development effort.


Jared Richardson replied on Fri, 2010/10/01 - 8:18am in response to: Tony Siciliani

If you think this is bad, you should see what I tell managers. ;)

I've spent some time in management, but a lot more as a developer... years more. I'm not interested in getting together a pity party and telling everyone how bad their management is. Plenty of other people are doing that. What can we do about it? If nothing, then let's just give up and live out a Dilbert-esque life, tolerating our pointy-haired bosses and being miserable. That's not a life that I want to lead.

If there's anything we can do about it, we'd be doing ourselves an enormous injustice by just sitting around and whining to each other about how bad all the managers are. Are we really helpless or are there tools and techniques we can use to help drive projects forward ~in spite~ of our managers? Are our managers really incompetent clowns, or do they desperately want to succeed (just like us!), and do they need to be educated on what we're doing and the most effective ways to get work done? If your manager hasn't figured it all out on their own, should we stand back and mock them or try to help?

I like the original direction of this article, but I think a follow on needs to tackle ways to manage up or ways the developers can help ensure our projects move forward. It's definitely emerged as a theme in a lot of the comments.

Eric Asberry replied on Fri, 2010/10/01 - 9:28am

Excellent article. Programmers who can't admit to needing all the help they can get are dangerous. :)

Christian Vigh replied on Fri, 2010/10/01 - 9:28am in response to: Jared Richardson


my posting was neither a trial to put in place a "pity-party" nor to perform unlimited whining sessions.

I have been a manager too and I have been focusing on social considerations. I realize that this may be out of subject in the context of this article.

You are true when you are telling people to be aware of their limitations ; you are true when you are suggesting them to move up and find appropriate technical solutions ; you are helpful when giving them links to useful productivity tools.

But please Jared, don't tell me : "Christian, you're a bad developer, but I have the right technical solutions that could help you think against all odds that you are better than that". I'm not a 7-years old child.

Jared Richardson replied on Fri, 2010/10/01 - 10:18am in response to: Christian Vigh

Hey Christian,

Your comment wasn't posted when I started typing that response. It appears after your comment because we don't have threading, but it was a reply to Tony's note, not yours. If you click the "In Response To" link you'll see that.

And to be fair, it was really more a general purpose reply that even to Tony's comment. But no offense was intended. I'm loving the lively debate and the different points of view the comments are bringing out.

Christian Vigh replied on Fri, 2010/10/01 - 11:41am in response to: Jared Richardson

Oops I'm sorry on my side as well ! I'm new to this site and I didn't notice that there was no threading. I really thought your answer was intended to me !

I like to freely debate as well and, similarly to you, no offense was intended... I will pay more attention in the future !

Avi Yehuda replied on Fri, 2010/10/01 - 4:44pm

Nice article and a good wake up call. No doubt that programming has a lot of ego around it.

Alexander Radzin replied on Sat, 2010/10/02 - 2:41pm

I agree with 99% of the article. It is fine that it is already written. Otherwise I'd have to do that...

Moreover I tried to explain similar ideas to my managers and ... had to leave company where I worked :(. I believe that it is because I was managed by bad managers that not only do not understand what I do but moreover do not understand that they do not understand.

Christian Vigh replied on Sat, 2010/10/02 - 3:09pm

Hi Everybody,

I have read your comments with great interest. I liked Avi Yehuda saying "Good wake up call". This is true. We often need some external highlights that say : "hey guy, take time to have a more synthetic look at your activity. Take time to look for external tools that might help you. Take time to be humble. This will not be wasted time".

I really do believe that the relationship between a manager and a managee is like the relations in a couple ; when something goes wrong, the responsibility is never at 100% over one head. The real danger in such a situation is having two people trying to find out who could have the sole responsibility of the situation that gets so bad ; ie, the danger is spending more time in finding responsibilities than in finding solutions.

Let's be clear : employees make as much mistakes as their managers do. We have all to be aware of that because we all need to make our projects reach their goals. Between over-estimating ourselves and under-evaluating ourselves, there is a middle position that says : "ok, I've been really good on this, and really bad on that ; let's learn from this experience".

And let's be humble...

Tony Siciliani replied on Mon, 2010/10/04 - 9:20am in response to: Jared Richardson

Developers are not exactly just sitting around and whining, as they often are the ones to have to put on extra hours at nights /weekends to try to accomodate changes in (poor) planning from up the hierarchy, last minute changes in user's wish list, unrealistic expectations of upper management, etc..

 Yes, some of the blame is deserved, most of it isn't. The bigger problem is with the latter, not the former.



Tony Siciliani replied on Mon, 2010/10/04 - 8:26am in response to: Avi Yehuda

"No doubt that programming has a lot of ego around it."


All things are relative. When compared to overpaid consultants for example, developers are a rather humble (& incidentally productive) bunch.


Adam Smith replied on Tue, 2010/10/05 - 8:25am in response to: Tony Siciliani

You're a union member, right?

Jim Le replied on Thu, 2010/10/07 - 10:03am

Oh boy ... anyone who would love to work with this sack of self-important skin please raise their hand.  Anyone?  Anyone?


I thought so.

Xebia Labs replied on Fri, 2010/10/08 - 1:08pm

Hi Jared, you make some interesting points. With so much code being constantly updated and replaced, we think it’s impossible to survive as a programmer without the training wheels. The only problem, though, is that this tends to slow you down. Luckily, a lot of tools are becoming more and more common that help programmers get their work down faster, such as deployment automation. It is not uncommon for operations teams to get slowed down by all the code required to deploy applications, but automating these deployments frees up time and eases the workload. Have you seen deployment automation being used as an aid by programmers?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.