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
  • 21,442
  • 29
  • 112
  • 288
Rotian
  • 131
  • 2
  • 1
    I suggest a drop kick to cause a lack of ability to retain memories. Documentation is essential for any long lived system...even if it isn't formal. – Rig Jun 06 '12 at 19:04
  • 14
    Welcome to software development! – yannis Jun 06 '12 at 19:05
  • @YannisRizos, no no no! ;) – Rotian Jun 06 '12 at 19:06
  • 4
    @Rotian This is almost required reading: http://www.joelonsoftware.com/articles/fog0000000332.html. A bit outdated, but still a great resource, and probably worth as an answer on its own. – K.Steff Jun 06 '12 at 20:09
  • More broadly, I recommend "Uncle Bob"'s /Clean Code/ and /The Clean Coder/. I don't agree with everything he says in those books, but they're very good food for thought. They certainly opened *my* eyes quite a bit! – Michael Scott Shappe Jun 06 '12 at 20:28
  • @K.Steff - I read the linked essay by Joel Spolsky - and it fits. Thanks! 1) attempted 2) no 3) tried once, will try again 4) not an issue 5) I do 6) can't really relate to that. I read not long ago, that you should create something you could be proud of (technically and in a business sense) - and that's my guiding star atm. – Rotian Jun 06 '12 at 22:48
  • Possible duplicate of [How to deal with too much pragmatism in the project?](http://programmers.stackexchange.com/questions/189073/how-to-deal-with-too-much-pragmatism-in-the-project) – gnat Apr 13 '16 at 21:55

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
  • 3
  • I appreciate your answer. I guess you know my environment quite well - I'll try to work harder - and if I don't get a roll - I'll look around for something else. – Rotian Jun 06 '12 at 19:35
  • 2
    +1. Be the change you want to see in your team. Set the standard. – Scott C Wilson Jun 06 '12 at 19:43
  • 2
    +1 for letting results speak for themselves. That combined with leading by example is the best way to affect positive change. People naturally want to do a good job (most, anyway), and if they see someone getting results better than theirs, they're likely to ask for the secret. And they're a lot likely to listen when they're asking of their own volition than if they're being told, unsolicited. – Erik Dietrich Jun 06 '12 at 19:46
  • @Rotian Not your specific environment, of course, but yes, I've been there, and I've done that. The worst part was, at the time, I didn't even entirely understand how bad it was. I only knew something was subtly wrong at a deep level, and eventually decided that was enough to get out. It's only in recent years that I've been able to point to specific practices they should (or should not) have been doing. – Michael Scott Shappe Jun 06 '12 at 20:42
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
  • 108,850
  • 29
  • 239
  • 365
  • 1
    As far as I understand, the problem is not these people make ad-hoc fixes due to time constraints. The problem is that they don't see it as a technical debt that should be repaid sometime in the future. It's like jumping: you can get by without the support of the Earth for some time just fine, but you better be prepared to land. – 9000 Jun 06 '12 at 20:10
  • @9000: the OP says it's for schedule and management's sake, so I'm guessing (hoping) that it's mostly time pressure. Underestimating the actual work involved in software development isn't exactly uncommon. – Telastyn Jun 06 '12 at 20:15
  • 1
    I agree that bad practices lead to concrete pain; but concrete pain does not always lead to the changes you would expect to see in a rational world. From experience, I can tell you that managers exist who will not learn from that pain and not come to encourage the right practices. They'll just keep on muddling along, because to do otherwise would require standing up to THEIR bosses to advocate for spending time to do it "right", which they're not always prepared to do. – Michael Scott Shappe Jun 06 '12 at 20:31
  • @UncleMikey: Of course. But if your managers are too ineffectual to schedule things appropriately, there is very little you can do. – Telastyn Jun 06 '12 at 20:34
  • @9000 and Telastyn - yes it's both I think - a certain ignorance about the fact that a thing like technical debt really exist combined with an environment that encourages workarounds for various different reasons (be it time, habit, etc.). – Rotian Jun 06 '12 at 22:34
  • @Telastyn, thanks for your answer. I don't feel that alienated - but a little yes. In my *limited* view of course - I am focused on business value: give my bosses more insight in the processes they are governing - just that they don't seem to care so much I thought they would. – Rotian Jun 06 '12 at 22:40