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

41–50 of 67 posts

Re: The Framing of the Developer

#41

Post by commandlinefan »

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%…

"We need to add unit tests" "That brings no value to the business!"

"We need continuous integration" "That brings no value to the business!"

"We need version control" "That brings no value to the business!"

"We need to upgrade from JDK 1.4" "That brings no value to the business!"

"We need to safeguard user's data" "That brings no value to the business!"

And on, and on, and on.

Re: The Framing of the Developer

#42

Post by marcosdumay »

commandlinefan wrote: post #41
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%…

"We need to add unit tests" "That brings no value to the business!" "We need continuous integration" "That brings no value to the business!" "We need version control" "That brings no value to the business!" "We need to upgrade from JDK 1.4" "That brings no value to the business!" "We need to safeguard user's data" "That brings no value to the business!" And on, and on, and on.

Yes, that's how that question is normally used. But it's a lie, those often bring value to the business.

If you are trying to answer it honestly, you will certainly get better results. But I am still not sure it won't bias you in a harmful direction.

Re: The Framing of the Developer

#43

Post by TheOtherHobbes »

commandlinefan wrote: post #41
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%…

"We need to add unit tests" "That brings no value to the business!" "We need continuous integration" "That brings no value to the business!" "We need version control" "That brings no value to the business!" "We need to upgrade from JDK 1.4" "That brings no value to the business!" "We need to safeguard user's data" "That brings no value to the business!" And on, and on, and on.

That's because "bringing value to the business" is confused with "increasing quarterly profits."

The problem is poor valuation. All of the above can be process lubrication. The actual value comes from the process that goes on top of them. But if they're not in place, process implementation is going to have a lot of unnecessary friction, which reduces the eventual value of the core business process.

Some businesses get this, others don't.

For those that don't, it helps to explain the effects with real financial metrics. If your product is six months late and customers hate it because it's full of bugs, your process has failed to "bring value."

Re: The Framing of the Developer

#44

Post by PaulStatezny »

marcus_holmes wrote: post #20
mikekchar wrote: post #5

I 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…

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.

> If a team attempts to implement XP, and fail, then XP failed

I've never done XP, but it's probably more reasonable to say: "If a team attempts to implement XP, and fails, then..."

(Choose one:)

- Maybe XP requires more discipline than the team is willing to give.

- Maybe XP is too rigid for that team.

- Maybe XP didn't fit the team's context or domain well.

Silver bullets don't generally exist. Maybe OP is right ("true" XP has real benefits), but the effort required to do "true" XP isn't worth it for many teams.

This might sound like "one true Scottsman", but it also applies to a lot of hard things in life.

Re: The Framing of the Developer

#45

Post by pacala »

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%…

As other people mentioned, this is shortsighted. What you want to target is a balance between exploitation, 'bring value to the business', and process improvement, 'how do we simplify our processes to make it simpler to bring value to the business in the future'.

Both can be argued with concrete scenarios and data.

Re: The Framing of the Developer

#46

Post by pacala »

TheOtherHobbes wrote: post #43
commandlinefan wrote: post #41

Earlier quoted context omitted.

"We need to add unit tests" "That brings no value to the business!" "We need continuous integration" "That brings no value to the business!" "We need version control" "That brings no value to the business!" "We need to upgrade from JDK 1.4" "That brings no value to the business!" "We need to safeguard user's data" "That brings no value to the business!" And on, and on, and on.

That's because "bringing value to the business" is confused with "increasing quarterly profits." The problem is poor valuation. All of the above can be process lubrication. The actual value comes from the process that goes on top of them. But if they're not in place, process implementation is going to have a lot of unnecessary friction, which reduces the eventual value of the core business process. Some businesses ge…

Exactly right. Building cowboy software with intense schedule pressure and best practices corner cutting it's likely to give you both late releases and bug backlog long enough to circle Earth three times.

There will be more bugs, and bugs will be more time-consuming to fix.

Re: The Framing of the Developer

#47

Post by simiones »

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%…

> simply going to the customer and asking them, "Out of these 10 things, if you could have 3 by the end of the month, which would you pick?"

This is only simple for a limited number of businesses. If you're building a product and not selling a service, it's much harder to nail down what is actually important to potential customers. Even talking to existing customers about new features is never a fool-proof way of getting the right prioritization.

Even when you do have a customer you can go and ask, they are rarely a single entity. The person in charge of the buying decisions may think some features are important, but the people who will end up using the product may have other priorities. Even then, prioritization may be hard on their part. If I were building a word editor for you and I came and asked whether word counts are more important than page numbers for you, would you be able to give a confident answer? Would your colleagues give the same answer? How about prioritizing both features over some stability work (e.g. you get both page numbers and word counts, but the product is still a little crashy)?

Re: The Framing of the Developer

#48

Post by frandroid »

> I always wondered why it isn’t called “product debt” because product took the credit to get a feature faster and must pay back by investing the time to clean up. Technology is the bank that gave credit.

I would expect massive pushback trying to push this framing...

Re: The Framing of the Developer

#49

Post by 29athrowaway »

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.

For every position, there is a chance of a bad hire. PMs are no exception. Every productive employee has a chance of losing motivation and start underperforming. Again, PMs are no exception.

You organization needs ways to detect and "fix" situations caused by a person not living up to their role.

Balance of power between product and engineering is one of such circuit breakers.

Re: The Framing of the Developer

#50

Post by 29athrowaway »

someguydave wrote: post #39
29athrowaway wrote: post #19

Earlier quoted context omitted.

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.

Let's say the probability of someone leaving their job in a given day is 1/100.

If you have 100 employees, from which each one of them is working on some critical piece of software that nobody fully understand, eventually you get a death spiral of orphaned projects.

Post reply on HN