Aug 12, 2009

Be The Change You Want To See

I get to work with a lot of developers as part of what I do, and in far too many cases I find myself asking questions when I look at their code and see how they develop.  That question is usually Why?

  • Why do you write code without any tests?  Why?!
  • Why is there Hungarian notation for variable names?  Why?!!
  • Why do you have source control with no shared checkouts (or no source control at all)? Why?!!!
  • Why are you doing deployment from a developers machine?  Why?!!!!
  • Why do you have comments in your code like: "DateUpdatedValue returns the date updated DateTime"? Why?!!!!!
  • Why are there methods in classes which have more than 200 lines?  WHY?!!!!!!
  • Why for the love of all that is beautiful is there so much rubbish code here?! WHY?!!!!!!!!!

The thing that I really struggle with and that gets me really frustrated is that these developers will try and abdicate themselves of any personal responsibility for writing code the way they have.  The excuses are typically along these lines

  • Everyone else writes it that way.
  • The code was already a mess when I got here.
  • I don’t get given time to write it properly
  • The company doesn’t care about me so I don’t care about the code
  • Management wants it that way
  • It’s not part of my job description

And my response to that?

What… A… Load… Of… Rubbish!!

We’re developers aren’t we? And aren’t developers meant to be highly paid, intelligent and logical individuals who can think and act for themselves?

At the same time, many of the developers making these excuses have the same frustrations I do but just don’t know what to do about, so they sit there and try not to rock the boat, suffering in silence until they become numb to the pain and just accept things the way they are.  How sad.

So seriously, people!  Stop making excuses or accepting mediocrity and start making some changes to improve things!

Do Something About It

Now here’s some news for you - no one else is going to make the changes that are needed for your situation to improve.   If they were then things wouldn’t be in the state they are now.  It’s time admit that you’ve spent long enough waiting for someone else to do it – it’s now time for you to be the change to want to see.

So here’s some things to consider if you’ve lived in frustration long enough and want to make improvements.

Change Starts With You.  You have to start with yourself.  Check your attitudes. Take ownership and responsibility for what you do. Improve yourself until you can take pride in your work.  Start learning again.  Never stop learning once you do. Be committed to change.

Encourage Others To Change.  I hate to sound cliché but I can’t express it any better.  Change is a journey.  There I said it.  Anyway, as you learn and improve in what you do you should try and encourage others to do the same and take that journey with you.  Show them what you learn and how you learned it.  If they follow and improve as well, then that’s a great thing. If they don’t then that’s OK, just don’t let that be an excuse for you to stop doing what needs to be done.  By the way, don’t be a pain in the butt when trying to get others to change – it’s much easier to get people to change through having a positive approach than it is by shouting and complaining and generally being a angry or sullen little developer.

Change Requires Courage.  Have the courage to challenge the status quo. Courage to ask the questions about why things are done the way they are. Courage to suggest that things need improving and courage to suggest the changes that are needed.  Courage to pressure your management to improve and change.  Courage to be a visible agent of change.

Learn From People Outside Of Your Company.  Most change in our lives comes from external sources (it’s an inertia thing) so if you haven’t talked with a developer outside of your company about how they develop then you should get yourself along to a user group or conference at some point.  If your time is precious don’t sweat it, there are a number of virtual user groups that are starting to spring up around the place that you can attend without leaving the comfort of your own home, and failing that you can just increase the number and variety of blogs you read.  Regardless of how, you need to talk to and learn from people outside of your day-to-day to get fresh ideas.

Change Your Company or Change Your Company.  I can’t remember where I first heard this one, but it’s apt.  If you start to improve yourself and change how you do things then one of two things is going to happen.  You’ll either encourage others around you to change, thus improving and changing the company you work for or you’ll grow frustrated and annoyed with where you work.  If the second one should happen then you’ve got a choice to make – stay where you are and be confined and constricted, eventually growing to despise what you do, or you can take your newly improved self and find a new job and a more suitable team to work in.  Regardless of the economic climate, good people are ALWAYS in demand.  Have the courage to make that decision if that time comes.

