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'd like to throw this question out there to interestingly see where the medium is.

I'm going to admit that in my last 12 months, I picked up TDD and a lot of the Agile values in software development. I was so overwhelmed with how much better my development of software became that I would never drop them out of principle. Until...I was offered a contracting role that doubled my take home pay for the year.

The company I joined didn't follow any specific methodology, the team hadn't heard of anything like code smells, SOLID, etc., and I certainly wasn't going to get away with spending time doing TDD if the team had never even seen unit testing in practice. Am I a sell out? No, not completely... Code will always been written "cleanly" (as per Uncle Bob's teachings) and the principles of SOLID will always be applied to the code that I write as they are needed. Testing was dropped for me though, the company couldn't afford to have such a unknown handed to the team who quite frankly, even I did create test frameworks, they would never use/maintain the test framework correctly.

Using that as an example, what point would you say a developer should never drop his craftsmanship principles for the sake of money/other benefits to them personally? I understand that this can be a very personal opinion on how concerned one is to their own needs, business needs, and the sake of craftsmanship etc. But one can consider that for example testing can be dropped if the company decided they would rather have a test team, than rather understand unit testing in programming, would that be something you could forgive yourself for like I did? So given that there is something you would drop, there usually should be an equal cost in the business that makes up for what you drop - hopefully, unless of course you are pretty much out for lining your own pockets and not community/social collaborating ;).

Double your money, go back to RAD? Or walk on, and look for someone doing Agile, and never look back...

share|improve this question
17  
Dude, have you been brainwashed? Don't be stupid and take their money. Sell-out? What are you nuts? If you feel guilty, you may share half of your extra earnings with me. With extra $ you can buy a house sooner, and thus make sure that you have a passive source of income (rent) - that is what I would do. That way you can afford to be capricious and set your own terms more often. –  Job Feb 6 '11 at 5:00
    
To me the answer depends on at least two factors: 1/ do you like the job (&people) despite this flaw? 2/ do you have an alternative that would satisfy you more? At the end of the day, what would make you happier in your life? Different people will have different answers. –  asoundmove Feb 6 '11 at 5:43
1  
It came down to it being a new place so there is always an element of learning, just maybe not for long. The buying of a house was the biggest win for me, even if I do this for a year and move on for something longer term where the processes are right etc. You're right Job, I'd have been nuts to turn it down. But the whole situation prompted me in thinking what others may have already done in their careers. –  Martin Blore Feb 6 '11 at 12:28
5  
People, nearly all of you tell him to take the money. Did it occur to you that for someone this tradeoff might be equal to a physicist being asked to build a nuclear weapon or a chemist to produce drugs. OK, bad code probably won't cause death. But principles are what defines us and our character, think twice before sacrificing them. –  Dave O. Feb 7 '11 at 2:15
1  
@Dave: it depends on the criticality scale of the project: en.wikipedia.org/wiki/Cockburn_Scale –  rwong Feb 7 '11 at 13:39

11 Answers 11

up vote 22 down vote accepted

Since I got addicted to unit tests more than 10 years ago, in the majority of my workplaces I was the first who has ever heard about these. Nevertheless I kept writing my little unit tests whenever I could, and estimating the cost of unit testing into my tasks. Whenever someone asked about my coding habits, I told what I was doing and why it worked for me. Usually at least some of the people were interested, and eventually I got to give presentations on the topic and mentored people to write their first unit tests.

You don't need to start convincing people about the agile way the first day at your new workplace. Just follow the principles in your own work as much as you can. If you do it well, you will deliver better code. If your coworkers and/or management notice it, they will ask how you do it. Then you can tell them.

Update

Most of the seasoned developers (and managers) have seen trends and fads come and go, so they do not get excited by the latest buzzwords. However, if you can demonstrate that a certain approach (tool, way of thinking) really works in practice, in the actual project, the ones who care about their craft will almost surely sit up and listen. But if you have no such people in your team, maybe it is time to look for a better place...

share|improve this answer
    
Thank you Peter. Nice to know you've experienced this kind of thing before and I will surely take your advice. –  Martin Blore Feb 6 '11 at 16:11
1  
+1 That's an excellent strategy - awesome. –  JBRWilkinson Feb 6 '11 at 18:03

Never drop something that will get you unhappy in the long run. Off course, you can start in no-mans-land and try to get the team move in your direction. If you're willing to put the effort in it and the job's worth it, this can even be an interesting challenge.

But if you have to leave the very things that keep the pleasure in coding (or any job for that matter), my experience is that you'll walk away sooner or later. I learnt that frustration should never be underestimated...

share|improve this answer
4  
+1 "I learnt that frustration should never be underestimated..." - too true. Long running frustrations are definitely a job killer. –  Martin Blore Feb 6 '11 at 1:04

This is where I think all developers should also know a little bit of project management. Everything is a trade off between time, money, and resources. Consider yourself the resource.

In my 12 years of programming I don't think I have ever completed a project and thought of it as done, or complete in my mind. There was always something I wished I could have done better, or cleaner. It took me a very long time to realize that this is because of those trade offs.

So if you are thinking about switching jobs just because the methodologies are not there, I would think again if I were you. These trade offs are constant and apply to all software developers. Even the most dedicated game developers wish they could do some things over again, or practice a different methodology again if they had a chance.

