Agile, Waterfall, Scrum. WTF? Do I really need to know this stuff to write code?

Miscellaneous and Personal Stuff I Must Share
1

So I’m between jobs and talking on the phone with various headhunters and direct employers. Yesterday, a headhunter asked me about what design methodology I like to use. We were discussing web development so I mumbled something about MVC. He replied that that was something different, a framework, he was talking about design methodologies like Agile or Waterfall. :confused:

Someone else asked me if I was familiar with Scrum. I said that I’d seen it in some job postings and assumed it was some language or report thing that I wasn’t familiar with. Nope. It’s another design methodology.

Here’s Wikipedia’s description of “Agile software development”.

Seriously? Am I missing the boat here or is this something more than buzzwords and mental masturbation?

Granted, I’m more of a coder than a designer, but I have sat in on and contributed to design meetings. As far as I could see there was never a name for whatever “methodology”, if any, we were using. We just sort of… designed.

I remember years ago working at a company that had a lecturer talk to us about Case methodology but we never actually used it.

Is this all a bunch of buzzwords and fads? How do I respond to questions about this stuff? Ask me about PHP or Perl or C or OOP or SQL and I know what you’re talking about, but I’ve never been in a situation where people were actually attempting to use some new fad design methodology.

I say “attempting” because I find it hard to believe that any real world project will be able to stick to some canned methodology. Am I missing the mark here? Am I on a different planet from everyone else?

Is this stuff for the pointy haired guys that us developers just humor?

What do I say when interviewers ask me about this stuff?

2

Do you need it? No, but it is certainly helpful.

Scrum and Agile are just ways of developing code, and while they do have some hype and can be a pain if done incorrectly, I think it’s the right way to develop code. Honestly, if you’ve never heard of agile or scrum, I can understand why the recruiter was hesitant, because these have been around for over a decade by now.

There’s lots of ways to develop software - everything from the “cowboy coding” that involves no design, no documentation, and no testing to the strict processes that go into avionics software.

Waterfall is in the more strict side of things. The Requirements guy collects all the requirements, then the design guy does all the design, then the programmer writes all the code, and then QA tests all the code. If a problem is found in one stage, the whole thing (not really, but it’s a pain) has to cycle back up the ‘waterfall’ to fix it. This is usually slow and error-prone.

Agile is more loose. Instead of developing the whole thing at once, you develop 1-2 features at a time, then get the customer to sign off on those before starting on the next couple of features. Repeat every couple of weeks. I find this a lot less daunting and much less error prone.

Sure, there’s buzzwords involved, and it won’t take long to learn agile and it’s nuances, but it should be well-known among professional software developers.

ETA: Agile is supposed to adapt, but it’s easier to stick to that than other methods. It is NOT just for the PHB - usually it’s something the developers prefer because it gets the boss off their back. (And yes, I think you are on a different planet, but no biggie)

I would suggest reading martin fowler’s website on Agile before your next interview.

3

No, you pretty much got it. It’s the latest meaningless buzzword, circle-jerk bullshit that gets dreamed up by people with far too much free time on their hands.

Unfortunately, simply because it IS the latest meaningless buzzword etc., etc., you should at least read up on it so that you can throw some buzzwords back at the headhunters.

4

You should read the book, or at least an article on it. Schwader and Beedle wrote one of them.

“Agile Development with Scrum”

Is it a current buzzword and methodology? Yes. But it is the current framework used (along with Sprints and Morning Stand Ups) to keep things moving.

It works, and a lot of development managers use it. Skim a few chapters (or find something online) and you should be fine.

It is all about short time frames, quick reviews, and regular communication so that others know what the hell is going on with the next release.

5

Scrum is pretty much a formalized way to do quick iterations while developing. It’s an attempt to keep communication/specs under control, by encouraging small development stories/tickets, and frequent feedback & communication between development, design & product owner.

Agile is too vague a term to be something you can “know”. Scrum is an example of an agile methodology.

Nobody ever does waterfall. Just ignore it.

In my experience, Scrum is a pretty good and useful project methodology, if you’ve got a smallish dev team and design & product owner are willing to invest the time to be part of the feedback loop. It’s also pretty simple and easy to learn - especially if you’d be joining a team that already does Scrum.

Oh, and you don’t NEED to know that stuff, but if I would recommend trying out Scrum if you have the opportunity.

6

Okay, so I have two different responses. Clothahump agrees and yellowjacketcoder says that I’m on a different planet, but you both agree that I need to at least be able to discuss this stuff, which I agree with.

Honestly, I’ve never run into any of this stuff in any of my past employment. I’ve seen mentions in job ads and assumed they were some language or programming tool.

yellowjacketcoder, I’m not familiar with Martin Fowler. Do you have a link to his website?

7

There were two more responses while I typed my last response. It sounds like what we’ve always done more or less naturally. Frequent communication and feedback along with regular meetings. We never had any names for it. It’s just having a good team that can work together.

Sprints and Morning Stand Ups? Sounds like something you’d do in a gym.

