5 things programmers preach but don’t practice

Posted on
August 30, 2011

by
Avdi Grimm

I’m having a frustrating day of merge hell. Just to blow off some steam while specs run, here are some things that, in my experience, are a lot more common in theory than in execution in proprietary software development projects. At least in the Ruby/Rails projects I’ve been exposed to lately.

Not pointing fingers or anything, I’m as guilty as anyone of not putting my foot down and saying “we aren’t moving another inch until we clean house”. Or, for that matter, of writing about practice ideals while consulting on projects that are far from those ideals.

Just to reiterate, this is anecdotal. If nothing here rings true for you… great!

Test-driven design. You’re lucky to find a shop that practices test-driven development consistently. Test-driven design is a concept that most programmers still don’t really grasp, in my experience. Behavior-driven design, where the focus is on stating behavior up front rather than on verifying implementation? Forget it. Also, nobody is testing their Javascript.
Refactoring. What most shops call “refactoring” is really a month-long timeout for software refurbishment every year or so.
Scrum. It’s apparently hip to say “we do Scrum” now. 99% of the time this means “we do daily standup meetings”.
DVCS. Git or not, most projects are doing centralized version control with periodic merge hell.
Continuous Integration. Sad but true. I can’t tell you how many times I’ve heard “we had a CI server at one point, but…”

Did I miss anything?

This entry was posted in Rants and tagged bdd, refatoring, Revision control, scrum, tdd, Test-driven development. Bookmark the permalink.

http://twitter.com/elight Evan Light

Can’t argue any of those.

Though, technically, the only people doing “Scrum” have some over-priced certified Agile Alliance™ weenie on their team. Pass!
- http://avdi.org Avdi Grimm
  
  I keep telling people, if you have someone on your team whose job description is “scrum master”, yer doin’ it wrong.
  - http://twitter.com/le_gars Tim Romberg
    
    “I keep telling people, if you have someone on your team whose job description is “scrum master”, yer doin’ it wrong.”
    
    In what sense are they doing it wrong? I agree with @Evan that having the Agile Alliance “stamp” on can give warning signals. Thanks for a great site!
    - http://avdi.org Avdi Grimm
      
      My understanding of the role of Scrum Master–as well my experience of software projects–says that it should be treated as a “hat” that can be worn by different people. Certainly they should understand the responsibilities of the role, but their entire career at the company shouldn’t be dedicated to Scrum Mastering.
      - http://twitter.com/le_gars Tim Romberg
        
        I understand what you mean. During my education we often worked on small projects for school and tried rotating the role as a Scrum master. I found this strategy to be good. Although I’ve seen companies that have one “dedicated” Scrum master that’s not a developer. I’m not sure when it comes to this. For me the role of Scrum master has always been one of the developers that instead of coding full-time, dedicate an amount of his or her time to “attend” the process. Make sure that the rest of the team can work, almost, without distractions, and value the individuals and the dynamics within the team. Though my experience is limited and I’m still “learning the ropes” as they say. I would like to add though that for me the focus here is context, meaning that sometimes maybe it is right that the Scrum master “only” works with that.
- George X
  
  I think you mean “Scrum Alliance™”. The rest I can’t argue with.
Anonymous

Selenium tests were usually the first thing to go away on projects I’ve worked on. So hard to keep running, especially in CI. And they are slow, and who knows how much value they actually provide…

The other thing that seems to be hard is maintaining adequate customer involvement. But I imagine you’d want to do a whole other post on that.

Good luck!
- http://avdi.org Avdi Grimm
  
  GREAT point about customer involvement.
- http://twitter.com/elight Evan Light
  
  My experience, in a nutshell: a large number of customers don’t want to be involved. They want to pay me to make the problem magically go away — without working with me to adequately define and scope the problem.
  
  After trying to get them involved, those are ultimately the customers that I wind up getting rid of.
- http://railscasts.com Ryan Bates
  
  Regarding slow selenium tests, I’m loving the headless webkit solutions out there. Try capybara-webkit and jasmine-headless-webkit.
  - http://avdi.org Avdi Grimm
    
    They are nice, aren’t they?
    
    EDIT: Although my OS X-using compatriots have been doing a lot of whining about them being “hard to install” or some such :-P
http://twitter.com/colin_jack Colin Jack

Again though, none of this is Rails/Ruby specific. In .NET land its all the same.

