At what point would you drop some of your principles of software development for the sake of more money?

Question

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

Answer 1

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

Answer 2

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.

Answer 3

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

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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

Answer 8

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:)

Answer 9

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.

Answer 10

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!