8

You probably need to know something about that stuff so you can get a job and get paid to write code. After getting that job, these things will turn out to be a minor part of your personal efforts, although depending on the organization and their gullibility, it may have a much greater impact. They are some pretty basic concepts, but as usual, someone has to make up labels for them and pretend they have magical properties.

9

It’s the SDLC equivalent of vaporware.

Read a wikipedia article on it and consider yourself well informed. When somebody asks you whether or not you have experience with Agile/Scrum, say YES.

As for Waterfall method, I’m old enough to have been fully immersed in that methodology as well and have completed multiple large projects using the waterfall method. It works better than the others and in my opinion remains the best SDLC PM tool. Most places have developed occupational A.D.D. and can’t wait long enough for a system to be implemented using that method. But in my humble long suffering experience, it offers the best quality control and scope creep.

10

His website is the eponymous http://martinfowler.com/. There’s a lot of stuff on there, but there is a section specifically on agile.

I do think a lot of good teams do this already - but knowing the terminology is a good idea, and sometimes there’s obvious things people haven’t thought about that Agile points out to you.

I will admit it can be misused.

11

As others have said they are ways that development teams write code together - not knowing them would be a red flag to me as I would expect a programmer to be aware of them at least.

12

I’m glad there are some people here that agree with me.

I guess I need to read up on Scrum at least.

13

Agile is real, and as a methodology it has it’s pluses and minuses. But if the organization is using it properly you will need to learn how things work and change the way you approach coding. It is different from waterfall (which is used quite often in my experience) and requires people to coordinate much more.

Agile is used poorly more often than it’s used correctly, but that’s true of all programing methodologies unfortunately.

14

What can I say. Nowhere I’ve worked has ever used those terms, plus I have a number of years of self-employment running web stores.

For me, someone asking about these things is a red flag because I’m not sure that I’d want to work for them as they sound like someone who goes in for the latest fads and then passes judgement on people who aren’t familiar with them. Unfortunately, I have to ignore those flags because I need a paycheck.

15

First, I agree that you should be aware of the latest methodologies. Subscribe to the free trade rags at least - it will let you know what people are talking about, though don’t believe it works.

The real question is what the new company is developing. Writing software for a massive international project is different from writing software for a department. Writing an accounting package is different from writing something for a project no one has done before. The project I’m running now is for people doing this job for the first time. My attempt to get even a glimmer of specs went nowhere. So I designed things to be easy to modify and gave lots of releases. It is agile even if not Agile. Doing a three month development phase would have been a total waste. On the other hand, there are projects for which not doing firm specs would lead to disaster.
So, ask questions, use your common sense, and plug in the right buzzword for the methodology you think the new employer should use.

What kind of projects have you worked on, by the way?

16

The Agile Manifesto (http://agilemanifesto.org/) was produced in 2001 this isn’t a new fad. Uncle Bob is a pretty famous guy in programming circles you must have heard of him?

I work in finance and the shift to Agile is now pretty much complete, I don’t interview many programmers with finance experience who have not used it.

17

Back in the dark ages when I started people talked about programming in the large versus programming in the small. I don’t know how much real programming goes into a web store, but I rather suspect it is programming in the small. I’m doing that also now, and no one hear would have the slightest inkling of what I’m talking about if I said “Agile” but it is still a good way of doing things. It is not good for a massive project, though chunks might use it.
The biggest danger is when someone who has only programmed in the small pooh-poohs methodologies need for a large project, and someone who has only programmed in the large thinks that kind of overhead and coordination is required for a small project.

18

They’re silly labels slapped on things that many dev teams were doing anyway–largely, I suspect, because managers demanded labels and measurements to assuage their fear of the wizards among them. They don’t understand what the devs are actually doing, so they insist on adding hoops to jump through so they can at least see people doing something.

“Project Death Spiral is six weeks late and the test server is chanting in Latin, but we’ve had full participation in all our Morning Stand-Ups, so everything is A-OK!”

19

That also applies to MRP*, ERP**, ISO 9000***… most methodologies are attempts to explain what some people view as “common sense” and other’s can’t even begin to grok, with greater or lower amounts of fancyspeak thrown in.
*: when you’re planning to build something, make sure you’ll get the materials you need.
**: as well as the personnel and machines.
***: write down what is it you do and how you do it, and do what you’ve written. If how you do things changes, update the manuals. If your manual describes Sleeping Beauty’s castle and you live in a cottage with seven dwarves - rewrite it.

20

The last BIG project I worked on was in the 90s and early 2000s. We had a GREAT team that always met deadlines and never had a need for some named methodology.

Since then it’s been a bunch of small projects and stuff I’ve done myself for my (now defunct) business.

Then of course, for the last 2 1/2 years I’ve been running an IT department. I was supporting the corporate office as well as salespeople and managers all over the country. Everyone was basically just using the standard office apps for email, etc. So that involved very little coding other than some website maintenance.

So I just haven’t run into these methodologies.