|
|
This critter was dug up in the states - so no NHS. Maybe COBRA, depending on when it planned to retire? Too young for Medicare.
|
|
|
|
|
craig robbins MN wrote: This critter was dug up in the states - so no NHS
But it lived long before the US declared its independence.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Is that the first diagnosed case of bird flu?
|
|
|
|
|
0) We don't use branching/merging in TFS.
1) We don't have a configuration manager that should be in charge of making deployment packages.
2) We never get sanctioned time to work technical debt on our 13-year-old code base
3) We never get sanctioned time to work on developing tools that help us do our jobs better (a different kind of
technical debt)
4) It's not a software development management tool, it's a people/time management tool that doesn't allow for mistakes or problems, or delays outside the development process (usually regarding infrastructure problems).
5) Our program manager is micro-managing our development. Yesterday, he had an all-day meeting to go over ALL of the support tickets and what their status was, and he took it on himself to cancel a bunch for reasons only known to him. During the meeting, he said, "What are you guys doing with your time?", and I said, "Well right now, we're in an endless meeting listening to you complain about ticket statuses, when we could be working on the tickets we've already been assigned." That response was not well-received.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
#realJSOP wrote: 0) We don't use branching/merging in TFS.
Branching/merging is a process smell.
In thirty years (?!) of development I haven't had to use branching/merging.
#realJSOP wrote: 3) ... to work on developing tools that help us do our jobs better
TFS' API is an outstanding tool for developing these kinds of team-helpers.
|
|
|
|
|
PIEBALDconsult wrote: Branching/merging is a process smell.
In thirty years (?!) of development I haven't had to use branching/merging.
Attempting a discussion, not a rant nor anything to prove.
In a team, Branching, Merging means:
1) Production-running code is on the Main (develop, default,etc.) branch.
2) To make a change, a developer branches Main (production code), makes changes, enhancement, bug fixes --- This leaves Main (prod code) safe and sound in it's original branch.
2a) Once dev is done, code is built & handed to QA/Test
2b) Maybe QA/Test notice some things that have to be fixed in the code.
2c) Dev makes more changes (checking into branch along the way, of course) and submits to QA/Test
3) Finally the code is approved.
4) Merge the changes into Main (default, develop,) branch and deploy.
* This all means that Production code is always safe and easily retrieved from Main branch
* This means that if a dev begins doing a change and it is decided not to be used then the branch is dead & she doesn't have to pull the code out of Main (production code).
* This also means that a team of developers can work on different parts of the system at the same time (last to complete & merge to Main gets the pain though).
* Keeps things so you always have a good working copy in source control at all times.
Does this still seem like a Smell?
Just curious.
|
|
|
|
|
Quote: Branching/merging is a process smell. Disagree. There should be a release branch for each previous release, plus a development branch. Only bugs are fixed in a release branch (and damn the architecture). They must then be fixed properly in the development branch, which is also where new features are undergoing development.
modified 10-Feb-22 14:47pm.
|
|
|
|
|
We have multiple devs working on multiple apps sharing a lot code - branching/merging would really help.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Maybe you should use JIRA, a magic agile bullet that will make all your problems go away ...
(or one of these jira-alternatives[^] )
|
|
|
|
|
How many more days again till you retire?
|
|
|
|
|
July 12 2023 - that's my magic bullet.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Nice. Exactly one day before I turn 51.
|
|
|
|
|
If I understand your right: If I am under a certain age, I am not granted the freedom to make up my own mind about the value of agile/scrum. Being young requires of me that I embrace it.
You are not telling from which age you grant me the right to make my own judgements on the matter. I really hope that I am above that age.
Geek and Poke: Advanced Scrum[^]
|
|
|
|
|
Perhaps you either don't understand the context to which I replied to John or you mistakenly are replying to me on another members post, because I completely do not understand your comments in relation to my post.
|
|
|
|
|
When someone writes a post declaring rather negative feelings about agile/scrum, and you reply by suggesting that he may be near (or into) retirement, I find it quite obvious that you by that means to suggest that "The reason why you hate agile/scrum is that you are too old. If you had been younger, you wouldn't have written such an agile/scrum-critical post".
I really see no other good reason why you would be referring to #realJSOP's retirement.
|
|
|
|
|
No, I was not suggesting that John was too old. If you know the history of John's employer and working environment, it is full of frustrations and misery a lot of the time.
So, when I mentioned he was close to retirement, I meant that he will soon not have to deal with all the crap he deals with.
John, I am sure, is more than capable of working in agile/scrum, regardless of his age.
Cheers.
|
|
|
|
|
Slacker007 wrote: John, I am sure, is more than capable of working in agile/scrum, regardless of his age.
Hey hey hey! Let's not get carried away with assumptions.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
#2 and #3 are not unique to Agile/Scrum. They're a sign of imbecilic, blinkered management, which is a widespread problem.
|
|
|
|
|
we have a lot of signs of imbecilic, blinkered management.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Since it is a government organization that is exactly what I would expect. Even a moderate level of competence would be a surprise to me.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
0 should at a minimum have a Dev branch and a Prod branch. If something major pooches Dev, you can start a new Dev from Prod
Agree on #2
We recently switched to a new UI. It took a lot of scrambling to get the artifacts for the previous iteration removed from the code.
We need to be able to have dedicated sprints to “take out the trash”.
4 infrastructure: why Developers came up with DevOps and infrastructure as code!
|
|
|
|
|
#realJSOP wrote: 3) We never get sanctioned time to work on developing tools that help us do our jobs better (a different kind of
technical debt)
Is that an agile thing?
It's hard to sell the ROI to management who also have to sell it up the chain. In my situation, I'm forced to lie about it (working on productivity tools) or worse, do it on my own time/dime.
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
It's a a side-effect of agile. We're only supposed to work on assigned tasks. Most of the technical debt we resolve is done on our own time - like the deployment tool I wrote, or the config-less connection strings module I wrote, or the entity factory app I wrote, or the refresh process forensic inspection tool I wrote. I could go on, but I think you get the point...
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I think any one of your items would make a great entry on a "Top 10 Signs You Should Bail" list.
Just today I got tacit approval to address a #2 item. We have a piece of equipment-wrangling code that got its start 20 years ago. It's been through 6 or 7 hands in that time and an integral part of several different products. There have been any number of chain-saw edits to adapt it each time. The end result is less than coherent, and its behavior on the newest product has... bizarre edge-condition issues. I volunteered to take it over when one of our team quit and we reshuffled responsibilities. Yeah, I know volunteering is stupid. This thing, however, should be easy. Anyway, there was a gripe from the product prototype machine. This was the first time I'd done a deep dive into this code. None of it is particularly bad, it's just there's inactive cruft laying around and you can't see the forest for the kudzu. I told my boss in our team meeting today that I'd set up a branch of the component and I was developing a new version as a "learning experience" while I reviewed the original. Josh knew this was some of my finer grade BS, but he let me get away with it. Part of it may have been the fact that his hands were the last ones in this body of code before it landed in my lap.
In my role as the DSJB(*) I've spent significant time on item 3. We have a diagnostic tool that is a Leatherman™[^] multi-tool for debugging our multi-processor, multi-threaded applications. Our home-grown automated build process ensures our products go from source control to compilers to install media, internal publishing, and change documentation without any manual steps or intervention.
(*) Departmental Shit-Job Boy
Software Zen: delete this;
|
|
|
|
|