Conversation

Notices

1. Embed this notice
   Paul Cantrell (inthehands@hachyderm.io)'s status on Friday, 29-Sep-2023 04:01:20 JST Paul Cantrell

   • Alex Rock

   Love this from @pierstoval:
   https://mastodon.social/@pierstoval/111133315182556286

   I know there’s a plethora of nuanced critiques of the term “technical debt,” and how “debt” is not a perfect metaphor, and how people over-read and misread the concept, and how devs push self-amusement via overengineering by clothing that as tech debt, and and and…

   …I still think it’s a great term. It’s a shared shorthand people in many roles know. Applying the metaphor as a quick heuristic, it captures a whole lot that’s true.

   • Embed this notice
     Paul Cantrell (inthehands@hachyderm.io)'s status on Friday, 29-Sep-2023 04:02:16 JST Paul Cantrell

     in reply to

     Now if we’re looking to expunge terms from our software development vocabularies, can we have some Real Talk™ about so-called “requirements?”

   • Embed this notice
     Paul Cantrell (inthehands@hachyderm.io)'s status on Friday, 29-Sep-2023 04:10:01 JST Paul Cantrell

     in reply to

     • Enema Cowboy

     @Enema_Cowboy Advice I often give my software students: human beings are much better at •reacting• than •imagining•.

     Listen carefully to all the bad and unwanted design advice. Take it as valuable information about assumptions, expectations, needs, usage patterns. Then give them something to react to. The reaction is where the useful design info.

   • Embed this notice
     Enema Cowboy (enema_cowboy@dotnet.social)'s status on Friday, 29-Sep-2023 04:10:03 JST Enema Cowboy

     in reply to

     @inthehands My experience has been those that have been responsible for providing subject matter expertise would much rather tell me how to design the presentation layer.

   • Embed this notice
     Paul Cantrell (inthehands@hachyderm.io)'s status on Friday, 29-Sep-2023 04:11:47 JST Paul Cantrell

     in reply to

     • craque sprung 🏳️‍🌈

     @dtauvdiodr Some cool thoughts here on a quick dip in. Any thought of writing up some highlights as a blog post? Seems like that would go over well.

   • Embed this notice
     craque sprung 🏳️‍🌈 (dtauvdiodr@c.im)'s status on Friday, 29-Sep-2023 04:11:48 JST craque sprung 🏳️‍🌈

     in reply to

     • Alex Rock

     @inthehands @pierstoval

     It's become multifaceted too. There are a lot of different kinds (google sre has their own official list for example, and it isn't short).

     Great conversation I had about tech debt with some other SRE folks not too long ago:

     https://youtu.be/akLl-RDfwC4

   • Embed this notice
     Paul Cantrell (inthehands@hachyderm.io)'s status on Friday, 29-Sep-2023 05:10:13 JST Paul Cantrell

     in reply to

     • John Wilson

     Fair question @crazybutable:
     https://mastodon.social/@crazybutable/111144436496030487

     If the developer isn’t the domain expert and/or product manager, they need to know what the software should do. If that’s not “requirements,” what is it?

     Goals. Constraints. Expectations. Assumptions. Wishes. Notions.

   • Embed this notice
     Paul Cantrell (inthehands@hachyderm.io)'s status on Friday, 29-Sep-2023 05:14:32 JST Paul Cantrell

     in reply to

     • John Wilson

     Very, very few things that we call “requirements” in software are in fact requirements. Most of them are little more than high-level checklist items.

     Software is all about making wise decisions about tradeoffs. The way to achieve that is to have shared clarity about goals and constraints, and thus allow maximum flexibility in execution.

     “We could make things far better by choosing to have a different problem” is one of the most important thoughts in software.

     @crazybutable

   • Embed this notice
     Paul Cantrell (inthehands@hachyderm.io)'s status on Friday, 29-Sep-2023 05:18:59 JST Paul Cantrell

     in reply to

     When we do choose to promote a todo item to the level of “requirement” — that is, a non-negotiable, immutable thing the implementation team •must• do or the results will be a failure — it’s usually one or both of these things:

     (1) Institutionalizing and feigning immutability for a large-scale decision which would be prohibitively expensive to adjust mid-process

     (2) Attempting to slough off blame for expected project failure (“Not my fault! Look at the requirements!”)

   • Embed this notice
     Paul Cantrell (inthehands@hachyderm.io)'s status on Friday, 29-Sep-2023 05:24:40 JST Paul Cantrell

     in reply to

     “The software must not determine whether an arbitrary input program halts” ← Now THAT is truly a requirement

     “The app must send a JSON query to the /foo endpoints when the submit button is clicked” ← That is a specific design which might change in any one of a dozen ways in the course of implementation (protobuf instead of JSON! /foo is renamed! autosave instead of submit button! etc etc etc)

   • Embed this notice
     Paul Cantrell (inthehands@hachyderm.io)'s status on Friday, 29-Sep-2023 05:27:18 JST Paul Cantrell

     in reply to

     • Enema Cowboy

     @Enema_Cowboy
     It can be maddening.

     A thought I’ve found helpful: expressing thoughts about the problem domain with the kind of explicit clarity necessary to write software •is a developer skill•, not a domain expert skill. That kind of metacognition is in fact one of the hardest things about writing code. We can’t expect everyone to think that way!

   • Embed this notice
     Enema Cowboy (enema_cowboy@dotnet.social)'s status on Friday, 29-Sep-2023 05:27:19 JST Enema Cowboy

     in reply to

     @inthehands Thanks, I will consider that. What has been confounding me is getting relatively simple answers to detailed questions about the problem domain.

   • Embed this notice
     Paul Cantrell (inthehands@hachyderm.io)'s status on Friday, 29-Sep-2023 05:28:37 JST Paul Cantrell

     in reply to

     • Enema Cowboy

     @Enema_Cowboy
     It’s thus our job as developers to suss out and formulate a good logical model via specifics (examples, mockups, scenarios, etc), and then test it by getting domain experts to react to those kinds of specifics — not to get the domain experts themselves to either express or verify the logical model in its abstract form.

   • Embed this notice
     Paul Cantrell (inthehands@hachyderm.io)'s status on Friday, 29-Sep-2023 05:38:39 JST Paul Cantrell

     in reply to

     • Rob Napier

     @cocoaphony
     Your thinking is quite close to mine, I think. I’d be happy if folks consistently used the word “requirements” to mean “constraints that are out of our control.” Not only is satisfying such constraints isn’t a sufficient condition for success (just as you said), but such constraints usually aren’t even the •starting point• for success.

     Don’t we have •goals•? Aren’t they the determiner of success? And shouldn’t they be flexible, adapting to changing information and conditions?

   • Embed this notice
     Rob Napier (cocoaphony@mastodon.social)'s status on Friday, 29-Sep-2023 05:38:40 JST Rob Napier

     in reply to

     @inthehands My definition of "requirement" is a thing that, if it were impossible to deliver, we would cancel (or at least seriously reconsider) the project. If its impossibility causes the "requirement" to vanish, then it was never IMO a requirement.

     BUT! devs often forget that minimally delivering just the "requirements" may still result in a worthless product, and the goal is a worthy product. Checklist-obsession is not useful. The goal is to delight; not barely meet "requirements."

   • Embed this notice
     Paul Cantrell (inthehands@hachyderm.io)'s status on Friday, 29-Sep-2023 05:40:02 JST Paul Cantrell

     in reply to

     • Rob Napier
     • John Wilson

     @cocoaphony @crazybutable

     Yup. “Assumptions” in my list above. Super super important.

     And “It wasn’t in the requirements!” is never an excuse for missing something like that.

   • Embed this notice
     Rob Napier (cocoaphony@mastodon.social)'s status on Friday, 29-Sep-2023 05:40:03 JST Rob Napier

     in reply to

     • John Wilson

     @inthehands @crazybutable I think we often forget that part of the job is learning the space we're working in. If we refuse to learn anything about our client's experiences, we cannot deliver them good software. No amount of checklists will fix that.

     A common example I've used is a car. You expect any car you buy will have a steering wheel, brakes, headlights, and the like. You expect the car manufacturer to know you need them even if you don't ask. They can't say "I don't know your use case."

   • Embed this notice
     John Wilson (crazybutable@mastodon.social)'s status on Friday, 29-Sep-2023 05:42:33 JST John Wilson

     in reply to

     @inthehands I guess my org uses “requirements” in a couple of different senses. The general case is “gathering requirements” and that’s what you are calling goals and constraints.

     And the second sense is very narrow and tactical: we break each feature up into user stories and we say the story isn’t done unless the requirements are done. But there’s a big gap between the two, for the design department to turn requirements (hopes and goals and constraints) into concrete features

   • Embed this notice
     Paul Cantrell (inthehands@hachyderm.io)'s status on Friday, 29-Sep-2023 05:42:33 JST Paul Cantrell

     in reply to

     • John Wilson

     @crazybutable
     That’s standard usage in dev circles, yup. And it’s reasonable to break software down that way. And yes, I realized it’s a term of art.

     Still, it’s the word “requirements,” and the mindset it implies, that I object to. It sounds like “things teacher said you must do to get an A,” which isn’t even a good way to thinking about •school•, let alone software development.

   • Embed this notice
     Paul Cantrell (inthehands@hachyderm.io)'s status on Friday, 29-Sep-2023 06:03:22 JST Paul Cantrell

     in reply to

     • John Wilson

     @crazybutable
     I think we’re on the same page here. My argument is that the word itself exerts a kind of gravitational pull toward the type of dysfunction you’re describing. I like vocabulary that instead encourages shared understanding and clearheaded thinking about the many paths to the true goals across the team and throughout the process.

   • Embed this notice
     John Wilson (crazybutable@mastodon.social)'s status on Friday, 29-Sep-2023 06:03:23 JST John Wilson

     in reply to

     @inthehands heh. We are so much more flexible in our use of the word that it’s hard for me to see it in that sense.

     But in the past we did contract software development and when the “requirements” become contractual requirements, and then something breaks down its *KNIVES OUT*

     (I’m kind of getting off topic though)

   • Embed this notice
     Paul Cantrell (inthehands@hachyderm.io)'s status on Friday, 29-Sep-2023 06:06:24 JST Paul Cantrell

     in reply to

     • Rob Napier
     • John Wilson

     @cocoaphony @crazybutable
     Strong agree here. Even if developers aren’t making a big design decisions and aren’t the ones researching the problem domain or the product strategy, there are still a million small missteps a developer can make without a healthy sense of context — and also developers are often the first to be in the position to spot when big underlying assumptions are wrong, or that the whole experience just isn’t going to make sense.

   • Embed this notice
     Rob Napier (cocoaphony@mastodon.social)'s status on Friday, 29-Sep-2023 06:06:25 JST Rob Napier

     in reply to

     • John Wilson

     @crazybutable @inthehands IMO it's an unhealthy shop if the designers systematically know more about the customer than the developers do. That suggests developers who are too isolated, and need to be more engaged with the product and the users.

     I've had great experiences with designers who've incredibly improved my work. But I've never personally seen great software from orgs where design held unilateral approval decisions. Those are the orgs I've most often seen make terrible "x-platform" UX.

     Paul Cantrell repeated this.
   • Embed this notice
     John Wilson (crazybutable@mastodon.social)'s status on Friday, 29-Sep-2023 06:06:26 JST John Wilson

     in reply to

     • Rob Napier

     @inthehands @cocoaphony When I’m done coding something, it goes to the design department to get approval, then the QA department, then it’s done.

     Since the design department is the most familiar with the requirements (goals and constraints) they can let us know if we got it right.

     (If the design department gives us something impossible or dumb to do, we try to step in and let them know early in the process, but they want to build something usable and so do we, so we mostly work together)

   • Embed this notice
     Rob Napier (cocoaphony@mastodon.social)'s status on Friday, 29-Sep-2023 06:06:42 JST Rob Napier

     in reply to

     • John Wilson

     @crazybutable @inthehands I've heard many devs say "I don't know how this feature will be used. It seems dumb, but the product managers are the ones who know the customer, so I have to do what they say."

     My answer is always the same. It's our job to learn those things, and they're learnable. We may have different skills; Swift or SQL or graphic design or testing or analyzing user feedback. But every one of us is responsible for delighting our users, and we can only do that if we know them.

   • Embed this notice
     Paul Cantrell (inthehands@hachyderm.io)'s status on Friday, 29-Sep-2023 08:52:14 JST Paul Cantrell

     in reply to

     • Susan Farrell
     • Enema Cowboy

     @joytrek @Enema_Cowboy
     Yup. And it’s such valuable work.

     In a good team, there’s a lot of trust and mutual respect, all the way along the chain from the users and stakeholders to the tiniest implementation detail. And people are listening to each other, communicating their understanding, and checking the reactions of the others via hypothetical scenarios, sketches, prototypes — anything that lets people react to each others’ various understandings.

   • Embed this notice
     Susan Farrell (joytrek@hci.social)'s status on Friday, 29-Sep-2023 08:52:15 JST Susan Farrell

     in reply to

     • Enema Cowboy

     @inthehands @Enema_Cowboy

     UX researcher here. That's part of what we do.

     We interview people who have the problem, people who need the solution, and people who use competitor products in order to understand what people need, their pain points, their workarounds, and why they do it the way they do it now.

   • Embed this notice
     Paul Cantrell (inthehands@hachyderm.io)'s status on Friday, 29-Sep-2023 10:55:12 JST Paul Cantrell

     in reply to

     • Fish Id Wardrobe
     • Rob Napier

     @fishidwardrobe @cocoaphony
     Indeed: what is truly “required” is more likely to be a social question than either a technical or business question.

     FWIW, I’ve encountered CEOs who were very glad to have implementation teams ask skeptical questions about so-called requirements, or propose alternatives, so as to prevent product disaster. And I’ve encountered CEOs who would see that as an unacceptable breach of authority. Depends very much on the people and the place.

   • Embed this notice
     Fish Id Wardrobe (fishidwardrobe@mastodon.me.uk)'s status on Friday, 29-Sep-2023 10:55:13 JST Fish Id Wardrobe

     in reply to

     • Rob Napier

     @inthehands @cocoaphony Depending on the politics involved, "constraints that are out of our control" might be very different things.

     If you're a small IT dept and you're given a bullet list by the CEO, those are unfortunately all requirements. If the head of IT is on the board, they might not be…

   • Embed this notice
     Paul Cantrell (inthehands@hachyderm.io)'s status on Tuesday, 03-Oct-2023 03:35:40 JST Paul Cantrell

     in reply to

     • Susan Farrell
     • Enema Cowboy

     @joytrek @Enema_Cowboy
     One of my students came up to me at the end of a project-based software course last spring and said:

     “Paul, halfway through the semester, you said to our team, ‘Design isn’t just frosting you put on top at the end to make it look good. It is the heart of your product.’ And I 100% ••did not believe you.•• And your were totally right.”

   • Embed this notice
     Susan Farrell (joytrek@hci.social)'s status on Tuesday, 03-Oct-2023 03:35:42 JST Susan Farrell

     in reply to

     • Enema Cowboy

     @Enema_Cowboy @inthehands The awareness in tech of the value of the discipline is much better now than 30 years ago when I started working in UX.

     Now that every company is in the web and app business, though, it's clear that each company (and each graphic designer) must learn at some point that UI design is not just visual aesthetics. That learning curve is often quite expensive, which may speed folks along.

   • Embed this notice
     Enema Cowboy (enema_cowboy@dotnet.social)'s status on Tuesday, 03-Oct-2023 03:35:47 JST Enema Cowboy

     in reply to

     • Susan Farrell

     @joytrek @inthehands

     I wish that more organizations would utilize the services of UX specialists.

     My qualifications for UX design are limited to my having read the first edition of Alan Cooper's *About Face*. I know just enough to know that UX design is rigorous work, a fact that is not appreciated by most managers.

   • Embed this notice
     Paul Cantrell (inthehands@hachyderm.io)'s status on Tuesday, 03-Oct-2023 06:40:51 JST Paul Cantrell

     in reply to

     • Susan Farrell
     • Enema Cowboy

     @joytrek @Enema_Cowboy
     Experience!

     I cajoled them into really thinking about core design questions. (Who is using this software? What experience are you creating for them? Want to create? What is the heart of it?) When they finally starting doing user testing, informal as it was, those questions popped into focus, they starting doing real design work, and the impact on the product was just gobsmackingly obvious.

   • Embed this notice
     Susan Farrell (joytrek@hci.social)'s status on Tuesday, 03-Oct-2023 06:40:52 JST Susan Farrell

     in reply to

     • Enema Cowboy

     @inthehands @Enema_Cowboy Amazing. What convinced them?

   • Embed this notice
     Paul Cantrell (inthehands@hachyderm.io)'s status on Tuesday, 03-Oct-2023 07:02:59 JST Paul Cantrell

     in reply to

     • Susan Farrell
     • Enema Cowboy

     @joytrek @Enema_Cowboy
     Always! I feel like for a lot of teams in that class, the work only begins in earnest the first time they watch somebody try to use their software. Also true for a lot of teams not in that class tbh.

   • Embed this notice
     Susan Farrell (joytrek@hci.social)'s status on Tuesday, 03-Oct-2023 07:03:00 JST Susan Farrell

     in reply to

     • Enema Cowboy

     @inthehands @Enema_Cowboy Usability testing for the win.