5 things programmers preach but don’t practice

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!

  1. 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.
  2. Refactoring. What most shops call “refactoring” is really a month-long timeout for software refurbishment every year or so.
  3. Scrum. It’s apparently hip to say “we do Scrum” now. 99% of the time this means “we do daily standup meetings”.
  4. DVCS. Git or not, most projects are doing centralized version control with periodic merge hell.
  5. 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?

Enhanced by Zemanta

55 comments

  1. 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!

      1. “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!

        1. 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.

          1. 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.

  2. 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!

    1. 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.

      1. 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 😛

  3. 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….”

    1. 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.

      1. 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.

  4. 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.

    1. 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.

  5. +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.

  6. 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. 

      1. 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.

  7. 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. 

  8. Also, if you’re “doing continuous integration”, but you’ve had broken builds for a month, you’re doing it wrong.

    1. 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.

  9. 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.

  10. 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!”

    1. 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.

    1. 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.

  11. 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).

    1. What is particular about a distributed rails project that a CI server such as Jenkins or Cruise Control cannot be usedcustomised for use ?

  12. 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.

  13. 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.

  14. 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…

  15. 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”?

  16. 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.

  17. 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 !

    1. 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.

Comments are closed.