How to Guarantee That your Software Will Suck

Justin Etheredge 14 minutes later:

• • Agreed, I was merely pointing out ways in which management can guarantee that they will have an extremely difficult time retaining talented developers. With so many options available to those of us who truly care about our craft, who would want to work in a place that treats us like second class citizens?

  • But I agree with you that my software is not better because I have a large monitor or because I use Resharper, but it is better because I put the time and effort into trying to perfect my craft. If my job is made more difficult because of a sub-par environment, I am willing to be that it would affect the quality of my work.

Kevin Hazzard, C# MVP 38 minutes later:

• • Thanks, Bob, for your reply to Justin. I agree that there’s no doubt that the secret ingredient in good software is real talent. And real talent is pretty rare, I believe. Real talent plus passion is rarer still. I got a lot out of Justin’s post because it’s sometimes useful to express what works in terms of what won’t. If you make a great big pot of chili and put bad ingredients in, it will most likely be unpleasant. And, as you point out, failing to put the right ingredients in is also a bad choice.

  • The analogy kind of breaks down here, though, because, unlike chili, bad developers can become good. And that’s what’s at the heart of Justin’s post for me. I have rescued a few shops from disaster by converting their developers to goodness using some of the tools that Justin mentioned: respecting planning, buying better hardware and software, learning to buy instead of build when it makes sense, teaching them how to focus and use good design principles.

  • I certainly appreciate your culling out the truth that developers are the secret ingredient. But Justin’s message is one of hope, even if it’s expressed in the negative. I liked it, too. :)

David Simar about 1 hour later:

• • IMHO all these little things hurts the developers ego. Basically the developer reasoning is: if the company doesn’t want to invest in helping me, why would I bother doing a good job for them? This is basic psychology, if you don’t show interest in people why would they in return show interest for you.

  • The manager is here to make sure that all the employees he’s responsible for can do their job in optimal conditions. Common, let’s get back to real-world, this is just asking a few hundreds bucks to invest in tools and hardware. Developer are not asking for the last BMW or 100K$ bonus to do good job.

  • I have been in the past in bad managerial hands and I would say that 30% of the time of the team went in moaning about the stupidity of the manager!

Guy Kolbis about 1 hour later:

• • Hi Bob, my opinion is that “software may suck” when the combination of both occure. On one hand, it is about my capabilities as a developer and on the other hand it is about the conditions my manager gives me. Surely, the manager can help me be more productive…but the quality of the software depends on my skills.

Daren about 2 hours later:

• • Your both right. What makes good software is good people, both in development and management. If either is not up to par, the whole will suffer.

  • I think the following blog summarizes it well: http://ansanelli.com/blog/?p=44

  • “Would you rather have a great team with the wrong strategy, or the wrong team with a great strategy?”

Mark Nijhof about 5 hours later:

• • Hi Bob,

  • I like you down to earth posts a lot and have to say I agree with them fully. As a developer we also have the responsibility to make management understand what the implications of their decisions are going to be. So when you want a license for tool XYZ you should be able to show your manager that it either makes you work faster, more efficient or just makes you happy. Same goes for all the other things that cost money, show them the benefit, make it a well defined business decision.

  • Same goes for unreasonable deadlines make it a clear business decision and make it a bad decision to write bad code. Al do I have to say your idea is much better, because there is still the possibility that your manager will tell you to write bad code, it would be very nice to be able to say. “You hired me because you want quality work done, and that means that I cannot meet your deadlines”, have to try that next time. (no sarcasm intended).

  • -Mark

Curtis Cooley about 5 hours later:

• • The responsibility lies with the developer. I’ve worked in ‘fun’ shops and seen software suck. I’ve worked in ‘bad’ shops and seen software suck.

  • The bottom line is when I sit down to write code today, am I going to be professional or not. If I choose to be professional, I write the best code I can given the tools I have. Do I want better tools? Damn straight, but that doesn’t imply any kind of responsibility for the quality of my code to management.

Markus Gärtner about 12 hours later:

• • There is one lack I sense in your blog, but in the last paragraph I see it nearly addressed: The people behind software. What we never should forget is the context. There might be one person, who does a great job if he gets the support from management for new computer hardware. He most likely works energized and does the job well, when showing her to be relevant by providing him the hardware she would like to have. On the other hand there is the stabilizing guy, who is seeking a proper plan with achieveable targets. This person will most probably won’t be able to do a good job, if put under stress through a impossible mission. Leadership know-how is a topic that should not be forgotten under these circumstances as well.

  • In general I fully agree to your concerns, but I would like to add this note to the human factors as well.

Justin Pavatte about 19 hours later:

• • I totally agree with both of the posts. I like how Uncle Bob reminds developers to take responsibility for their code and not pass the buck. By the way, I am currently reading your Clean Code book! Also, I enjoyed Justin’s post which is I see as a message to management rather than developers.

Lee Brandt about 20 hours later:

• • Perhaps Justin’s post should be called “Guaranteed Ways to Drive Good Programmers Away” ?

  • Just a thought.

  • Great posts.. both of you.

Andy Brandt 2 days later:

• • Great post.

  • I see developers as artists. They should care about their code no matter what and try to make it as good as possible always. As I sometimes say “the art must not suffer”. Not always 100% possible, but this is the ideal to strive for.

  • One other related thought: Agile is an approach that embraces much of what Justin was writing about (except maybe huge LCD screens). However to work right agile requires much more discipline on the part of team members. Plus they must take ownership of the code they do in the sense that they should do all to be proud of what they did.

gps nextar 6 months later:

• • An avarage developer loves his work but do not know where to put his efforts and he has very short attention span. I worked with some of them and they were helpless in strategic planning (however, I have a friend developer who runs a succesful IT business, as well, but that’s an exception, IMHO).

Online Certificate Programs 8 months later:

• • Some people write so-called “spaghetti code” and that will definitely make sure software unworkable.

Designer wedding outfit 11 months later:

• • Good developers also ignore many problems and this result in a waste program.