Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
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 6 '12 at 19:04
12  
Welcome to software development! –  Yannis Rizos Jun 6 '12 at 19:05
    
@YannisRizos, no no no! ;) –  Rotian Jun 6 '12 at 19:06
3  
@Rotian This is almost required reading: 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 6 '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! –  Uncle Mikey Jun 6 '12 at 20:28

2 Answers 2

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.

share|improve this answer
    
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 6 '12 at 19:35
2  
+1. Be the change you want to see in your team. Set the standard. –  Scott Wilson Jun 6 '12 at 19:43
1  
+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 6 '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. –  Uncle Mikey Jun 6 '12 at 20:42

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.

share|improve this answer
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 6 '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 6 '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. –  Uncle Mikey Jun 6 '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 6 '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 6 '12 at 22:34

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.