On TDD I think you get the same as you mention for CI “we had tests but they kept breaking so….”
- http://avdi.org Avdi Grimm
  
  So true about TDD. :-(
- http://avdi.org Avdi Grimm
  
  So true about TDD. :-(
http://railscasts.com Ryan Bates

Thanks for the post, I’ve been guilty of some of these points. There are two tools that have helped me recently with some issues you bring up:

One is Travis CI. If you have an open-source project, go try it: http://travis-ci.org

The other is Jasmine which really helps testing JavaScript. If you’re writing JavaScript and haven’t tried Jasmine, do it: http://pivotal.github.com/jasmine/
- http://avdi.org Avdi Grimm
  
  I’m eagerly awaiting the Travis for closed-source programs. Having been involved in a hosted CI-ish product in the past (devver), I’ll be interested to see how they overcome the difficulties. IME closed-source stuff is a whole ‘nother ballgame: the projects that need you the most are the ones that have the most difficult to duplicate, highly specialized setups for their CI.
  
  As you’ll hear if you listen to Ruby Rogues, I’m definitely all aboard the Jasmine train! Very happy with that project.
  - http://twitter.com/godfoca Nicolás Sanguinetti
    
    Hosted CI is hard. It’s something RunCodeRun experienced. It’s something I figured before investing too much time or resources in FixTheBuild.com.
    
    The best bet for Travis for closed source projects is, IMO, that they make it easy to install on your own architecture so you can configure build agents to fit your needs without much trouble.
http://twitter.com/jwo Jesse Wolgamott

I think most teams could do better at DVCS (the git branching model http://nvie.com/posts/a-successful-git-branching-model/)… More often than not, I see teams commit straight to master rather than feature branches (or even committing to dev). So: I don’t see periodic-merge hell, but I do see the inability to hot-fix what’s on production.
- Marius
  
  We solve this by hiding in-dev stuff with properties. We only do feature branches for bigger features. Feature-branches don’t necessarily save you from merge-hell either.
http://twitter.com/jwo Jesse Wolgamott

+1 on TravisCI and Jasmine… and if you’re closed source, Jenkins is great and tests rails projects (rspec/cucumber and test/unit) with ease. We connect to campfire for notifications.
- http://avdi.org Avdi Grimm
  
  You really have to connect it to something, otherwise it just sits broken.
http://www.20spokes.com Ryan Fischer

Spot on. My last company would preach agile and everything else known to mankind. It got to the point of ridiculousness where clients were taking the hit with bloated costs to make up for these failures. I am now starting my own company and switched from Java/Spring MVC to Rails. Plus svn to Git. TDD has been one of my main points with how I work and not only does it truly save time but helps prevent royally f’in something up for a client.
- http://avdi.org Avdi Grimm
  
  It’s amazing how meaningless “Agile” has become.
  - http://dool.in Dave Doolin
    
    Being too old to be “agile,” I suspect as I continue blithely along writing the best code I know how (however poor that may be) it will put me right back in the avante garde. Probably half of what I read about “best practice” in Rails (or anything else) was covered by the Indian Hill Style Guide… in 1990… to about the same effect.
    
    Agile and great code isn’t a causal relationship. It might (or might not) correlate well. But it’s not causal.
http://www.20spokes.com Ryan Fischer

Spot on. My last company would preach agile and everything else known to mankind. It got to the point of ridiculousness where clients were taking the hit with bloated costs to make up for these failures. I am now starting my own company and switched from Java/Spring MVC to Rails. Plus svn to Git. TDD has been one of my main points with how I work and not only does it truly save time but helps prevent royally f’in something up for a client.
Wagner Andrew

Also, if you’re “doing continuous integration”, but you’ve had broken builds for a month, you’re doing it wrong.
- http://avdi.org Avdi Grimm
  
  Indeed.
- http://ekenosen.net/nick nicholas a. evans
  
  Agreed. Also, if you’re “doing continuous integration” but also have to deal with merge hell because your branch hasn’t integrated with master for a week, you’re doing it wrong.
http://twitter.com/jr_plusplus Julian Russell

I think if you broaden the post to software companies you could include:

6) Pay anything like the bonus scheme they offer
- http://avdi.org Avdi Grimm
  
  Oh dear.
http://twitter.com/jr_plusplus Julian Russell

I think if you broaden the post to software companies you could include:

6) Pay anything like the bonus scheme they offer
http://twitter.com/ZsoltFabok Zsolt Fabok

+1, we keep retrospective meetings for continuous improvement. This means that someone got a bunch of action points which will pile up
http://twitter.com/ZsoltFabok Zsolt Fabok

+1, we keep retrospective meetings for continuous improvement. This means that someone got a bunch of action points which will pile up
Anonymous

I’ve been using JetBrain’s TeamCity CI server which is free for up to 20 projects. I use it on Rails applications and it was pretty easy to setup.
http://smartic.us bryanl

How have you accomplished the above list? How have you failed?
http://www.solidsyntaxprogrammer.com Jerod Houghtelling

“I’ll come back and clean that up, later” — which means never!
Natebkirby

Yes, you left out ‘Understanding requirements before they start coding’.
http://twitter.com/wlangstroth Will Langstroth

So true. *tear*
http://twitter.com/wlangstroth Will Langstroth

So true. *tear*
http://profiles.google.com/david.adsit David Adsit

I would add Paired Programming to the list.
“We pair so that we don’t have to bother with code or test reviews. Only not all the time; never for the non-critical code, just the tricky stuff. And only when we aren’t on a deadline, ’cause who can afford the time it takes when there is a deadline?And only when the stories I committed to are already done. And only during a lunar eclipse…”This is usually on teams who talk about the importance of pairing as a means of transferring knowledge. And teams with insecure developers who are afraid others will see their code. And teams where the developers are arrogant and “don’t need any help on [their] stories!”
- http://avdi.org Avdi Grimm
  
  Hehehehe. Very true.
- http://altbit.org Christopher M. Hobbs
  
  Sometimes management doesn’t agree with pairing. They see it as a waste of time and prefer the divide and conquer approach. In small companies, it can be hard to push an idea like pairing through when the bosses don’t understand or care for the practice.
Anonymous

You should probably quit your job.
- http://avdi.org Avdi Grimm
  
  Did you read the whole post? I’m a consultant. I see lots of people’s codebases.
  
  If you are suggesting I quit being a consultant… well, that’s a discussion for another day, but it wouldn’t change the reality of what goes on in most software projects.
http://twitter.com/ponnappa Sidu Ponnappa

Agreed on all five counts. This is exacerbated by the fact that externally, *every* Rails shop claims to do all five.

And since you mention it in point #5 – this is the reason we’re building and using our own open source CI server; most of the existing ones aren’t much use for distributed Rails projects (or more precisely, they incur enough overhead that most people slowly stop using them after a while).
- http://fragmentedthoughts.net Adrian
  
  What is particular about a distributed rails project that a CI server such as Jenkins or Cruise Control cannot be usedcustomised for use ?
http://tersesystems.com Will Sargent

Sounds about right. I’ve yet to see the textbook implementation of refactoring done.

I’d also add “pair programming” except I don’t think pair programming is nearly as effective as people think it is.
pedro

Regarding on how meaningless has the word “Agile” become. Does anyone still remember how once upon a time there was a set of four statements called “the agile manifesto”. They were 4 statements, and it was hard to make anyone disagree with them.

Why the hell did anyone turn these four statements into books about agile development?

Why do people insist more on TDD than on those four statements?

- Individuals and interactions over processes and tools- Working software over comprehensive documentation- Customer collaboration over contract negotiation- Responding to change over following a plan

So many people still insisting on Processes and Tools over Indivituals and Interactions. Even in books about Agile Development!!! I wish that the word “Agile” wouldn’t have been used in anything beside this manifesto. I wish that all my colleagues at least knew these four statements by heart.
http://rosenfeld.heroku.com/ Rodrigo Rosenfeld Rosas

At least TDD or BDD is something I never preached about. The important thing to me is to have a good coverage of the parts that could break in some refactoring. Having said that, usually I write code first and tests just after the code is working because I do lots of code experimentation and lots of mocks in my tests, so it takes less time to me to write code first, except for some rare cases where writing the tests first would make code writing faster…
http://rosenfeld.heroku.com/ Rodrigo Rosenfeld Rosas

With regards to Javascript tests, I would you recommend participating in this discussion I started some days ago:

http://groups.google.com/group/rubyonrails-core/browse_thread/thread/22226bfc67d49f9f
http://www.learncomputer.com Michael Dorf

Most projects usually look good in the beginning. The original developer (or team) thinks through the most optimized design, clean implementation, and good test coverage. But the app starts to grow, becomes more complex, more people contribute, an “outsourced” firm from a “certain country” is brought in, and before long, the perfect “baby” soils itself beyond recognition. That’s generally been my experience. Did anyone say “RE-WRITE”?
http://fragmentedthoughts.net Adrian

The one that I would add is Showcases. The stuff that I am working on is heavy on integration and the customer doesn’t really get excited about seeing messages being passed between systems… as a result we find it difficult to get into a showcase routine, which means the UI looses out on direct feedback.

My experience is Test-driven design. Agree 100% TDD is hard… I didn’t realise how hard (and how poorly I currently do TDD) this is until I watched Uncle Bob’s clean code videos
Refactoring. This is one thing that the team that I am working in does well.. we have a stack of unit tests that allow us to refactor confidently, so we do.
Scrum. We definitely don’t do Scrum or Agile or Waterfall… closest I can guess is it would be called plain old iterative development , with the problems that implies… distance between dev teamcustomer and requirements defn out of synch with development.
DVCS. Git or not. Currently team merges every day. Commit rate to origin would be about 1 commit per developer per day… which is okay.. don’t often have merge hell except when coming from different versions
Continuous Integration. It is very difficult to do 4 without 5… it is so easy to set up a CI server I can’t fathom why this wouldn’t be a no brainer… Of course this is for .Net, but I would think most of these practices wouldcould be applied uniformly across technology stacks.
Reza

why do you think TDD/git and Scrum are best practices or good things to be preached ?! Because in many places/projects they are not !
- http://fragmentedthoughts.net Adrian
  
  Reza – What circumstances are you thinking of where TDD / DVCS(git) or Scrum should not be promoted. I am having trouble thinking of examples, except where the tool support is not available.
http://www.brainster.org braincube

i do “Continuous Integration” ^)