Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Framing of the Developer

svese.de

Post reply on HN
Print view View original

31–40 of 67 posts

Re: The Framing of the Developer

#31

Post by marcus_holmes »

twic wrote: post #30
marcus_holmes wrote: post #20

Earlier quoted context omitted.

This is the "no true scotsman" thing that plagues SCRUM too. The "you're not doing it right, so obviously it's not working for you" argument. If a team attempts to implement XP, and fail, then XP failed. Any discipline that doesn't work in real situations using real people with real politics and management issues, doesn't work.

Exactly! I just tried to cook some scrambled eggs. One the eggs went on the floor, and the eggs in the pan cooked to quickly and turned into an omelette. Scrambled eggs has failed!

hehe nice analogy. But yes, if this was the experience of most people who made scrambled eggs, then I'd be comfortable saying that recipe had failed ;)

Re: The Framing of the Developer

#32

Post by ikiris »

bob1029 wrote: post #27

This seems like such an obvious thing to me. When an issue comes up for prioritization during review, we simply ask "What value does this bring to the business". Every single meandering bullshit conversational path we happen to find ourselves upon can be immediately curtailed by stating these words. Technical folks may not like hearing it all the time, and it doesn't necessarily have to be the dominating factor 100%…

This kind of thinking is how you run a good business into the ground chasing local maxima.

Ask Kodak

Re: The Framing of the Developer

#33

Post by marcus_holmes »

mikekchar wrote: post #24
marcus_holmes wrote: post #20

Earlier quoted context omitted.

This is the "no true scotsman" thing that plagues SCRUM too. The "you're not doing it right, so obviously it's not working for you" argument. If a team attempts to implement XP, and fail, then XP failed. Any discipline that doesn't work in real situations using real people with real politics and management issues, doesn't work.

