FWIW, I suspect these stairs have been photographed before adding wood steps that are deeper/wider. I base that on the low visible height of the bottom step. A 1.5-2 inch wooden slab would normalize the height of each step.
The paradox is that people don’t actually implement agile methodologies but rather try to shoehorn them into their waterfall mindset.
I’ve worked with a team of 10 developers (one of them tech lead) + 1 “PM”, using Test-Driven Development. The customer was the PO and was involved in the scrum process. When we had plannings, the TL+PM+PO had already prepared the User Stories for us, so they were easier to guesstimate. The customer/PO took part in reviews of deliverables and provided feedback. Overall it worked nicely.
Most other teams i’ve worked with were not agile, but fragile, waterfall in disguise. Never works.
Right now i work alone (and one QA) maintaining a legacy project plus handling the CI/CD maintenance and whatever else hits my fan. It’s agile when it suits the suits, otherwise they’re in charge, i have no say. Just yesterday i was handed a task by the boss of the boss, which will occupy me for a few days. I could go on ranting but i’d hit some character limit.
The paradox is that people don’t actually implement agile methodologies but rather try to shoehorn them into their waterfall mindset.
After several decades and several methodologies in a number of fields, I’ve concluded that very few actually think methodologies are useful. It’s always pick and choose or mix and match the various elements. This is all driven by the belief that my business is a special little flower and needs it’s own custom little process that only I can invent.
I had a PM postpone a critical part of a project since June, the hard deadline is on September 15th… I’ve insisted to start with it months ago and now he’s scrambling everyone to get this done yesterday.
I’m usually one to think folks exaggerate the dangerousness of strange staircases in posts like these, but yeah these are definitely gonna cause a few accidents.
No you won’t, because even if everything is perfectly specced you’ll encounter unforeseen issues during implementation. So you’ll either overestimate or underestimate the time required.
I once had a manager hand me a project brief and ask me how quickly I thought I could complete it. I was managing my own workload (it was a bad situation), but it was a very small project and I felt that I had time to put everything else on hold and focus on it. So, I said that I might be able to get it done in four days, but I wouldn’t commit to less than a week just to be sure.
The manger started off on this half-threatening, half-disappointed rant about how the project had a deadline set in stone (in four days’ time), and how the head of the company had committed to it in public (which in hindsight was absolute rot). I was young and nervous, but fortunately for me every project brief had a timeline of who had seen it, and more importantly, when they had received it. I noticed that this brief had originated over three months prior, and had been sitting on this manager’s desk for almost a month. I was the first developer in the chain. That gave me the guts to say that my estimate was firm, and that if anyone actually came down the ladder looking for heads to set rolling (one of the manager’s threats), they could come to me and I would explain.
In the end nothing ever came of it because I managed to get the job done in three days. They tried to put the screws to me over that small of a project.
Especially the other projects that were hidden on someone’s desk until a week before the deadline. And now they have two or more projects like that simultaneously
We were managing our own work with (usually generous) milestones/deadlines determined by other people. As long as we kept meeting goals, no-one looked any deeper. It gave me the freedom to literally put everything else on hold and switch 100% of my attention to this project.
This used to happen to me all the time! Except I always gave an estimate of a minimum, “six weeks”. Which was always going to be shorter than the other folks/teams who would always start with a minimum of, “three months”.
It was a trick, you see. It meant I was always the first person they asked to do anything which meant I got first pick of any given work coming down the pipe 👍. It was more than that though: From experience I knew which projects were real and which were, “management whims”. That is, projects that were going to ultimately get cancelled.
If you know how the system works you can always get a deadline extended. Especially if you, “went out of your way” to try to get it done faster than everyone else. With this knowledge in mind I would accept the, “six week” project with the anticipation that it would get cancelled after a month which happened at least 50% of the time and 100% of the time if it was a, “management whim”.
This situation was an extreme disincentive to actually work on any projects at all; because if you spent all day every day working on a project for a month and then in the 4th week it gets cancelled that means you wasted all of your time. You could’ve been surfing the web or learning new skills/frameworks/operating systems/whatever in that time!
Once I had the system completely figured out I would accept these, “six week” projects and not work on them at all for the first month (I had much better things to do, trust me). If they were still pining over it after that time I’d just request an extra two weeks which would give me a month to actually get it done. Then I’d complete the project–usually in a fucking day or two of dedicated work (e.g. “don’t talk to me; I’m not joining any conference calls today”). Then I would deliver the project on the day it was originally due: Two weeks early.
I was a hero at that company. The bosses would regularly throw my name out there whenever someone else’s project went over time or over budget, “we should’ve given this to Riskable!”
Company ended up laying me off and then re-hiring me ~1.5 years later at a vastly increased salary because they, “just couldn’t find anyone that delivered” like I did 😁
One cool thing is that the comments are self documenting. I read the program earlier and it’s quite clear what it does. Excellent accomplishment, dear colleague!
I was given a ticket for something I was still unfamiliar with at the time, as I was only about 6 months into the job. The thing I was working on was fairly complex in a very specific and niche subject, so it’s the kind of thing literally no one would know until you work at this place.
I made the requested changes per the ticket as best as I understood them and fired the ticket back to the BA. Almost a month goes by and the project lead calls me up telling me it wasn’t done properly. After going through what the issue is I remark that now I understand better and will update it. He started on a rant about how if I don’t know something I should be asking and these kinds of changes shouldn’t be left to the last minute only a day before deployment.
I merely replied that it’s difficult to ask about something when you aren’t even aware of its existence (too hard and too difficult to explain here). But what really set him off was me saying “why am I hearing about this an entire month after I finished the ticket?”
He didn’t know what to say and just hung up the call.
programmer_humor
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.