Salmon-ladder development is not the way to do agile(blog.apterainc.com) |
Salmon-ladder development is not the way to do agile(blog.apterainc.com) |
In my opinion, true agile is rapidly getting code in the hands of users as quickly as possible. Then iterating on that. You don't need a lot of requirements to get started. But need to be not afraid of change! Things will change (maybe everything will change) and that's ok -- plan for change. This author starts with the implicit premise that change is bad and all conclusions are the result of that.
I've been involved in a few "Agile" projects implemented in hard-to-change platforms. And ultimately it's just disguised waterfall -- if you can't change the product then you're doing big planning up front.
Where in the article do you draw this conclusion from?
Change isn't bad. The article doesn't say change is bad. Change introduces complexities. And unclear or ill-defined objectives (aka, requirements) make change more likely.
How did you come to that conclusion? The theme of what I was saying is that projects to be given direction from the stakeholders. I never said anything to suggest that the direction couldn't change.
If programmers are coding whatever they want based on wildly unfounded assumptions then they're not doing Salmon Ladder development -- they're just terrible developers. If they're given some direction, coding, and iterating on that result then that's great. Even if they make some wrong assumptions at first, I don't see anything wrong with that.
"Don't start without requirements"
Depends on if you even know what the requirements are, some projects are just an idea.
Before you start writing software, have at least one
clear objective. You might call this a requirement, a
user story, or a specification. Give the developers a
target to shoot at. Otherwise, you will be swimming
upstream.
Even producing the prototypes meant you probably had some objectives unless someone just typed something out one day entirely on a whim.
Why is it so unimaginable to create something without being able to articulate it beforehand? Or why wouldn't it be possible to start with something and letting it evolve by discovering new insights while building it?
How many successful things are really built by first writing down requirements?
Sometimes it is just an personal itch or curiosity. Other times it is actually total epiphany that brings success...
When a project or task is individual or trivial, then who cares. When not, a "hack it 'till it (hopefully) works" approach doesn't cut it.
Edit: grammar
If its a business process, lack of any form of requirements is how technical debt is guaranteed from the start.
For example, I've seen a project where upper management tasked a team of developers with writing software and didn't give the team specific direction nor did they communicate clear goals for the software. The team asked for more details, and the management told them to "do it agile". The team wrote good software, but they solved the wrong problem.
But it is not just management that is at fault. Those developers did not have enough backbone to push back. Instead of educating management about the process or telling them it can't be done they just sulked back to their cubicles and coded. There is no surprise it turned out wrong.
I see where you're coming from on this; you cannot build any product without communicating with the stakeholders. That communication can be rough scribble diagrams, notes, detailed requirements, meetings showing off prototypes -- really anything. All software development processes are about communication.
Obviously it could have been found during planning but it never would have. It's hard to get people to think in that much detail without anything concrete.
Edit: with the exception of literal rocket scientists -- they're very good at planning and getting the details right compared to the average person.
Edit: Do you really want to be an evangelist for mediocrity? You should give thinking things through a try; none of us get it right even close to all the time, but I think you will be surprised by how effective you are at it.
Sometimes you have to do the work and build something that isn't fully specified. Or when management says they want a Facebook clone and then walks away, you have to be willing to say "no, you have to come back the table on that one".
I think the pendulum has swung too far the other way, however, and it is not hard to find opinions (and Stack Overflow comments and sometimes answers) stating, in effect, that the only valid way to develop code is to write some and try it. For the most part, I think these authors have not considered of how much thinking ahead goes into making even that work, and if they did, they would not be so dogmatic about deprecating it.
Three areas, of definite relevance to ordinary commercial applications, where I think thinking ahead is more or less essential to success, are security, concurrency and performance.
Instead the article is about programmers who code without the involvement of stakeholders at all. The inclusion of agile is a bit of red herring.