I can understand what you are saying, but there are some very subtle and difficult things in the world. The fact that only a very few people in the world can be successful with the things that make a concert pianist successful does not mean that concert pianists have failed. I will absolutely agree that XP is not a discipline for the masses, but it is incredibly effective for those who are able to use it well (to the…

I'd agree with that. It's one approach (of many possible), and it only works in certain circumstances.

I think part of the problem is that it's difficult to tell beforehand if XP will work with any given team. And that's the "no true scotsman" part :- if you can't tell beforehand whether it'll succeed or fail, and all failures are down to "not doing it right", then it's broken ;)

Re: The Framing of the Developer

#34

Post by mikekchar »

marcus_holmes wrote: post #33
mikekchar wrote: post #24

Earlier quoted context omitted.

I can understand what you are saying, but there are some very subtle and difficult things in the world. The fact that only a very few people in the world can be successful with the things that make a concert pianist successful does not mean that concert pianists have failed. I will absolutely agree that XP is not a discipline for the masses, but it is incredibly effective for those who are able to use it well (to the…

I'd agree with that. It's one approach (of many possible), and it only works in certain circumstances. I think part of the problem is that it's difficult to tell beforehand if XP will work with any given team. And that's the "no true scotsman" part :- if you can't tell beforehand whether it'll succeed or fail, and all failures are down to "not doing it right", then it's broken ;)

I may be being overconfident, but I feel I can tell you if it's going to be successful (I need to spend some time with the team, first though). That used to be my gig ;-) I'm usually pretty straightforward when I go onto a project and tell management: XP is not going to work for this team, let's try something else. Where I've had difficulty is when management wanted a hybrid approach and usually that doesn't work well.

Re: The Framing of the Developer

#35

Post by TomMarius »

marcus_holmes wrote: post #31
twic wrote: post #30

Earlier quoted context omitted.

Exactly! I just tried to cook some scrambled eggs. One the eggs went on the floor, and the eggs in the pan cooked to quickly and turned into an omelette. Scrambled eggs has failed!

hehe nice analogy. But yes, if this was the experience of most people who made scrambled eggs, then I'd be comfortable saying that recipe had failed ;)

Let's switch scrambled eggs for a two Michelin stars-restaurant kind of recipe (which is where I would put XP - to the very top of developers)

Re: The Framing of the Developer

#36

Post by marcus_holmes »

mikekchar wrote: post #34
marcus_holmes wrote: post #33

Earlier quoted context omitted.

I'd agree with that. It's one approach (of many possible), and it only works in certain circumstances. I think part of the problem is that it's difficult to tell beforehand if XP will work with any given team. And that's the "no true scotsman" part :- if you can't tell beforehand whether it'll succeed or fail, and all failures are down to "not doing it right", then it's broken ;)

I may be being overconfident, but I feel I can tell you if it's going to be successful (I need to spend some time with the team, first though). That used to be my gig ;-) I'm usually pretty straightforward when I go onto a project and tell management: XP is not going to work for this team, let's try something else. Where I've had difficulty is when management wanted a hybrid approach and usually that doesn't work wel…

nice gig :) what was the biggest signal that the team would fail trying to implement XP?

Re: The Framing of the Developer

#37

Post by luckylion »

AmericanChopper wrote: post #26
29athrowaway wrote: post #16

That is why you need engineering leadership that can keep the PM in check, and can veto PM decisions if they endanger the product in a way only engineers can understand, or want to understand. And that engineering leadership needs to be independent enough from the PM, so that the PM cannot appoint redundant/agreeable scapegoats with no engineering weight. Maybe you can still allow the PM force their hand on engineeri…

> if they endanger the product in a way only engineers can understand If you have critical risks that only engineers can understand, then you have extremely poor engineering leadership. I can’t think of any examples critical risks I’ve encountered that couldn’t be communicated concisely to non-technical stakeholders.

> If you have critical risks that only engineers can understand, then you have extremely poor engineering leadership.

Or extremely incompetent PMs. I've had one PM be confronted with the documentation of something where it clearly said "don't do this, it's wrong and will ruin everything" (which, totally by coincidence, is what he was told by someone on the team before). He still demanded it to be done because he had heard a talk at some conference where that was recommended. It took getting the CEO into the issue via back channels to clear that out.

Imho the percentage of PMs, POs etc that have no clue what they are doing is much, much higher than in any technical role. If they're good at bullshitting, they can usually talk their way out of being blamed for their failure and switch to a different company later.

Re: The Framing of the Developer

#38

Post by [deleted] »

qw wrote: post #21
routerl wrote: post #10

Earlier quoted context omitted.

an organization where devs are apparently autonomous, so they're responsible for failures, but still need to go in the direction set by someone else. I've just left a place like this, largely for this reason. Someone with impressive credentials was hired by the senior leadership and given project ownership. The problem is that neither this person's education, nor their work experience, had anything to do with softwar…

> Choice example: does a time period "from January 2019 to January 2020" include two Januaries? The answer to this question would change, sometimes twice a week, when asked of the "product owner". Unfortunately, the only way you can protect yourself is to have a paper trail. If the PO says something, write it down in your tracker (Jira, Trello etc.), or at least an email. If the PO is unclear, write the answer accord…

[deleted]

Re: The Framing of the Developer

#39

Post by someguydave »

29athrowaway wrote: post #19
gregdoesit wrote: post #7

One of the most well-known companies using what the author calls “impact frame” is Facebook. There, engineers’ promotions and perf used to be heavily dependent on their impact. Developers needed to be aware what the business impact of their work was, thus they needed to measure (using the excellent tooling available). This model worked very well while the company was growing. Lots of features core to Facebook today w…

There is also the bus factor. If critical business functions depend on a piece of software maintained by one person, the organization has a problem. If you decide to become dependent on a piece of software, that software better be well documented, tested, audited and maintained by a group of people with certain level of redundancy in case one of them is not available or leaves the organization.

Preventing the destruction of the company in the case of low probability risks is its own impact.

Re: The Framing of the Developer

#40

Post by ascotan »

Interesting article, however I have a different take on it.

Agile/XP was originally envisioned to reduce the impact of middle management/business processes on software development and put the customer and developer together to get things done.

During the early days of XP/Agile this worked in certain areas where it was feasible to do so and there were not a lot of already establish business processes and business people who had a vested interested in preventing it.

At some point middle/product/project managers realized that this was just another business process and adopted and morphed it as their own. Although agile was invented and made for developers, today only non-engineers are involved in 'agile'. As a result we have craziness like scrum master as a full-time non-development job that requires certification from a business process body. Additionally the process people have added a ton of process cruft (burn down charts, playing poker with card decks, etc.) All of which is mostly unnecessary business processes.

So we're back to where we were before and developers and customers continue to be separated from each other.

In the new world, engineering leadership is being replaced by non-technical business people with certifications. The has lead to less skilled teams of 'developers and testers' that are no longer guided by highly technical engineers that have either actual or perceived power in the organization.

The net result of all of this is that developers are struggling in many orgs.

Post reply on HN