Agile Zone is brought to you in partnership with:

Michael Norton (doc) is Director of Engineering for Groupon in Chicago, IL. Michael's experience covers a wide range of development topics. Michael declares expertise in no single language or methodology and is immediately suspicious of anyone who declares such expertise. Michael is a DZone MVB and is not an employee of DZone and has posted 41 posts at DZone. You can read more from them at their website. View Full User Profile

It's our own damn fault

11.19.2010
| 10363 views |
  • submit to reddit
It ain't easy slinging code

Over the course of my more than twenty years in the software development industry, I've worked with hundreds if not thousands of developers. Many of the projects I've been involved with have suffered from the same malady; a disconnect between expectations and realistic possibility.
The Agile Manifesto attempts to address many of the root causes of this malady. It encourages individuals to interact, collaborate, communicate, and respond to change. These are not easy things to do. Nor do they necessarily ensure quality software.
The Manifesto for Software Craftsmanship gives a clear nod to the Agile Manifesto and then extends it by addressing the need for quality software. These are not easy things to do.

The man is always keeping us down


Many developers look to this inequity and the challenges and realize they are helpless against unrealistic demands. External forces are at play; leadership, management, or sales - no matter. They neither listen nor care. They want it done. They want it all done. And they want it yesterday.
So we cluster together. We lament. We gnash our teeth. We wring our hands. We commiserate. And then we perform our duties in compliance with the demands set upon us.
It is not our fault. Try as we might, we get no respect. No recognition. No appreciation. If we don't crank fast and put in the long hours, they'll just find somebody who will.
We have no choice.We are victims.And we need only for "them" to understand and allow us to do our jobs well.

It's our own damn fault

Where do we get off? Absolving ourselves of responsibility for the quality of our work by blaming others. We rationalize doing a lower quality job in the name of pressures, deadlines, and promises made by others. But it is we who deliver the software. It is we who ultimately make the decision to not test enough, not refactor, put in excessive hours, and not do a quality job.
And every time we do this. Every single time we say it can't be done but then deliver a steaming pile that closely resembles that which we said couldn't be done; we reinforce the behaviors. Every time we put in excessive hours to be heroes, we set a precedent for the next time. Every time we compromise quality in order to meet unrealistic expectations, we devalue ourselves and the service we provide.
We haven't the right to complain about the very behaviors we enable.

Never ask permission...


If we want to stop this pattern. If we want to improve the reputation of our profession. If we want "them" to understand, then we need to change our behavior. Take a stand. Do your job well regardless of the pressure. A doomed project is doomed whether we compromise on our values or not. The more of us who behave this way; the more of us who insist on quality from ourselves and our teammates, the more evident it will become that this is not only a better way, but the right way - perhaps the only way.
Do your job. The absolute best you can. Keep learning. Keep improving.
Never ask permission to do your job well.
References
Published at DZone with permission of Michael Norton, author and DZone MVB. (source)

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

Comments

Philopator Ptolemy replied on Fri, 2010/11/19 - 9:56am

Sounds like quixotic goals. It probably needs a disclaimer that trying it might lead to getting yourself fired:)

Igor Laera replied on Fri, 2010/11/19 - 10:26am

 

We had years ago in a project a long discussion about the fact, that some modules
in the large app are simply bad. You can see that in the amount of change requests
and bugs over time, that this thing needs a large rewrite.

The "solution" to the problem by management? Removing the ability to see this type
of information in the issue tracker for anybody outside upper management.

I can see where Scott Adams (Dilbert Comics) get his ideas...

Andries Spies replied on Sat, 2010/11/20 - 8:44am

Why is it that developers should always be the first to understand and cave in under other people's expectations? Why not once expect the "other" (managers, testers etc) for a change to understand.

Amin Mansuri replied on Sat, 2010/11/20 - 3:53pm

Read Steve McConnell's book on Software Estimation. He makes the difference between "Estimates", "Goals" and "Commitments". Often we're asked for an estimate but what they really want is a commitment. His book explains it better than I could but it also gives some key ways we can educate the consumers of our product. The other advise he gives is to always overestimate and commit to it. It is better to have a project who's costs are capped than a never ending project. In the long run you'll be respected more. But better just look at his book, my portrayal is incomplete.

Cosmin Mutu replied on Mon, 2010/11/22 - 1:59am

If your goal is to work like a slave, yes ... put in all the long hours and make every project work like a swiss clock ... but hey, at the end of the days (your days) you`ll understand that the company doesn`t really care about your biological clock (the one you stoled hours from to put into your projectS)... and you`ll be old, with no social life, with no real friends (except co-workers) and with lots of good working projects :) nice life ...

And btw, why should programmers always accept what sales / project managers / etc decide for them? Frack`em! If they sold a project with a deadline too short that`s a BAD SALE ... ofcourse you can sell anything if you sell it for 50% cheaper than it should (either if it`s money or time).

So frack`em :)

Tony Siciliani replied on Mon, 2010/11/22 - 5:09am

Your description is pretty accurate. The other part about reacting to job assignements isn't however very realistic.

 Yes, everytime we put in long hours we set a precedent. We compromise quality by rushing to meet deadlines,e tc...But what do you propose, exactly? Refusing not-so-realistic expectations with the argument of not compromising quality?

Seriously, how many programmers do you know, who did precisely what you propose and lasted in their job? Just curious. It's not that we indulge in the cult of victimhood, it's just that many if not most of us can't afford what you're suggesting.

I'd rather see some small concrete suggestions. As an example:

http://97things.oreilly.com/wiki/index.php/You%27re_negotiating_more_often_than_you_think.

It's not much, but it's better to just say "it's your own damn fault", or "Don't let them do that to you" or "Yes, we can".

Daniele Dellafiore replied on Thu, 2010/11/25 - 12:46pm

+100

That's the way to roll, the way I roll.

I am totally with you Michael. Totally.

Emma Watson replied on Fri, 2012/03/30 - 3:56am

Great article. I did exactly what you recommend - and now I'm unemployed!
The bosses don't recognize software quality because they don't know about it. It runs and that's all what matters. I think, before we can produce quality software, our bosses should take some seminars where they learn about it! Sad but true, "Duct tape programmers", "Cowboy programmers", they are the heroes for them and not geeks who want clean, maintainable and reusable code.

JDBC

Comment viewing options

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