13

I joined a dev team of six two month ago. People are nice, all is good. But more and more I observe an ad-hoc mindset. Stuff gets quick fixed, at the cost of future usability, there is little testing and two people happily admitted, that they like to carry the knowledge around in their head, rather than to write it down.

How to deal with this? I'd like to lead by example, but time is limited - I like architecting and actually implementing the stuff. But I'm afraid the ad-hoc mindset infects me and rather than striving for clearness and simplicity in design and code - which isn't simple to establish - I get pulled down the drain of an endless spiral of hacks on hacks - which no outsider can uncouple - just for schedule's and management's sake.

gnat
  • 20,543
  • 29
  • 115
  • 306
Rotian
  • 131

2 Answers2

10

You already know part of the answer: you need to lead by example. You also need to become comfortable with the fact that your "leadership" might be ignored, that your colleagues will continue to do things the way they've always done them -- either because it makes the boss happy or because they themselves value expediency over long-term maintainability.

In the end, you need to let your results speak for themselves. Did you miss a deadline by three days but save the QA team at least that many scheduled days of testing because you test-drove your development and it largely works as designed? That's a win.

In the end, however, if you don't have at least some degree of management buy-in for that sort of trade-off, you're simply in the wrong environment, and need to find one more conducive to good practices. Bad practices are habit forming, so the sooner you can either find a way to stand your ground, or change to a working environment with better practices, the better.

Michael Scott Shappe
  • 201
1

Nothing?

I mean, business time constraints exist. Yours might be a scenario where time to market is more valuable than future ease of use.

If you are a rank and file programmer, then setting standards and concerning yourself with product architecture is not really your job (especially 2 months in). You should strive to improve the product however you can (including culture change), but not at the expense of alienating your team and/or boss. Being the new guy who thinks he knows better is a quick and easy way to do that.

I would ask why you're doing all of these quick hack fixes? Is it due to previous quick hack fixes? It's easy enough then to point out that if things were done 'right' in the first place...

In the end, bad programming practices lead to concrete pain. If people think they won't, all you need to do is wait.

Telastyn
  • 110,259