The Framing of the Developer
svese.de
The Framing of the Developer
1–10 of 67 posts
Re: The Framing of the Developer
#2Actually I don't think of an elephant when you tell me not to think of an elephant, I think of the word elephant, specifically "huh, they said don't think of an elephant, now they are going to say see you can't stop thinking of elephants but I'm only thinking of the word and not thinking of the object. Why is that?"
Re: The Framing of the Developer
#3I've never been in a place where it was pretended that there is no person with authority to tell you what to do, whatever that person is called, and that person's ass is the one that's kicked in case things don't work.
What this article describes is alien to me: 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. There are multiple problems with that system. From the outside you can ask without concerning yourself with priorities or tradeoffs. From the inside, different persons can push in different directions.
Re: The Framing of the Developer
#4There is always a backlog and product manager. Roles! Not necessarily job titles. The question is who is / are managing the backlog and what criteria they use.
If you claim to have no backlog then you basically come to work each day fresh and choose something to work on - but don’t plan on continuing that tomorrow because to do so would mean you actually do have a backlog!
It might not be a Jira backlog but it exists in the minds of the devs at least.
So if we have a backlog then who should control it?
Good question and it depends on the company and the skills of the staff including the developers.
It also depends on how much it is wanted that developers do business strategy and to what degree they do it.
Leaving it all to a product owner can be OK if they do their job properly and understand the technical trade offs and really listen to both the technical and business sides. It can’t just be chucking shit in the backlog.
So, like nosql vs. vim or tabs vs. microservices, it’s going to be another horses for courses, best tool for the job kind of decision. Each company needs to carefully consider their strategy for basically: deciding what to work on.
Re: The Framing of the Developer
#5I like the diagram in the middle of the article and think it has a lot of value, but I want to comment on the "XP failed" aspect of the article. I've very rarely seen any team actually implement XP. The rare times I've been able to do so, it has worked spectacularly well. However, the constraints are difficult to deal with and XP in its original form only works with small, co-located teams. If you have more than 3-4 pairs of programmers, if they are not changing pairing partners regularly, if the developers are not co-located and importantly coding at core hours, if you are not TDDing your code, if you are not ruthlessly refactoring, if you are not integrating all of your code several times a day (I like several times an hour!), etc, etc, etc, then you are not doing XP. I think its very fair to say that XP as a movement has failed, although I think it has contributed mightly to the tool chest of developers. I do also think it's fair to call out XP on its lack of program management. Any successful XP team needs to sort that out and leaving it to the programmers is rarely the correct solution.
Just my usual rant on this topic :-). I'm sure it is surprising to many people that XP can be wildly successful, so I try to speak up when I see this repeated.
Re: The Framing of the Developer
#6I'm eagerly awaiting the next project management fad to make writing software less enjoyable.
Re: The Framing of the Developer
#7One 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 were created by engineers, not product managers. Newsfeed. GraphQL. A/B testing frameworks.
The difficulty comes both when growth slows - and it’s hard to have impact without cannibalising another team’s impact - as well as when having more impact actually causes harm to the company on a different direction. While engineers were optimising for engagement, tweaking the news feed algorithm to show items you were likely to click on, sensationalist content (sometimes: fake news) was over-promoted. While the ads team optimised for ad engagement by exposing various metrics, they exposed metrics that turned to public uproar later on.
The idea of only optimising for impact is a great short-term strategy. Long-term it is not nearly as black-and-white.
My take is the optimum is in-between. Engineers should have an understanding and input on the business impact. But the strategy and prioritisation framework does need to come top-down, aligned with the long-term goals of the business.
Re: The Framing of the Developer
#8This seems like a very specific set of experiences has set this developer up to make broad statements that do not fit with my reality.
> Feeling in control is one of the main drivers for happiness.
I'm not sure this person has ever developed a product, on their own. Feeling like you have some control is not the same thing as being in total control.
> The word backlog makes you think you are always behind finishing things. The frame says: Finishing means success. If we work from the backlog, we’ll have success. If we complete all the things I as a product owner have in my vision, we will have success.
> If a product fails in this frame, it is because we have not implemented the whole vision of the product manager.
No. It's a plan of things that the team might do. The backlog (and if you're lucky, the prioritization) is ever-changing. Many of the planned features aren't even controlled by the product manager, but by other dependencies (teams, markets, etc). This is why the product owner and product manager ends up being the same solitary role. It's efficient. You can pursue building ANYTHING FOREVER, so it doesn't even make sense to claim the backlog is a goal/finish line.
> In the backlog frame success is tied to implementing the items of the backlog.
No, that's your frame. It's not the paradigm. I like product managers. It's not my business to work harder, because I have an eventual productivity cadence (from collected metrics) which is what they have to work with and communicate to interested parties. Other than some light competition between peers, I'm not responsible for pushing to meet arbitrary goals. Everything is a negotiation. As a resource, I am what I am and we're all working together.
Re: The Framing of the Developer
#9If a prioritized list of not-yet-implemented features and issues is unhelpfully called a “backlog”, what should it be called? An “impact queue”? An “improvement roadmap”? Is this just a matter of language?
Re: The Framing of the Developer
#10I've never been in a place where it was pretended that there is no person with authority to tell you what to do, whatever that person is called, and that person's ass is the one that's kicked in case things don't work. What this article describes is alien to me: 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. There a…
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.
Relatively quickly, I started noticing exactly the dynamic you've described. If the backlog was growing (which it always is), engineering would get reprimanded and have the whip cracked on us. But when we'd reach objectives, we'd get no recognition or even acknowledgement, while the "product owner" would get showered in praise. After passing our first major feature milestone, the "product owner" was literally greeted with a bottle of champagne on their desk.
It took me a few weeks (read: too long) to trust my perception that most of the "delays" came from how terribly the requirements were written, and how often they changed for arbitrary reasons that created no value. 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".
In retrospect, I was in the exact no-win scenario you described, in which my team owned every failure but no successes.