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?
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 :)
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.
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.
I prefer places that have a development method that everyone can actually follow.
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.