You might also want to have a glance at this blog post on how to change the world.

So, what are you waiting for?  Go start changing things, and start today. No more excuses.


  1. My experience is that people who write the kind of code you talk about are *usually* (but not always) the kind of people who do development as a 9-5 and really aren't interested in bettering themselves. Unless you sell it to them in a way which they see benefits them directly (ie: me! me! me!), then there's no incentive or motivation to improve, and the cycle of excuses you mentioned just keeps on repeating.

    It's actually a real shame, but that's the reality of my experience.

  2. I think quitting is a really underrated move these days. The only way we're gonna start to change things for the better is if we vote with our feet and walk out the door.

    Seriously, if all the good developers in shitty work environments quit we'd solve most of these problems over night.

  3. @dave Well, I don't think it would solve all the problems. It would just concentrate them all in fewer places :-) [which isn't a bad thing by the way]

    @xerxes I think you are seeing are the symptoms of bad teams and environments. They don't feel like improving because when they do they get shot down for it by the lazy ones who don't want others to look better than them. The good people in those teams are the one's who need the courage to either stick it through and create some genuine change or to kiss that team goodbye and leave for greener pastures.

  4. Does this come under the banner of "professionalism"? I.e. if your environment is such that you feel forced to lower your standards (and hence act "unprofessionally") maybe your best option is to get out?
    It's hard to define professionalism in this industry however!

    On the testing front, how do you write proper unit tests if the rest of your team is writing untestable code? It is very difficult.

  5. I would say the biggest thing you missed in your "things to consider" list is:

    "Putting in an extra 8-16 hours a week of unpaid over time".

    Because that, unfortunately, is the only way that 95% of people will ever be able to demonstrate the change they seek.

    Because most of the time we work for companies that have no interest in improvement. No budget outside of the project. No concept of what software even is.

    It's easy to write a couple of lines about courage and encouragement, when you are working for a company that gets hired to bring change. You realise that consultants get listened to way more than intenal staff that could tell them exactly the same thing? It may seem that your advise is taken up because its right. But a lot of the time its because you ARE external.

    I promise you if you were dumped into most internal development jobs out there you would find changing your company was the only option.

  6. The problem is Richard, that genuine change takes time. I would say YEARS in fact. At which point you have to ask yourself "Why bother breaking my balls for years, for a company I don't care about?"

    When instead I could try out 4 other companies in the same time and perhaps find the change I seek there?

    It's definitely tempting - I've tried. Mind you I haven't found that change yet ;-)

    Anyway I reckon most of these attitude problems are much deeper than simple "change you seek" mantras - its all about modern society and big business where everyone is disconnected from any authenticity. Perhaps I have better save that rant for a post of my own ;-)

  7. Richard, I would like your advise on how to affect change in the following scenario:

    - First day at the company, no PC, no chair, no phone.
    - Find out there are no development servers
    - There is no "budget" for development servers until next quarter
    - There is no budget for development software. Developers are told to 'share' licenses.
    - The company uses a database system that is 15 years old, and its the only one you are allowed to use. And its shit.
    - To get anything into production you need to fill in 4 forms in triplicate with initials by directors who know nothing about the code. If you make a typo, it gets rejected after getting 95% of the way there. To resubmit you have to type it all in again. By hand.
    - At same said company, mission critical apps are missing source code.
    - YOU MUST DELIVER ALL FEATURES IN THE STATEMENT OF WORK, ON TIME AND TO BUDGET (knowing full well its impossible - do we suddenly become the change we seek by becoming lawyers?).
    - IT infrastructure is managed by a horizontal group (for "efficiency"!). Software never get upgraded because project teams would have to pay, even though everyone would benefit. Therefore its never updated. And you need it on your project. And you don't have time to reorganize the structure of 5000 employee company. On top of building software.

    These are just a few of the typical challenges developers find in the workplace. In fact I have found all of the above plus about 5x more in only my two most recent jobs.


  8. @Intramper Maybe not professionalism. Maybe just personal pride. And even though no one else writes tests, doesn't mean you can't.

    @Jack Before doing this consulting thing I worked in jobs dealing with internal systems. For many years. That didn't stop me from trying to change things. Some of those battles I won and others I lost, but I always wanted to see improvements. And even so, regardless of the company you are in, you can always improve yourself. If you put in those "8-16 hours" to improve your own skills then what would happen after that?

    @Anonymous1 Yes change can take years, and if it's a company you don't care about I can understand your sentiments exactly (excuse #4). So what to do? Find something you can be passionate about and if that involves changing company then when interviewing remember that they are just as much under the microscope as you are. I remember one interview where I had a potentially great job lined up but when I thought about the stuff they were doing all I could come up with was a yawn. I turned that job down.

    @Anonymous2 Wow! You hit the dysfunction jackpot there! I've got to admit that confronted with all that I'd run for the hills and not look back!

  9. Have you ever written code. If yes then you will know why. I hate whingers.

  10. 1. They were probably not high payed employees.
    2. They were never shown how to write tests, they can learn it when there would be a good tutorial available somewhere. Not only theories with a never ending story. Missing practical examples on 99% of the tutorials, no relations to real world scenarios.
    3. As couple of others said begore, there are no deployment server(s) or even deployment rules present.

    This are far relevant scenarios than you live in I suppose


  11. @anonymous (aug 24) That's a fine list of excuses you've got there, though I'm not sure how pay scales is a drag on a desire to improve. If anything I'd think it would encourage people to improve so they can ask for more pay.

    As for the other two excuses... I feel your pain, but I have to ask: what are you doing to change it? For example, have you looked at Test Driven Development in Microsoft.NET or Test Driven Development by Example both of which contain great examples of how to learn to write tests. Or have you tried to get someone in to do mentoring to help improve your skills using your code base? Or have you requested new deployment servers or put in place something to help with deployment rules?

    As I said, if you want the situation to improve then it's up to you. Don't just make excuses, do something about it.

  12. There will always be varying degrees of challenge, so you always need to be striving for improvement that's proportional to the obstacles.

    Only having a few years experience in the industry I fight for any and all levels of improvement. Small wins will keep you motivated to keep fighting for bigger and better improvements. Otherwise you feel crushed and can barely drag yourself out of bed in the morning.

  13. @richard I'm not saying that improving my skills is not important, everytime I can or have time I do it. But being focused on the project I can't afford it to spend that amount of time that is needed to properly learn all the stuff for e.g. testing. I know it should have been learned in the school, but in my case I grow up in a procedural programming 'communistic' world (:p) where testing , deploying etc. was not involved in the learning process. I had to learn everything from scratch no teachers nobody to discuss with (unfortunatelly I'm the only developer in the couple of last projects), with a limited budget and so on.

    The last few sentences were a little bit out of scope :), sorry for that pain :). I think this is not the forum to discuss these things.

    I don't have any problems using or writing these test. I only miss 'use case' tests with real world scenarios. So my tests are mainly focused on prepopulating data and automatic use case tests on it. As the only developer I have to do everything, and I know well that this is often the case where I came from originally. The other part is planning software and services is also important, but it's not discussed here either.

    @nickjosevski, I like challanges very much but I miss all this to have learned in the school, just the basics. All this stuff should be part of a programmers (early) learning process, and this is still not the case in many east european schools courses. I'm tired to fight for a 'bigger - better' world, the reality show me that not everything is made of gold.

    My pain is big but become a better programmer since I spend more and more time making tests.

    It's time to spend some time with the family. :D

    b.r. Sandor

  14. Great Post !
    Would be a pleasure to work in any team if more people would show an attitude like this.

    It's tough to work with depressed programmers. It goes also with the attitude of looking to "how can I solve the problem?" instead of "That's not of my concerns". Even when we talk about development servers budget.