Agile methodology: quick and dirty or plan first?

Question

Agile question: does agile believe in getting things up and running the “quick and dirty way” - or does agile prefer building solidly from the ground up? Or is this not a methodology question, and more a question that you evaluate case by case?

I’m technically “remaking” the foundation of system, after I already built much of the structure itself... it’s not a monumental amount of work... would agile have wanted me to spec out the entire flow first, analyze it, tweak it, and then build? I feel like in a way it’s better this way... once I put up a messy system I see better how it needs to be done... on the other hand it isn’t so organized... just curious what best development practice is in this regard.

I believe this question is somewhat different than Agile and protyping since I am not asking about prototyping and throwaway code; I am interested in agile for production-grade code.

Answer 1

The agile methodology is plan first. It's just not plan everything first. In fact you gather requirements, design, code, test, deploy, and present. You just do all that in less than a fortnight (give or take) on the tiniest little feature you can deploy and get feedback about. Then you do it all again adding another feature or tweaking an old one.

The key is to write code that accepts change so that when you finally do see "how the entire flow should go" you can change the code to do that. That way when "the way the flow should go" (or whatever) changes yet again, it's not traumatic.

You can't write quick and dirty. Quick and dirty gives you ridgid code. Be fast by working small. Stay flexible by not spreading knowledge. Ideally any single feature change should impact only one place in the code.

You can't spend tons of time doing nothing but planning either. You can plan but you need to be able to change the plan. You need to quickly discover reasons to change the plan. When planning is going smoothly, with no surprises to learn from, that is when planning has gone on for too long. The planning and the coding have to happen close to each other. If you're learning then the older the plan, the dumber it is.

In the long term, you should plan to get smarter. Write flexible code. Then getting smarter doesn't lead to regret.

Answer 2

I dislike that for most people it's either "quick and dirty" or "big design up front". They don't even consider there are other options.

Agile is about building a system, where change, even late in the development, is trivial. This is done by building the software in small, incremental chunks, and locking down the behavior of those chunks with robust automated tests. And using frequent, automated deployment into production to validate the value of those changes.

By having robust automated tests, it becomes trivial to change even the hardiest parts of the architecture, by incremental refactoring over longer periods of time. So even if you realize your architecture could be done better halfway through the project, it is realistically possible to make the change relatively quickly.

Some people say that "some design up front" is good with agile. But if you intend to iterate on this design afterwards, you still need to make sure your development culture produces a system that is easy to change. So "SDUF" doesn't invalidate the need for robust testing, aggresive refactoring and continuous deployment.

By building "ease of change" into the system, you don't need to think hard about the initial design of your project, as that can be changed later on. The "Quick and dirty" approach, most people call it "spike", is only usable if you stabilize the features you find valuable. But you should not leave pieces of hacked-up code in your codebase for too long, as they slow down change.

Answer 3

Neither.

It's "Start simple and improve while you move along".

Quick and dirty is brittle, but fast (if the project is sufficiently small and short lived).

Plan first is rigid, but stable (if the project completes before it runs into financial or temporal constraints).

Agile is an alternative to the 2 above. It relies on an iterative approach where features are completed one at a time, feature by feature, and the knowledge gained while completing these fully functional pieces of the program is used to flesh out and adjust the plan as development progresses. To do so requires some planning up front - you need at least enough planning to be able to estimate how much work the individual features require - but because agile expects change, excessive planning leads to waste.

Answer 4

One of the main characteristics of Agile is to do short iterations and then reassess. You run ahead to explore new territory, learn from it, and then make a plan. That way your plan will be better. And if you fail (find your course idea does not work), you will have "failed fast", which is good.

So your approach is just fine. The danger though is then to say "Nice, it works, I'm done. What's next?". You're not done, there are plenty of cut corners to straighten out and you should get/take the time to do it properly once it is clear your approach yields a working and workable system. That could be to write tests, document, StyleCop, optimize, educate colleagues about what you did and how you did it, have it reviewed, etc.

Answer 5

To add to the above answers, a key principle is YAGNI. If your up-front design and planning enables the next step, then fine. But if it enables a hypothetical future step which you cannot prove is needed, then assume YAGNI.

Much design, both top-down and bottom-up, assumes that there will be significant code reuse. Experience says though that code reuse simply isn't that common, because you're rarely solving the exact same problem. If you need to solve a variant of that problem in future, refactor your design in future to add that variant, but do not consider it right now.

In other words, plan for the immediate task, but do not plan for anything further ahead.