I'm in the job market and I have a set of priorities for my next job including salary, line of business, etc. One thing that is nowhere on my list of requirements however, is the development process methodology. I feel my job is to create software and I view the process structure as something I can adapt to whether it's scrum or waterfall or whatever.

Is the development process methodology a priority for you?

  • 8
    Depends on how much patience you have, and if you suffer fools gladly.
    – snakehiss
    Commented Mar 21, 2011 at 5:11

7 Answers 7


It is important to me only as far as not getting in the way of the common sense that we hope most professionals would have.

When we talk about version control, there is the argument that any version control beats not having anything at all, this isn't the case with development methods. Methods mean rules, and rules are sometimes broken. I've worked for companies that have been doing really goofy things for as long as anyone can remember, whatever problem the goofy procedure happened to cure went away a long time ago.

I want the following out of a company:

  • Clearly documented procedures that fit on a few pages. If I have to read a dissertation or (worse) a novel in order to get up to speed, I'll be lost for a long time.

  • Evidence that the company is open to changing procedures for the better. I need to be able to go to someone and say "I realize why you're doing [xyz], but there's a tool out that does most of that for you now. Can we use it?"

  • A little competition can be good and is often unavoidable. But, I'll avoid any shop where competition is used as a primary means to motivate people. If you have codified something that sends the # of lines committed per day by developer to the laser printer at 5 PM, I don't want to work for you.

  • If you have not prevented builds in blessed repositories from receiving changes that break said build, I run like heck. The last thing I want to do at 5:00 is pull in changes from the master repo to test my local build, only to find myself fixing someone else's semicolon.

  • I prefer jumping into methods that resemble an established method that fell from the agile tree. It's not mandatory, but a sense of familiarity helps to overcome the initial hump of trying to be productive while not making a procedural mistake.

If I see that I'll spend more time resenting procedures than being thankful that they exist, I'll probably pass on the job.

The other resounding "oh no, never again!" is "We're hoping you'll also set up best practices for us. We have six million lines of code and 21 telecommuters, should we be using an SVN or something?".

Someone could have some fun sorting that out. I'm not that guy :)

  • I really like your first bullet a lot. I might even put a version of that in my cover letter. Commented Mar 21, 2011 at 3:12
  • 2
    +1 - Nice answer! You really have me thinking about continuous integration and automated builds.
    – jmort253
    Commented Mar 21, 2011 at 4:56

As a developer, I care that the development process is sane. A number of different development methodologies can provide a sane development process. Conversely a broken company can provide an insane process no matter what they call it.

Therefore I don't particularly care what their official "development methodology" is. However I'll still ask about it simply because it gives a context for me to ask follow-up questions to figure out what they are really doing.


Yes, I've seen some poor methodologies that I don't think I'd want to repeat again. As a couple of examples, consider these: Would you be alright with a cowboy style for a team of a dozen developers where everyone may use their own source control, coding conventions, etc? I know I wouldn't. How about where to change a line of code there are a dozen forms to fill out and a about 20 signatures to OK the change in production that may take weeks to get done as the senior management sign off may take a while to get? The "whatever" leaves things a bit too open to my mind but then maybe I'm a little cyncial here.

  • 1
    Sounds like it's not so much "this methodology is OK, that one is not", but rather a matter of "whatever methodology they use, it can't be implemented in a completely dysfunctional manner." That would be how I feel, anyway. Commented Mar 21, 2011 at 2:06
  • Really? to change a line of code code you had to go through that many approvals? i can understand two at the most.
    – Aditya P
    Commented Mar 21, 2011 at 4:12
  • Hmmm ... assuming a totally dysfunctional bureaucracy, I can get to 20 pretty easily: actual dev, actual tester, actual ba and subject matter expert, actual architect, actual dba, lead dev, lead tester, lead business analyst, dev team manager, dba team manager, test team manager, infrastructure manager, help desk lead, business team lead, business manager, subsystem owner, system owner, change control manager, and the guy who actually deploys the change. (Disclaimer: I've never had to work in this kind of environment - would never want to! But I can imagine how this might get entrenched …)
    – Bevan
    Commented Mar 21, 2011 at 4:51
  • 3
    @Bevan - That sounds like a nightmare.
    – jmort253
    Commented Mar 21, 2011 at 4:52

As a developer I don't mind which methodology it is, as long as it is proper methodology, properly used.

So for example I wouldn't like to work for company which does "cowboy coding", especially if they are ignorant enough to think that they're actually doing Agile.

  • +1: I'm pretty much forced into a cowboy coding style and I really don't want that at work. It feels too chaotic and I really feel like it is holding me back.
    – IAbstract
    Commented Jun 9, 2011 at 0:45

I prefer places that have a development method that everyone can actually follow.

  • ... or ... maybe a development method ... in writing
    – IAbstract
    Commented Jun 9, 2011 at 0:14

I've worked in jobs that were very frustrating because of process choices used for development and business in general. These days I have some minimum requirements for process. Any business that doesn't engage in these I consider poorly run and will not work for. I don't have the patience for idiocy I used to have so I save myself and them alot of aggravation by skipping those jobs.


So long as we have some semblance of sensible requirements, some business representative who is engaged and responsive, and an understanding that the dev team has a large say in timescales, then I'm happy and I can fit into anything.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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