allenholub

@allenholub@mstdn.social

For the moment, this account is mostly cross-posted tweets. Unfortunately, you won't be able to see any of the replies from Twitter so the conversation is split between two sites. (I'll obviously reply to comments on Mastodon on Mastodon.) Find me on Twitter at https://twitter.com/allenholub if you want to follow the conversation over there.

This profile is from a federated server and may be incomplete. Browse more on the original instance.

GeePawHill, to random
@GeePawHill@mastodon.social avatar

The real problem with all these text platforms: there are not enough characters in unicode to properly capture the guitar refrain on "Black Dog".

allenholub,

@GeePawHill Isn't it "As Falls Wichita, So Falls Wichita Falls"? Great album.

allenholub,

@GeePawHill Live takes are almost always better. 😄 There are some bands that I thought I didn't much like until I heard them play live!

searls, to random

I guess one valid reason for requiring employees to return to the office is so you can make sure they're not able to connect to the Internet. https://justin.searls.co/links/2023-07-20-google-s-new-security-pilot-program-will-ban-employee-internet-access-ars-technica/

allenholub,

@searls Is that sarcasm? I can't get work done if I can't connect to the internet. Many of the apps I use daily are so badly done (e.g., a myriad of configuration options scattered around in dozens of menus all accessed differently) that I have to consult the internet pretty much every time I use them. I don't know of any software-toll org that provides printed documentation.

allenholub,

@autiomaa @searls My "sarcasm" query was because of the word "valid." Precisely how is separating devs from information that they need to do their day-to-day work valid? Sure, the only way to guarantee that any computer is secure is to unplug it from the wall. You can't do much programming work staring at a black screen, though. I can't believe that even Google is that dumb, thus my thinking it was sarcasm, but they seem to be getting dumber (or at least eviler) by the minute.

afilina, to random
@afilina@phpc.social avatar

Here's a fun one:

"Uncaught ArgumentCountError: Too few arguments to function [redacted], 11 passed in [redacted] and exactly 13 expected."

There are hundreds of method signatures not matching usages in this codebase. It used to be merely a warning in PHP 5, which we know that devs usually hide.

allenholub,

@afilina 13 arguments! Geesh. 🙄

allenholub, to random

The only Definition of Done you need:

(1) Is it the highest quality code we can build knowing what we know now?

(2) Are the users happy with it (which you can't know until they're using it).

(3) Does it satisfy both our and our user/customers strategic goals?

That's it.

allenholub, to random

The biggest problem with Kanban boards is that they don't reflect the messy reality of software construction. We don't do things in a nice linear flow. Neither do factories. E.g., if a workstation is getting low on the parts needed to do its work, it sends cards upstream to the people building those parts. If it needs three parts, it sends three cards to different places. Typically, there will be a cascade of cards, sometimes going all the way back to raw-material acquisition. 1/2

allenholub,

Repeat with multiple stations, and you get a complex graph with many interconnections. It's not linear. There is no single "assembly line." That's why the notion of a "kanban board" doesn't really exist in manufacturing. Kanban boards do provide value in identifying dependencies and delays, but they are not the panacea that some seem to think they are. 2/2

allenholub,

@yisraeldov Kanban cards do, and sometimes they put them on "boards," but those are nothing like the "Kanban boards" you see in Software software shops, and most of those force a linear flow.

allenholub,

@yisraeldov Think "based on." The current software kanban board was developed by David Anderson when he tried to adapt the TPS to software dev. The manufacturing-style board does give you a big picture of inventory flow in the factory, but it's not the same as Anderson's board.

allenholub,

@cabang @yisraeldov I learn as I work. If I learn that the current thing isn't worth doing, I stop working on it. If I find that I have to make significant changes, I do. I discovered that through feedback: build, deploy, get feedback, modify what I just did based on that feedback. I'm continuously revisiting what I just did to improve it. I don't use backlogs—that's just management push. Team pull is better, & you're pulling from the customer, not management, design, Product, or whatever.

allenholub,

@cabang @yisraeldov I apply Lean principles to the backlog, treating it as the ready queue for the "build" column. Like all ready queues, WIP limits are in place, typically 1-2 weeks' work based on average measured throughput.

allenholub, to random

If you think you're Agile, you probably aren't.

