Live data from Hacker News

Salmon-ladder development is not the way to do agile

blog.apterainc.com

11–20 of 23 posts

Re: Salmon-ladder development is not the way to do agile

#11
post #6

I hate the term "requirements" with passion. It is almost always used by people without any vision or passion. 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 i…

If its a "personal itch or curiosity", sure.

If its a business process, lack of any form of requirements is how technical debt is guaranteed from the start.

Re: Salmon-ladder development is not the way to do agile

#12
post #5

I start all kinds of projects with minimal requirements. You obviously have to have something to start but I'll go into a meeting with a notepad and suss out what's need enough to get started. 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 chang…

> This author starts with the implicit premise that change is bad and all conclusions are the result of that. 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.

Is it actually a problem that you've seen in real life where programmers write code without any direction? That seems impossible. A program exists to solve a problem. You might have a pretty vague idea of the details of that problem but ultimately you know what it is.

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.

Re: Salmon-ladder development is not the way to do agile

#13

Earlier quoted context omitted.

> This author starts with the implicit premise that change is bad and all conclusions are the result of that. 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.

Is it actually a problem that you've seen in real life where programmers write code without any direction? That seems impossible. A program exists to solve a problem. You might have a pretty vague idea of the details of that problem but ultimately you know what it is. If programmers are coding whatever they want based on wildly unfounded assumptions then they're not doing Salmon Ladder development -- they're just ter…

It is a problem I've seen in the real world.

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.

Re: Salmon-ladder development is not the way to do agile

#14

Earlier quoted context omitted.

Is it actually a problem that you've seen in real life where programmers write code without any direction? That seems impossible. A program exists to solve a problem. You might have a pretty vague idea of the details of that problem but ultimately you know what it is. If programmers are coding whatever they want based on wildly unfounded assumptions then they're not doing Salmon Ladder development -- they're just ter…

It is a problem I've seen in the real world. 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.

This is not a software development process issue. If management is bad, doesn't understand the process, and there isn't buy in then the project will fail. Take that same team and same management and do it waterfall and I doubt the outcome would be any different.

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.

Re: Salmon-ladder development is not the way to do agile

#15

Earlier quoted context omitted.

Is it actually a problem that you've seen in real life where programmers write code without any direction? That seems impossible. A program exists to solve a problem. You might have a pretty vague idea of the details of that problem but ultimately you know what it is. If programmers are coding whatever they want based on wildly unfounded assumptions then they're not doing Salmon Ladder development -- they're just ter…

It is a problem I've seen in the real world. 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.

[deleted]

Re: Salmon-ladder development is not the way to do agile

#16

Earlier quoted context omitted.

> This author starts with the implicit premise that change is bad and all conclusions are the result of that. 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.

Is it actually a problem that you've seen in real life where programmers write code without any direction? That seems impossible. A program exists to solve a problem. You might have a pretty vague idea of the details of that problem but ultimately you know what it is. If programmers are coding whatever they want based on wildly unfounded assumptions then they're not doing Salmon Ladder development -- they're just ter…

I have seen quite a few cases where more thought to work through the specific implications and consequences following from "vague ideas of the details" would likely have quickly identified problems that did not emerge until a bunch of code had been written.

Re: Salmon-ladder development is not the way to do agile

#17

Earlier quoted context omitted.

It is a problem I've seen in the real world. 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.

This is not a software development process issue. If management is bad, doesn't understand the process, and there isn't buy in then the project will fail. Take that same team and same management and do it waterfall and I doubt the outcome would be any different. 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…

> this is not a software development process issue... [followed by a list of software development process issues.]

Re: Salmon-ladder development is not the way to do agile

#18

Earlier quoted context omitted.

This is not a software development process issue. If management is bad, doesn't understand the process, and there isn't buy in then the project will fail. Take that same team and same management and do it waterfall and I doubt the outcome would be any different. 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…

> this is not a software development process issue... [followed by a list of software development process issues.]

[deleted]

Re: Salmon-ladder development is not the way to do agile

#19

Earlier quoted context omitted.

Is it actually a problem that you've seen in real life where programmers write code without any direction? That seems impossible. A program exists to solve a problem. You might have a pretty vague idea of the details of that problem but ultimately you know what it is. If programmers are coding whatever they want based on wildly unfounded assumptions then they're not doing Salmon Ladder development -- they're just ter…

I have seen quite a few cases where more thought to work through the specific implications and consequences following from "vague ideas of the details" would likely have quickly identified problems that did not emerge until a bunch of code had been written.

I've seen many cases where specific implications and consequences from vague ideas of the details could not possibly have emerged until a bunch of code is written.

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.

Re: Salmon-ladder development is not the way to do agile

#20

Earlier quoted context omitted.

I have seen quite a few cases where more thought to work through the specific implications and consequences following from "vague ideas of the details" would likely have quickly identified problems that did not emerge until a bunch of code had been written.

I've seen many cases where specific implications and consequences from vague ideas of the details could not possibly have emerged until a bunch of code is written. 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 t…

Coincidentally, The Cassini mission to Saturn comes to its scheduled end in a few hours. From what I have read about how NASA develops software, it is essentially a waterfall process, and I am fairly certain that its programmers have more than a vague idea of what they are doing when they write code.

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.

Post reply on HN