|
"Alternatives considered" is my favorite piece of the design doc because I only started using it a few years ago and it feels like the missing piece that gets me from "why would I waste time designing when I could just code the loving thing?" to "a document that's valuable to both the author and the reader." If there's no alternatives worth considering then either you don't need a design doc or you haven't thought about the problem enough. A list of things that are out of scope for the design is also useful, especially if there's some feature that you know your company/coworkers always try to add in.
|
#
?
May 28, 2022 14:30
|
|
|
|
| # ? May 27, 2024 17:53 |
|
|
Our internal design doc template has a "what problems AREN'T you solving" section which is honestly pretty useful at least in terms of product understanding that without a roadmap you aren't building in potential support for things Y and Z and are stopping at what you need to have X working.
|
|
#
?
May 28, 2022 23:31
|
|
|
Just like when product folk start thinking of a new feature in terms of 'MoSCoW' format. Or as I always imagine it, old style RFCs for the 21st century. The feature, Must, Should, Could, and Won't do these things.
|
|
#
?
May 28, 2022 23:54
|
|
|
Hughlander posted:Just like when product folk start thinking of a new feature in terms of 'MoSCoW' format. Or as I always imagine it, old style RFCs for the 21st century. The feature, Must, Should, Could, and Won't do these things. I love that setup. Even when I’m not using it specifically I always include a “what this won’t do” section in my design docs. It clears up a lot of miscommunication early.
|
|
#
?
May 29, 2022 00:56
|
|
|
We had a process for docs like this at a previous job of mine that was actually very useful. The team was around a dozen people and we had 2 core applications that we maintained, together forming the company's money tree. Since every new feature went into one of these two codebases and everyone worked on them, having context for why changes were being made was super important. To that end, for big features (not literally every change), we'd get everyone in a room, engineers and product, and an engineer who was assigned to would walk through their approach to implementing the feature - what sections of the code will be updated and how, any new database support needed for the feature, etc. These meetings might sound awful but they were extremely useful for having everyone understand the work that was taking place and correcting any misunderstanding or miscommunications before engineering started actually implementing anything. There would almost always be something the engineer didn't account for, and it could come from the product side or the engineering side. It slowed us down somewhat, but we didn't make mistakes in our production environment (mistakes in prod for us cost us a boatload of money, so "testing in prod" was verboten). It also has the added benefit of being a great learning time for newer and less experienced engineers to see code architecture work done in real time and explaining different parts of the system in a practical setting.
|
|
#
?
May 29, 2022 12:39
|
|
|
I have a feature X. It introduces a lot of engineering overhead, makes our product actively worse for users and has no actual benefit to us (so this isn't even a question of harmful to users to benefit us, like gathering personal info would be  ). I am not aware of any other similar SW that has this feature.I would like to kill it, but the CEO has a massive hard on for us having feature X. How do I kill the feature anyway?
|
|
#
?
May 30, 2022 17:03
|
|
|
So why does your CEO like it?
|
|
#
?
May 30, 2022 17:12
|
|
|
Make a deep fake video of Elon Musk saying that feature X was going to be included in Teslas but they decided it was too lame and only beta nerd CEOs would want it.
|
|
#
?
May 30, 2022 17:19
|
|
|
Sagacity posted:So why does your CEO like it? He is an idiot.
|
|
#
?
May 30, 2022 17:26
|
|
|
Let them waste enough time to get it to the point where you can user test it, then test it and let the users tell your CEO it’s stupid?
|
|
#
?
May 30, 2022 17:37
|
|
|
1) Comprehensively measure how pointless it is - the limited scale of use, limited revenue, etc. 2) Also comprehensively measure how much time (and money! convert engineering time into engineering money!) it's wasting. 3) Make it clear how much the CEO will look like a genius if he approves killing the feature, given how bad it is and how much money he gets credit for saving! Edit: 4) CEO explains it's a critical differentiating feature, either for some kind of standards compliance or just an extra checkmark on a comparison chart, you get fired for your audacity
|
|
#
?
May 30, 2022 18:15
|
|
|
Xarn posted:He is an idiot. All CEOs are
|
|
#
?
May 30, 2022 19:11
|
|
|
“How do I kill my CEOs stupid pet project?” is not a tech specific thing and is basically impossible.
|
|
#
?
May 30, 2022 19:15
|
|
|
Why would you try to kill a pet feature of the CEO or management in general? It's not your money, who cares if they waste time or resources on it.
|
|
#
?
May 30, 2022 19:33
|
|
|
Xarn posted:I have a feature X. It introduces a lot of engineering overhead, makes our product actively worse for users and has no actual benefit to us (so this isn't even a question of harmful to users to benefit us, like gathering personal info would be Think about this seriously: how miserable does this really make you and your team? If it causes a significant amount of after-hours calls that you have to field, or if you're getting flak for not making enough progress on other work because Feature X is sucking up too much of your time or complicating the rest of the product too much, then by all means, make a case (in a data-driven, unemotional way as suggested above). I would go through your direct manager to do this. But if it's just an annoyance, if it's something that from your perspective is only a problem for the company and its allocation of development time and money? Then my advice would be to stop caring about it, and take whatever satisfaction you can in the contributions that actually make the product better. If you can't do that, you're probably going to be stressed out a lot and I'd maybe take steps to transfer away from the product or get a new job where you can be more fully invested (but really, you're going to find bullshit like this everywhere).
|
|
#
?
May 30, 2022 19:38
|
|
|
I’m putting my vote in for deepfake Elon Musk negging.
|
|
#
?
May 30, 2022 20:32
|
|
|
asur posted:Why would you try to kill a pet feature of the CEO or management in general? It's not your money, who cares if they waste time or resources on it. Some people actually want to believe in what they work on.
|
|
#
?
May 30, 2022 20:41
|
|
|
Canine Blues Arooo posted:Some people actually want to believe in what they work on. Then tell your manager you don't want to work on it and then don't, switch teams, or switch companies. Trying to kill the pet feature is the worst possible option here. Every company is going to have some amount of work that people consider pointless. It's just a matter of how much can you tolerate and the specific type of work. I guess if you're considering bailing anyway then you can try to kill it on your way out the door, but if you want to stay then I wouldn't risk it. asur fucked around with this message at 22:50 on May 30, 2022 |
|
#
?
May 30, 2022 21:38
|
|
|
Yeah, building a case to essentially prove that the person with the most power in your org is making bad business decision is akin to career suicide.
|
|
#
?
May 30, 2022 22:42
|
|
|
Also depends on how close to the decision making you are. If you're one level down, the CEO ought to be expecting you to make these cases. If you're two levels down, see if you can get traction to the guy above first to mention it. If you're further down than that, just loving lol you're not changing poo poo.
|
|
#
?
May 31, 2022 00:14
|
|
|
just do a halfassed job of it
|
|
#
?
May 31, 2022 05:09
|
|
|
redleader posted:just do a halfassed job of it and get another job after so you don't have to deal with the fallout.
|
|
#
?
May 31, 2022 06:11
|
|
|
Collect telemetry data on the feature. Report nobody is using it. Discover your CEO didn't actually care in a kind of schrodinger's cat scenario; they would still care if you didn't post the data.
|
|
#
?
May 31, 2022 08:32
|
|
|
asur posted:Why would you try to kill a pet feature of the CEO or management in general? It's not your money, who cares if they waste time or resources on it. Canine Blues Arooo posted:Some people actually want to believe in what they work on. lmao no, we aren't curing cancer or some poo poo. I just don't like my job getting harder for stupid reasons. Volmarias posted:Also depends on how close to the decision making you are. If you're one level down, the CEO ought to be expecting you to make these cases. If you're two levels down, see if you can get traction to the guy above first to mention it. Actually I wrote up why the feature is bad idea, collected various issues that it is gonna cause, and gave it to my skip level (CTO), as they were the first shared boss between me and the other team. Nothing happened and I stopped caring, because I was not working on the product in question, so the team behind it wasting half a year is not my issue... except this month I was loaned out to that team to help them fix their poo poo Anyway, the feature is an autoupdater for our SDK, which is a library with C bindings that other business can use to develop their own SW. So now whenever the init function of the library is called, a network request is fired off to our servers to download newer version of the library, and then it is loaded into the process. And there is no way to disable the update check and download, and it is done synchronously in init, so if
For bonus points, the autoupdater is currently roughly half of all the source lines, and we don't handle a whole bunch of edge cases that I barely know about (and I know loving nothing about lazy loading libraries like this, I expect that someone who actually knows their poo poo would run screaming).
|
|
#
?
May 31, 2022 09:50
|
|
|
AskYourself posted:Yeah, building a case to essentially prove that the person with the most power in your org is making bad business decision is akin to career suicide. I’m reading this as we are about to go live having never tested in prod, this is a good reminder that I can only do so much.
|
|
#
?
May 31, 2022 13:31
|
|
|
Xarn posted:Anyway, the feature is an autoupdater for our SDK, which is a library with C bindings that other business can use to develop their own SW. So now whenever the init function of the library is called, a network request is fired off to our servers to download newer version of the library, and then it is loaded into the process. Well that sounds like a loving nightmarish disaster; good luck! Precambrian Video Games fucked around with this message at 16:31 on May 31, 2022 |
|
#
?
May 31, 2022 15:15
|
|
|
Oh my god 
|
|
#
?
May 31, 2022 15:37
|
|
|
I feel like we are pretty bad at breaking features into stories and could use some advice. We own the full stack and generally start with a UX design for the feature. This usually gets turned into one story per screen, which makes sense from a product owner perspective. The issue we run into is where do you put the backend work? Do you create a new story that blocks all the rest that the product team doesn’t care about? Or do you make the “first” story have the backend component and block the rest? Or some better solution, possibly involving better product owners?
|
|
#
?
May 31, 2022 15:40
|
|
|
One story per screen probably doesn't make a ton of sense. - Most tasks users will actually want to do will require more than one screen - Most screens will be useful for more than a single task
|
|
#
?
May 31, 2022 16:40
|
|
|
This specific scenario is where the metaphor breaks down, and why I don't (and others don't) use user stories for things. User stories are excellent for mainly visual content, with minor backend processing, but they fall down for things like "As a driver, I want the car to start when I use the ignition" which is a button press to the user and an absolute ton more behind the scenes. See if you can have specific tasks broken down an epic or whatever the term is now, so that the user story is an overarching goal, not one specific task, then create subtasks from there and consider those as you would the story.
|
|
#
?
May 31, 2022 17:07
|
|
|
smackfu posted:I feel like we are pretty bad at breaking features into stories and could use some advice. We own the full stack and generally start with a UX design for the feature. This usually gets turned into one story per screen, which makes sense from a product owner perspective. We do enabler stories, and explain to the PO that the work is necessary and (usually) has to go firsts.
|
|
#
?
May 31, 2022 17:31
|
|
|
Glad to hear that other people have the same issue. And yeah, we do tech enablers, it just feels like it is hacking the “user stories” system.
|
|
#
?
May 31, 2022 17:46
|
|
|
One of our big application teams ran into something recently where a particular requirement made their backend significantly more complex. They responded by broadening the scope of who's considered to be a user to include devs who talk to the backend as well as our actual end users. They're in the process of figuring out their workflow based on that, but I think they're going to come up with something that works well for them. This team doesn't do anything highly technical, though. Even with the new more complicated backend they're still basically building CRUD apps. My team, on the other hand, is building a system that does large scale computations based on a high-level specification and we only track our work using stories because that's what the tools we have support. We're absolutely not trying to map what we do to anything a user of the system might care about, let alone the end users of our applications. Jabor posted:One story per screen probably doesn't make a ton of sense. This is probably true but can depend a lot on the nature of the application.
|
|
#
?
May 31, 2022 17:58
|
|
|
smackfu posted:I feel like we are pretty bad at breaking features into stories and could use some advice. We own the full stack and generally start with a UX design for the feature. This usually gets turned into one story per screen, which makes sense from a product owner perspective. You can get quite creative with breaking down back-end stories, one of my favourite tricks is to implement a dummy endpoint that returns a hardcoded response entity and split off the "real" work to a separate ticket or two. This unblocks the front-end (it can hit the API) and you can do the real back-end in parallel. Getting used to delivering small, quick, incremental tickets is a cultural thing that's worth the effort of cultivating. If you have agile coaches try and get them involved, their opinions can have more gravitas and help shift attitudes. IMO it's fine for a ticket to be entirely back-end and not immediately deliver user-facing value. The fact it leads to later tickets that will deliver user value is sufficient. The alternative is bloated, overly-large stories and that's not in anyone's interest.
|
|
#
?
May 31, 2022 18:05
|
|
|
Speaking of weird definitions of stories and things along those lines, I looked at another team's sprint board recently and noticed that each team member had an item on the board for "overhead" like meetings and other untracked work and, uh, that doesn't seem like how you're supposed to do it???
|
|
#
?
May 31, 2022 18:05
|
|
|
CPColin posted:Speaking of weird definitions of stories and things along those lines, I looked at another team's sprint board recently and noticed that each team member had an item on the board for "overhead" like meetings and other untracked work and, uh, that doesn't seem like how you're supposed to do it??? It's not but might be a sensible defensive measure in your average SAFE hellscape.
|
|
#
?
May 31, 2022 18:30
|
|
|
If that exists, it's because a team felt it has value in factoring in how much work they can actually do. Which means they have too many loving meetings
|
|
#
?
May 31, 2022 18:56
|
|
|
Too many bean counters too if you're having to separately track that sort of poo poo. Definitely a SAFe hellscape.
|
|
#
?
May 31, 2022 19:05
|
|
|
CPColin posted:Speaking of weird definitions of stories and things along those lines, I looked at another team's sprint board recently and noticed that each team member had an item on the board for "overhead" like meetings and other untracked work and, uh, that doesn't seem like how you're supposed to do it??? We do similar fake issues at the place that I work at, and it's because we need to track our time and there's an integration between Jira and the time tracking software... it's all very very dumb.
|
|
#
?
May 31, 2022 19:07
|
|
|
|
| # ? May 27, 2024 17:53 |
|
|
Oh yeah, I for sure can picture the exact sequence of events that led to it. And, UGH.
|
|
#
?
May 31, 2022 19:10
|
|