Coworkers don't seem to care about best practices [closed]

Question

I am a member of a 6 person team of software engineers within a 400 person department at a fairly well known company. We are responsible for the business applications our department uses, both third-party and custom asp.net tools we write. The group has been around since 2006ish and I joined in 2011. I have been trying to introduce best practices(soc, solid,dry,unit testing,etc), but i get from about half that they simply dont care. Since as a group we should all follow the same process, should I just give up promoting this stuff and go with the flow? Every meeting we have discussing this csn get a bit heated. I am getting to my wits end.

Answer 1

soc, solid,dry,unit testing,etc

Trying to introduce multiple new practices, against resistance, will usually fail, and, in your case, has.

Pick one, whatever you think would be simplest to implement and most obviously useful. Probably DRY or unit tests (YMMV). Next time you are working with a colleague on a new feature or bug fix, try to work in the new practice.

This may still fail, but little steps often work better than huge leaps.

Answer 2

... a 6 person team of software engineers ... around since 2006ish

I would assume that staff turnover has been low, resulting in a Team that is keenly in tune of its own Product; well experienced in the stuff they work with.

As such, they probably don't feel the need for any of these [good] things. They know what they're doing. Of course it probably means lots of repeated, messy code but that's fine because they do [actually] know what they're doing.

I would ask what the level of Documentation is like ... but I suspect I already know the answer.

This is actually a good place for the Company to be.
Their Development team knows understands they're doing and they work quickly and effectively (I assume), even if it's not in the "Best" way.

However, the Team's attitude is short-sighted.
When someone leaves the team, for whatever reason, it will suffer hugely because of the loss of a significant proportion (1/6) of that Domain Knowledge. At that point, changes will become more fragile, introducing more bugs because of the lack of a testing framework/ mentality.

Answer 3

Go with the flow? You are unique, don't dump your best practices for them to drag you down to their level of performance when it comes to Software Engineering. I would recommend you continue to do your best and express your opinions about the choices and changes that your team makes, but don't get to the point to where you lose productivity in meetings by "heated" exchange.

In the interim, I would continue to improve my developer skills while looking for a company that I may be a good fit for. There are companies that are passionate and care about the output of their work. On the other hand, there are companies that could care less. I am passionate about what I do, so the company I work for would also have to be passionate, not only in Software Engineering, but the services they provide to customers.

Answer 4

Bear in mind that "Best Practices" is a rather loose term that largely depends on the software product. The best practices for developing "shrink-wrap" software vary quite a bit from those for an in-house software team writing line-of-business apps for the larger company or department.

Perhaps you should step back a bit, and find out if the push-back you're getting from your coworkers isn't simply a case of you emphasizing the wrong set of best practices.