|
Messyass posted:This is about designing, not about building, and it's not like Aircraft design hasn't evolved over time. The Wright brothers didn't try to design a 787. Your average huge hospital has a tiny particle accelerator for making radioisotopes to whack cancers and some medical physicists
|
#
?
Apr 12, 2019 14:58
|
|
|
|
| # ? May 12, 2024 16:02 |
|
|
Messyass posted:This is about designing, not about building, and it's not like Aircraft design hasn't evolved over time. The Wright brothers didn't try to design a 787. im pretty sure its not the first particle accelerator e;fb
|
|
#
?
Apr 12, 2019 15:00
|
|
|
It's the first particle accelerator able to hit the powers that it can hit. There's a physical limit to how small something like that can be.
|
|
#
?
Apr 12, 2019 15:11
|
|
|
csammis posted:It's the first particle accelerator able to hit the powers that it can hit. There's a physical limit to how small something like that can be. sure, there's a reason for it to exist. it's just an evolution of earlier, smaller designs
|
|
#
?
Apr 12, 2019 15:22
|
|
|
So are the projects Jawn is talking about, stand on the shoulders of giants, etc. they still take that long
|
|
#
?
Apr 12, 2019 15:38
|
|
|
The point, as I understand it, is that you can't go from the idea of discovering the mass of the Higgs boson to the LHC in a series of partially-functional two week iterations, even if you start out knowing how to build a particle accelerator in general. That makes sense. Making pure software is different because you absolutely can start with a general plan and tack on features piecemeal over time.
|
|
#
?
Apr 12, 2019 15:49
|
|
|
My favorite analogy for software development is a bridge, you don't start at one end and build the whole bridge as envisioned from point A to point B, you put down posts, throw a rope across, tie it secure, repeat a few times, get some floorboards in there, add hand ropes and safety nets (maybe), test the weight capacity at some point, eventually down the line replace the rope and boards with stronger materials, and the whole process is constant improvement upon the initial two posts and rope you started with.
|
|
#
?
Apr 12, 2019 19:57
|
|
|
Except management is sitting there the entire time saying "How can this be taking so long? You're just putting down posts and throwing ropes." After making you sit in a meeting for 2 hours asking how long you estimate the putting posts down and throwing ropes process will take.
|
|
#
?
Apr 12, 2019 20:01
|
|
|
Polio Vax Scene posted:My favorite analogy for software development is a bridge, you don't start at one end and build the whole bridge as envisioned from point A to point B, you put down posts, throw a rope across, tie it secure, repeat a few times, get some floorboards in there, add hand ropes and safety nets (maybe), test the weight capacity at some point, eventually down the line replace the rope and boards with stronger materials, and the whole process is constant improvement upon the initial two posts and rope you started with. Was this analogy devised by anyone with actual bridge-building experience?
|
|
#
?
Apr 12, 2019 20:09
|
|
|
Some people really, viscerally hate doing work over, which is basically a requirement for interim solutions. More up-front planning and discovery are appropriate for some kinds of larger projects, but if you try to build a skyscraper without a scaffold because "we only build things to last", you might be in for a real bad time.Polio Vax Scene posted:My favorite analogy for software development is a bridge, you don't start at one end and build the whole bridge as envisioned from point A to point B, you put down posts, throw a rope across, tie it secure, repeat a few times, get some floorboards in there, add hand ropes and safety nets (maybe), test the weight capacity at some point, eventually down the line replace the rope and boards with stronger materials, and the whole process is constant improvement upon the initial two posts and rope you started with. Vulture Culture fucked around with this message at 20:18 on Apr 12, 2019 |
|
#
?
Apr 12, 2019 20:14
|
|
|
We're waiting on a use case for permanent exterior walls, here's your poncho.
|
|
#
?
Apr 12, 2019 20:18
|
|
|
Kevin Mitnick P.E. posted:We're waiting on a use case for permanent exterior walls, here's your poncho.
|
|
#
?
Apr 12, 2019 20:18
|
|
|
During my most recent Scrum training, the analogy the consultant offered was that if the customer wants a car and you take six months to deliver a car, the customer will be mad for six months and then happy at the end. But if you first deliver a skateboard, then a bicycle, then a tricycle, then a car, the customer will be happy the whole time. I was like, what the gently caress? Who's going to be happy if they ask for a car and you give them a skateboard? Basically, like every dogma, you should leave the door open for reexamination when following it dogmatically feels like it's making less sense.
|
|
#
?
Apr 12, 2019 20:23
|
|
|
Bad analogies are a separate problem from the problem they're trying to fix.
|
|
#
?
Apr 12, 2019 20:29
|
|
|
Polio Vax Scene posted:My favorite analogy for software development is a bridge, you don't start at one end and build the whole bridge as envisioned from point A to point B, you put down posts, throw a rope across, tie it secure, repeat a few times, get some floorboards in there, add hand ropes and safety nets (maybe), test the weight capacity at some point, eventually down the line replace the rope and boards with stronger materials, and the whole process is constant improvement upon the initial two posts and rope you started with. "Alright boss, here's the first rope, we've got a good starting-" "Oh! Bridge is done! Great work team!" *sends convoy of buses over cliff*
|
|
#
?
Apr 12, 2019 21:08
|
|
|
CPColin posted:During my most recent Scrum training, the analogy the consultant offered was that if the customer wants a car and you take six months to deliver a car, the customer will be mad for six months and then happy at the end. But if you first deliver a skateboard, then a bicycle, then a tricycle, then a car, the customer will be happy the whole time. The other half of the problem with that analogy - which I actually really like because of how instructively bad it is - is that it's impossible, or at least hopelessly circuitous, to iteratively turn a skateboard into a bicycle or a bicycle into a car.
|
|
#
?
Apr 12, 2019 21:36
|
|
|
Messyass posted:Good, because these projects shouldn't exist and are doomed to fail.
|
|
#
?
Apr 12, 2019 21:48
|
|
|
I can stop bitching about my current work problems and start bitching about others! I have received an offer letter for a senior level position that gives me a very substantial pay boost, so now I will be able to afford more booze. Just have a few questions about benefits for their HR before I say definitively yes. Most of all, I think I'm excited to potentially stop working for a company that does SAFe. Unfortunately, even with a 2-week notice, PI Planning is next week. On the other hand, my car is in the shop with its engine in pieces right now, and it'll take at least a week to fix...
|
|
#
?
Apr 12, 2019 22:09
|
|
|
Polio Vax Scene posted:My favorite analogy for software development is a bridge, you don't start at one end and build the whole bridge as envisioned from point A to point B, you put down posts, throw a rope across, tie it secure, repeat a few times, get some floorboards in there, add hand ropes and safety nets (maybe), test the weight capacity at some point, eventually down the line replace the rope and boards with stronger materials, and the whole process is constant improvement upon the initial two posts and rope you started with. Which sounds good, but you can't build a pyramid like that. There's no solid foundation, you can't build any secret passages, you have to keep removing the cladding every time you build an addition, it's bananas.
|
|
#
?
Apr 12, 2019 23:13
|
|
|
Doom Mathematic posted:The other half of the problem with that analogy - which I actually really like because of how instructively bad it is - is that it's impossible, or at least hopelessly circuitous, to iteratively turn a skateboard into a bicycle or a bicycle into a car. The notion is that you might cheaply learn they don’t actually want a car without actually building one.
|
|
#
?
Apr 12, 2019 23:42
|
|
|
Build them a train because users don't know what's best for them
|
|
#
?
Apr 12, 2019 23:44
|
|
|
Just deliver anything. It's not going to be what the customer wants, but who cares?
|
|
#
?
Apr 13, 2019 04:04
|
|
|
Yeah, the metaphors don't really respect the non-physicality of software
|
|
#
?
Apr 13, 2019 04:29
|
|
|
redleader posted:Just deliver anything. It's not going to be what the customer wants, but who cares? No development paradigm delivers what the customer wants (magic)
|
|
#
?
Apr 13, 2019 05:10
|
|
|
CPColin posted:During my most recent Scrum training, the analogy the consultant offered was that if the customer wants a car and you take six months to deliver a car, the customer will be mad for six months and then happy at the end. But if you first deliver a skateboard, then a bicycle, then a tricycle, then a car, the customer will be happy the whole time. Your trainer hosed up the analogy. It's not that the customer is asking for a car, it's that they're asking for a way to get to the store. The reason you deliver iteratively, starting with the easiest and cheapest mode of transportation, is so you can get to the easiest method for the customer to achieve their desired outcomes. This is kind of the point of agile that is most often missed when it's being cargo-culted: the goal is not to create a specific piece of software, it's to give customers a better way of achieving their goals.
|
|
#
?
Apr 13, 2019 15:18
|
|
|
Blinkz0rz posted:Your trainer hosed up the analogy. It's not that the customer is asking for a car, it's that they're asking for a way to get to the store. All in all, this was one of the very few things the trainer hosed up. It was just unfortunate it came right at the start. They also listed several reasons why a team shouldn't use Scrum and told the management in the room to take a break and be sure before proceeding. They proceeded, of course, despite the teams obviously falling on the "shouldn't" side. That was a fun first week at that job; really established my confidence in my boss.
|
|
#
?
Apr 13, 2019 15:37
|
|
|
bob dobbs is dead posted:Yeah, the metaphors don't really respect the non-physicality of software ban physical analogies for software development. They just reinforce incorrect thoughts and open the door for dumb time-wasting counter-points. Almost no one is qualified to actually construct a bridge or an airplane or particle collider. Why is it helpful to take something they don't understand to explain something they don't understand?
|
|
#
?
Apr 14, 2019 17:45
|
|
|
Xguard86 posted:ban physical analogies for software development. They just reinforce incorrect thoughts and open the door for dumb time-wasting counter-points. I've found carpentry or plumbing analogies useful when explaining software to certain audiences - trying to explain what a cache is and the nuances of on-demand vs. precached might be a discussion that you can shortcut if anyone's ever used a tankless water heater, for instance. You just have to be careful to not explain something you understand using an analogy to something you don't understand or the audience doesn't understand or you'll end up sounding like the "internet is a series of tubes" guy.
|
|
#
?
Apr 14, 2019 18:06
|
|
|
I'll amend ban to "drastically reduce", to not be hyperbolic for the internet.
|
|
#
?
Apr 14, 2019 18:39
|
|
|
Metaphors are useful, but they all fall apart if you look at them too hard. That bridge metaphor just happens falls apart as fast as humanly possible. Like my software. Making it the perfect metaphor.
|
|
#
?
Apr 14, 2019 22:09
|
|
|
Any metaphor that likens software development to building instead of designing is stupid. I mean, the bridge metaphor would only work if all work was spent designing the bridge and building it was almost instantanious and free. Then you might actually build a bridge like that.
|
|
#
?
Apr 15, 2019 06:59
|
|
|
The bridge metaphor only works if you describe it a "Well, without tests we essentially build the bridge in zero G and then bring it down to earth to see if it works in production."
|
|
#
?
Apr 15, 2019 07:13
|
|
|
Metaphors are awesome. Even incomplete metaphors can be great for explaining some specific thing at some specific level. Of course some metaphors are much better than others, but even if a metaphor can only be applied to software development partially, it can still be used to understand those specific aspects it applies to.
|
|
#
?
Apr 15, 2019 13:17
|
|
|
Outside of college, the majority of the people I've met that spout these aphorisms tend to be bad developers.
|
|
#
?
Apr 15, 2019 13:38
|
|
|
Xguard86 posted:ban physical analogies for software development. They just reinforce incorrect thoughts and open the door for dumb time-wasting counter-points.
|
|
#
?
Apr 15, 2019 13:47
|
|
|
Would it be in bad taste to give my 2 weeks notice at the end of today, after I've already had a conversation with my manager regarding some unfortunate circumstances around my car? I have to travel to a city 60 miles away for PI planning which spand 2 days, but my car's in the shop, so they ended up getting me a hotel room and now I only have to worry about traveling up once and down once. I've already accepted an offer contingent on starting in 2 weeks, so I have to give my notice today, but I guess I'm worried they'll react poorly after having pulled a string or two on my behalf.
|
|
#
?
Apr 15, 2019 16:42
|
|
|
I want to rewind the clock on the metaphors thing and get back to complaining about interpreting Agile as meaning you deliver constant poo poo and it's fine so long as you are constantly making GBS threads. We're getting two years in on some internal tooling that does less than 50% for even the best-positioned subset of our customers. Whole sections of it are unused. A lot of this comes down to ingesting all these team's requests, removing all that contextual information, and then implementing them seemingly arbitrarily such that no particular team gets enough of an implementation that they're set to actually use it in their own production environment. Our end users don't want to be constantly QA'ing this prototype stuff and would rather the whole thing hibernate for 6-12 months before having a big debut. It's funny to me because we were basically releasing monthly and were getting pressure to release every sprint. I was actually surprised when they were complaining about that because there I was starting to automate spawning up VMs to make builds and run all our qualifications on every commit. Every release requires some little tweak to their environment. We always highlight what is necessary but it's fair to still be apprehensive about it. Of course then we're only able to support that latest release so it compels everybody to upgrade. I think a major undercurrent here is the lack of support we can provide. Given it's pretty much just two full-time developers, we just can't do this. I have suggested having something like some application engineers that can bridge the gap--especially since this is all internal stuff. It would also tighten the feedback loop since these poor folks can watch the trainwreck in their environments and look at the actual pain and suffering on some of these people's faces. At this point, I'd prefer this over having two extra developers--particularly since two extra developers would always be some electrical engineers that are fresh off the electrical engineering boat. This was a project that I had been advocating going back something like five years at this point so I have some passion for it. However, this slow trickle for resourcing has kind of shown me this all isn't working. I'm thinking fundamentally, you can't just take an under-resourced project, release it iteratively, and act like that's going to solve something other than prove you're under-resourced. That's useful information so long as you don't ignore it, but here we are. So I'm basically giving it another quarter to see if they're going to lift a finger to do a single thing for what is basically 50% of the customer base that's been completely ignored. If they won't then I think this project will be just as successful with zero developers as two and  .I think I should also acknowledge that the various release I think have generated enough trust that they think if we did hibernate on it that we'd produce what they wanted--at least for a subset of the people.
|
|
#
?
Apr 15, 2019 16:42
|
|
|
Protocol7 posted:I've already accepted an offer contingent on starting in 2 weeks, so I have to give my notice today, but I guess I'm worried they'll react poorly after having pulled a string or two on my behalf.
|
|
#
?
Apr 15, 2019 16:45
|
|
|
Protocol7 posted:I have to give my notice today If you 100% believe this, then it doesn't matter how they'll react. If you don't 100% believe this, then give notice tomorrow or Wednesday (for two weeks minus however many days).
|
|
#
?
Apr 15, 2019 16:52
|
|
|
|
| # ? May 12, 2024 16:02 |
|
|
CPColin posted:If you 100% believe this, then it doesn't matter how they'll react. If you don't 100% believe this, then give notice tomorrow or Wednesday (for two weeks minus however many days). I mean, it doesn't have to happen today by any means, but I do want to start on the date I told the new employer and I'd want to give as full of a 2-week notice as possible. On the other hand, I don't think there's much that I can do to help the transition, so aside from courtesy I don't have any real reason to give a full 2-week notice. Rocko Bonaparte posted:Would they feel bad laying you off after pulling the same strings on your behalf? Honest question. I'd only worry about it particularly if you like any of these people. I like my manager, but the upper level dev manager, and the people on my scrum team are a bit of a different story. I do not think they would feel bad, after all it's a large company and I bet my hotel room is a drop in the bucket.
|
|
#
?
Apr 15, 2019 17:00
|
|