At least going by the percentages I've observed. People who are agile tend not to use Agile™ to describe what they're doing. Too many misconceptions. Let's talk about effective ways to build software with agility, instead.

allenholub,

@poppis Which one?

allenholub,

@bunix SM is a Scrum term, having no meaning outside of Scrum. I see Scrum as anti-agile. You cannot become agile by following a rigid framework. "Agile Coaches" are actually a more widespread term. They're the people you go to when your team is having issues or problems, and they'll work with the team in coming up with a solution that makes sense in an Agile (and typically Lean) context. Nowadays, I try to avoid the word "Agile" entirely, though. I talk about agility instead.

allenholub,

@bunix A "coach" focused on "fixing things" is not a coach at all. They're process managers. Different job altogether, IMO. For the developers to ask for help, they need a safe environment where asking for help is not seen as a weakness. If you're punished for asking (e.g., you don't get a bonus because you "don't know what you're doing"), you won't ask.

allenholub, to random

It is not the PO/PdM's job to tell people what to build. Period. It's The PO/PdM's job to help the ppl doing the building to understand user/customer needs, to understand aspects of the domain they hadn't considered, & to connect builders w/ users/customers so they can converse. The team decides what to build (and who does what), when, and how.

allenholub,

@yisraeldov Nobody. You describe a significant (though common) anti-pattern that often results in a product nobody's interested in buying.

allenholub,

@yisraeldov I've one friend who has a mailing list of people with a vested interest in the change's success. A mailing goes out with every significant change, and they respond if they're interested. There are always a few people interested.

allenholub, to random

The only Definition of Done you need:

(1) Is it the highest quality code we can build knowing what we know now?

(2) Are the users happy with it (which you can't know until they're using it).

(3) Does it satisfy both our and our users/customers' strategic goals?

That's it.

allenholub,

@kickstink @forestpines
If they're so busy that they can't spend a couple of minutes giving you feedback, I'd wonder if you are building the right thing. If the product solves a pressing business problem, they'll be more than happy to ensure that the product satisfies their needs,.

allenholub, (edited ) to random

If you think you're Agile, you probably aren't.

At least going by the percentages I've observed. People who are agile tend not to use Agile™ to describe what they're doing. Too many misconceptions. Let's talk about effective ways to build software with agility instead.

geoff_horsey, to random

@allenholub How do you manage agile budgeting? It's reasonable for a stakeholder to say, "I want scope X. How much and how long?". At the start we're at the widest point of uncertainty. I don't think we can answer (esp. on a RFP), "with a team size of X our monthly burn rate is $Y. Give us 3 months and we can see where we land." Business still wants fixed cost and/or time, so scope is always what you have to wrangle. So contracts aren't written based on, "see where we land in x months." How do you manage this? Or better yet, are there any enlightening books/articles/blogs on this topic. It is something I struggle with daily.

allenholub,

@geoff_horsey At the basis of your question is the notion that we work on projects. I work on entire products, not projects. Project-based thinking is fundamentally waterfall, and it's not a given. It's difficult to be agile if your client demands that you work in an ineffective way. In any event, fixed cost, scope, and time is a classic death-march project. The iron triangle. Nobody can succeed at that, no matter what approach you take. →

allenholub,

That is, working the way you describe actually increases risk and pretty much assures that you'll be building the wrong thing. You can be cynical about that and just shrug and take their money, or you can be ethical and explain the issues to them. Selling a better way of working is a big part of selling your services. ✖️

allenholub, to random

A roadmap is a bet, not a plan.

allenholub, (edited )

@django The problem with the street-map metaphor is that you have a restrictive set of choices. Sometimes the best way to get from point A to point B is off-road cross-country. It's also a map of something you already know.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • anitta
  • GTA5RPClips
  • osvaldo12
  • thenastyranch
  • DreamBathrooms
  • khanakhh
  • magazineikmin
  • InstantRegret
  • Youngstown
  • slotface
  • mdbf
  • love
  • kavyap
  • rosin
  • megavids
  • everett
  • cubers
  • ethstaker
  • Durango
  • ngwrru68w68
  • tacticalgear
  • modclub
  • cisconetworking
  • Leos
  • provamag3
  • normalnudes
  • tester
  • JUstTest
  • All magazines
    •