7 ms·
This cycle seems to repeat endlessly in our industry: * Early adopter independently comes up with an idea that works well for his/her team. * Writes an innoce
by ryanackley 7y ago
This cycle seems to repeat endlessly in our industry:
* Early adopter independently comes up with an idea that works well for his/her team.
* Writes an innocent well-written article or book.
* Idea somehow becomes dogmatic. Even for situations that don't make sense.
* After some time, people rebel against dogma because they realize it doesn't make sense for every situation.
* Original idea now considered anti-pattern even though it may still make sense for some people or situations.
- rkangel 7y agoMy takeaway from this is that more articles should include a 'this works in x situation, probably also works in y, but is not suitable for a, b, c' discussion. Applying the right techniques in the right places is an important part of engineering - some authors talk about it more than others and it's very useful.
- dirtydroog 7y agomedium.com articles define the software development practices of most companies. It's a bit of a joke.
- andrewstuart2 7y agoOur industry? I think the problem goes well beyond any industry; it's just a human thing. 1. See success 2. Want success 3. Copy behaviors 4. Behaviors were only part of success
- Dirlewanger 7y agoYup. It's a byproduct of software not being grounded in anything compared to, say, every other engineering discipline. They all have the laws of physics. Software has...a bunch of different mantras and paradigms, and for every one out there, there's one that is its direct opposite.
- chadcmulligan 7y agoEven things that have science are largely ignored - one I always shake my head at - oracles for ethereum. Proved many years ago - there can't be an oracle. Ethereum developers - we'll build oracles so the transactions are guaranteed. No doubt there will be arguments for how oracles for ethereum are different, and so on
- btrettel 7y ago> It's a byproduct of software not being grounded in anything compared to, say, every other engineering discipline. They all have the laws of physics. I think experimental evidence helps, but if you look at the physical sciences more closely, you'll find tons of similar narratives. This is a fairly universal human behavior unfortunately. Nonsense becomes "canonized" as I put it, and then continues to be repeated by people until someone finally looks into it and realizes it's nonsense and publishes an article saying so. But unfortunately that's not always the end of the nonsense. Even things which have been debunked can continue to be cited and used. One great example (not engineering but the point stands): https://www.youtube.com/watch?v=WRoe3xXFtmM https://www.youtube.com/watch?v=WRoe3xXFtmM > In one sense we won. We got our points across. People now understand that this research is wrong. But this 2005 article by Fredrickson and Losada gets citations today at 3 times the rate of our article that demonstrated that it was just utter rubbish. (Note that I'm using "nonsense" as an example here, but the top level comment was more general in that it mentions practices which apply in some situations erroneously being applied for all situations.)
- iovrthoughtthis 7y agoThats a funny way to spell Agile.
- rolltiide 7y agoMy mind was blown when I found out that daily standups were a Kanban philosophy and not a SCRUM philosophy. Only because every SCRUM team I have been on has standups and it is essential, as long as they are less than 1 minute long.
- travisjungroth 7y agoI still remember this standup I once had. 8 people, under 2 minutes. It was a dream.
- Agathos 7y agoI had a 45-minute standup the other day.
- rolltiide 7y agoRidiculous. I would have left the meeting. Just walked away to my desk and started coding after 3 minutes
- stkdump 7y agoDid it help the work vs not having it in the first place?
- travisjungroth 7y agoYeah, I think so.
- mikekchar 7y agoAlso not in XP. I eventually came to like standup meetings, but with one caveat: no management (including project management) is allowed to attend. Otherwise it becomes a status meeting rather than a "How can we get past our current blockers" meeting. Management glazes over all the technical talk -- the very thing that we need to speak about if we are to need a meeting at all. I'm going to say this rather rashly (and maybe regret it sometime in the future): any "Agile" process that includes a status meeting for developers is broken. Status should be determinable from the artifacts that have been produced. If management can not see or understand the artifacts, then your process is broken. If they prefer not to look at the artifacts, then your management is broken. If they need status on something that is "taking too long" then you haven't broken up your tasks enough. If you have broken them up enough and it's still "taking too long", then there really isn't much to say other than "this blew up on us" -- which is obvious. What a standup is good for is casually checking with your teammates that the approach you are taking is reasonable and to discuss other strategies. It's useful for asking for help, swapping pairs (or getting one in the first place). If you find yourself doing the "This is what I did yesterday. This is what I'm going to do today" dance, then you are not getting much value. It should be blindingly obvious what you did yesterday, because code was written, reviewed and hopefully merged. Possibly you may want to say, "Hey, can you review my code?" It should be blindingly obvious what you are going to do today, because you grabbed a card/task from the backlog. The only thing you need to talk about is, "I'm confused. How do I do this?" and the like. /end rant ;-)
- taneq 7y agoThis process reminds me of "Considered Harmful Considered Harmful": https://meyerweb.com/eric/comment/chech.html https://meyerweb.com/eric/comment/chech.html
- kodachi 7y agoIt's turtles all the way down, my friend.