Many years ago I went on a rant. I've gone on many a rant since then, but this particular rant happened, for the first time, many years ago. I was quite frustrated with teams claiming to be agile and saying all kinds of agile like things but not actually being agile. There were people running around telling others to "do the simplest thing that could possibly work" at random times and calling this project management. It could get a bit uncomfortable if you ran into one of these people in the bathroom and one of those random times hit. Others would occasionally chirp, "you aren't going to need it!" (Imagine running into that one in the bathroom!)
The big problem was that none of these people really knew why they were saying these things or why they were important. The methodology backing all of these things was lost but the phrases remained.
To me this became "Slogan Driven Development". And it was the first step in the death (or popularization, same thing) of a methodology. It got worse.
Soon people were running around saying "YAGNI!", and still not knowing what they were talking about. I would answer "WAGNY!", but never explain that it meant "We Aren't Going to Need You!".
At that point we have hit the last step in methodology death. The dreaded ADD or Acronym Driven Development. You have now boiled a methodology down to a few letters so as to better fit them on powerpoint slides.
Having now witnessed SDD and ADD (Slogan and Acronym Driven Development respectively) and the horrors they could bring I felt the need to try and fix the problem. A new methodology was needed. One that even if boiled down to acronyms could still be understood and accomplish its key goals. It had to be simple with binary goals. It had to bring the team together for a common goal. It had to be something you probably wouldn't put in powerpoint form.
To find it I turned inward and listened to what my gut was telling me. As usual it was saying, "Feed me!" And then I had it.
Lunch Driven Development! It's simple. When software is being developed there should be lunch and only lunch. It breaks down into three simple rules and a universal truth.
1) There should always be time for lunch. If you are working so hard that there is no time for lunch your project is screwed anyway so you might as well just go have lunch and not come back. Free lunch is preferred but not required.
2) There should not be dinner. If you have to work late enough that dinner and development happen at the same time then it's broke. Team dinners for fun are fine. They must be out of the office to count.
3) There should not be breakfast. If you have to get to the office early enough to have breakfast at work then you have failed. Having a second breakfast (that is one at home one at work) is okay. The point is you shouldn't have to be at work so early that you miss a normal breakfast time at home.
UT (universal truth). Snacks are good. This isn't just about development. This is just true. But in the Lunch Driven Development sense snacks are also key. Sometimes, hopefully on rare occasions, you do have to stay a bit late or arrive a bit early. Snacks can bridge that time between an early at home breakfast and lunch. Or fill that gap between lunch and a slightly late at home dinner. Let's be realistic sometimes you have to throw in a few extra hours.
That's it. Try it. You would be surprised at how much it can fix. If you really focus on getting lunch and getting out of the of there for other meals you can really clean up a bad project. It gives you that needed break and it has other not so obvious benefits. Project manager can't ask a stupid question if their face is full of sandwich can they?
There are a few things to point out about lunch and work that have nothing specific to do with software.
If you have a meeting that lasts for more than half an hour at anytime between 11 am and 1 pm then whoever organized that meeting must provide lunch.
Brown bag lunch meetings are evil. You're making me buy my lunch and sit in a meeting to eat it? That means the company can't afford to finish the project.
If you have lunch meetings more than 2 days every week then your job sucks. This means you have lunch driven development in name only and not in spirit. It's a lunch driven development anti-pattern. Remember "eating while meeting is cheating".
There are other valid methodologies. Such as "Shut up and Go Away", "Project Manager Roulette", "Requirement Bingo" and "Dude where's my code". They must be valid since I've seen projects actually use them. In the end I favor having lunch every day. It's simple and tasty. How many other methodologies can say that?
