Software Development – When to Drop Principles for More Money?

agilesdlctddtestingunit testing

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…

Best Answer

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...