Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I consider myself an agile developer, I have set up CI in the last three teams I have worked with, and in my previous role worked in a style which revolved around writing failing tests before fixing bugs, extremely short feedback cycles (typically starting UAT of new features within a couple of days), and a very short release cycle.

Now I find myself the only person to write a C# unit test in the last 6 months, battling inertia to improve code quality, and supporting a system in which new features are just released with the intention of fixing them later.

What tricks can I employ to try and stabilise things? I have tried setting up CI, automated UAT deployment from a separate branch in source control, and publicising local free talks on software development, but with little success.

share|improve this question

migrated from stackoverflow.com Aug 20 '11 at 19:56

This question came from our site for professional and enthusiast programmers.

add comment

4 Answers 4

You cannot give "The Process" on people and expect they to follow blindly.

The best way I could think of is this - try to take "ownership" of some the harder parts of the project. And if you development process consistently yields better results it will not go unnoticed and people will come asking and listen.

That is how I managed to change things a bit in my current workplace.

You have to introduce the things a bit with the wow effect that comes with encountering major improvement. Like migrating from CVS to Mercurial - holy #$%@ it can do this easily?

share|improve this answer
    
I've delivered one particular feature which was regarded as too hard to solve for the last couple of years, with a set of integration tests which I used to prove that the changes I was making would work, and the response to that was underwhelming to say the least. –  Jon Freedman Aug 20 '11 at 20:33
3  
Well if you manage to do something hard and nobody asks you how did you do it, it may seem that you have something worse. A people/culture problems. If you are surrounded with concrete heads it is almost impossible. –  Daniel Iankov Aug 20 '11 at 20:51
add comment

Sounds like a difficult situation. A couple of more or less random thoughts:

  • How much have you actually talked with your teammates about these new ideas? Changing the way other people think and do things is one of the most difficult things in life. So you need lots of communication, and time too. Who and where gave these "local free talks" you mention? If they are somewhere else in the town, it may be difficult to convince people to go there - especially in their free time. You should try to arrange talks / workshops / demos on your own workplace, or even just talk about these ideas during lunchtime with colleagues whom you find interested in learning.
  • You should gather hard data to support your cause. E.g. keep statistics of bugs caught with unit tests, and bug density in code you wrote TDD style vs code written in the "traditional" manner. With hard data in your hand, it is much easier to convince both sensible team members and management.
  • Yes, it sounds like you should involve management too. Talk to your managers about the problems you see, and the possible ways to improve things (but make sure to present them in ways management understands, e.g. "because we have no CI, we may notice broken builds only at the customer site, which causes customer irritation and extra expenses"). Also listen to their point of view. They may see the same problems from a different angle, or may be completely oblivious to them, due to company cultural issues. In the former case, you may make them your allies, and together you can manage to move the development team and process towards a more agile, quality oriented approach. In the latter case, without management support, alone in a team of jaded developers, you have close to nil chance of success, so it may be better to start looking for greener pastures...
share|improve this answer
    
Talks are normally hosted by skillsmatter here in London, but most of them are recorded and made available online. For example I found John Smart a good speaker when talking about testing. –  Jon Freedman Aug 20 '11 at 20:59
add comment

You need to get some level of management buy in. While some people will want to write better code just because, that does not sound like the culture there. This is going to take some level of change from the top, like rewarding delivery of code that doesn't intrude 10 new bug requests, etc.

Sometimes you just have to realize that you are better off somewhere else (and maybe so are they).

share|improve this answer
add comment

One the problem in any new technique that the one didn't used to do is resistance to change, try do offer them something interesting as some kind of challenge, try introduce to them something that will impressed him like Dev Magic Fake on CodePlex :

http://devmagicfake.codeplex.com/team/view

This framework will save any object and retrieve it without any needed code and will give you the ability to write unit test and TDD and UI test without write the underline layers

My last advice, some people didn't believe in talks, they have to see the project success to follow you, so you may need to work harder to get them believe.

Thanks

M.Radwan

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.