I would say you should look at your agile development practices and realize that you can do that even on a micro level. Sure your team mates might be off in la-la land doing whatever they want, but your personal satisfaction will be greater and you will most for sure generate better code than them in the long run. Then when the manager comes and asks why your code is so much better you have your chance to convert the team :)

But if you don't like the people, or the job then I think you know the answer already. But I highly doubt anyone will walk in the room and tell you not to use agile development principles while coding... if they do... run screaming.

share|improve this answer
1  
+1 for mentioning of PM, and the 3 factors. –  mauris Feb 6 '11 at 2:18
    
s/resources/quality/g = time and money qualify the resources. The actual balance is time, cost and quality. In other words: I can do it quick, I can do it well, I can do it fast, pick any two. –  asoundmove Feb 6 '11 at 5:41

Just make sure working with the new team is a good investment of your time.

Perhaps they work in a more efficient manner than you're encountered thus far? If so working with them will be a great learning experience for you (hence a good investment).

On the other hand the new team's methodologies may be of little value to you (too much "cowboy coding" etc). In that case the additional money probably isn't worth it (unless it's a pre-IPO start-up or something extraordinary). You probably won't learn much... and you risk burning out.

share|improve this answer

The people at your last job already knew about TDD, SOLID, etc. That's great. I'm sure you enjoyed working there and learned a lot. Now you have an opportunity to teach those concepts (while making big bucks at the same time). In my experience, having to teach someone else a concept has always helped me to learn it in even greater detail myself. Just be patient with them, and keep pushing your concepts one at a time. When you get frustrated, go home and count your money. Or look for support on SE.

share|improve this answer
    
Very supportive answer Marcie, thank you. –  Martin Blore Feb 6 '11 at 15:14

I want to quote a former colleague of mine. He said, whenever he is looking for a job, or a part time project, there are three criteria that the project must meet:

  • It must be fun to work with
  • It must be beneficial for your competency development (not sure this is the right way to phrase it)
  • It should pay well

As I read your question, this project only satisfies the last criteria.

As you have grown fond of TDD (just as I have), I think that you will go around on a daily basis and wish that all your coworkers had reached the same insight as you have. So the first criteria would probably not be met.

Secondly, if you want to pursue TDD projects, and perhaps getting more experience with building agile teams, then working on this project is not going to help you strengthen those skills. Therefore the second will probably not be met either.

So personally, if I was in you position, and I was not in a position to help introduce TDD into the company, I would look elsewhere.

share|improve this answer

I must admit I'm a b*tch in that regard. As a freelancer, whatever the client regards as the right methodology for the project, is ok with me. That doesn't mean that money is the only thing I care about, but the decision about what to do and what to leave out is up to the client. I would not accept bad working conditions (loud, long hours etc.), though.

share|improve this answer

Never.

Life is too short (especially as you get older) to do things you're going to hate.

Of course, it does make it harder to change jobs, and there are less places to work.

But at least only the legacy code smells bad. (And I have autonomy, so we can do sensible things like spend a week eliminating compiler warnings from the legacy codebase....)

share|improve this answer

I would not work somewhere that didn't allow me to work the way I wanted. By that I mean that I don't want to be micromanaged.

I work under the assumption that I am good at what I do, and if you give me some tasks I'll get them done efficiently and effectively. How I implement them, provided I don't break your code guidelines and patterns, is up to me. That's the fun part of my job.

If I wanted to unit test every class I write then that might be an issue, but writing unit tests generally is fine, provided I still meet deadlines. I expect that a TDD proponent would argue that writing unit tests actually increases productivity (later on, etc). If I were in your shoes, I'd write some unit tests which will save me some time down the track (presumably less bugs, easier fixes). If you reinvest that time saved into more tests, then it will compound into even more time saved and eventually you can sit back with a big smile when you have an awesome suite of tests, and can easily check your code changes when some new 11th hour requirement comes in.

If I couldn't do that, then I don't know if I'd want to work there.

What I am saying is that I think there should be give and take in these matters - a bit of negotation. The more they pay me, the less non-monetary niceties I expect. But I always need a level of autonomy and self respect, especially when there's no need to refuse. I'll drop any other principle as long as I have that bit of autonomy. After all, what might seem like some backwards crazy methodology might be the best thing you have ever done!

share|improve this answer

In short, development methodology is not part of you. It is not a relgion and it is not who you are. It is a tool. Do what you are told, how you are told and make the extra bucks. Thousands of systems were developed and are running today without TDD, Code Smell, etc. In few years no one will know what these terms mean because methodologies come and go more frequent than a city bus. Work hard as you are told and take the money it is appreciated any time and all the time:)

share|improve this answer

Your methodology should not be your principles, your principles should be quality or product related -- secure, reliable, performant, or promotes a healthy lifestyle and is good for the environment or whatever you are concerned with.

Methodologies are great, they can help you get the job done faster and easier, helping to ensure that you end up with a good maintainable product when you are done. But they aren't the product and whether you think of what you do as craft or art, that is what you should focused on.

Badly applied a methodology can be worse than a "just do it" mess, as you end up with the same thing but spending more time not working on getting something done, so its not a silver bullet that guarantees quality.

That said, the methodology is just as much a part of the work environment as the location, platform, language, monitor size, co-workers and the purpose of the product -- it's not unreasonable to consider it when evaluating a company.

share|improve this answer

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.