June 18, 2019 at 11:12 am
MVDBA (Mike Vessey) wrote:while it's slightly off topic, I worked with a team that mixed the V model (kinda like waterfall) and agile.. it had an unfortunate nickname of "vagile"
What did you develop? Properly enumerated numeric information systems and did it support binary uploaded transfer tables? 😀
hahahaha I like it . but it was worse than you can imagine … it was SAP , there was a lot of "constantly updating nonsense tasks"
jeff you have a filthy mind
although there actually was a man on the project team called peter ennis .. his email address was amusing (lets just say first letter of firstname followed by surname), we called him willy!
MVDBA
June 18, 2019 at 11:34 am
Heh... I was in the military a long time ago. I got used to strange names that had weird abbreviations. Even my Dad had to put up with some of it. He was a chemical engineer working for the Navy and he once worked on a team that was responsible for the problem conversion of black waste water to something a whole lot less benign. They official government name of the team was the Sanitary Handling Investigation Team.
Of course, not all naming had dark connotations. My Dad, Brothers, and I were working on creating a special diving suit for Seal Teams. It was meant to be a combination of self propulsion and keeping the diver warm. I named it project SCHAMU (kind of like the killer whale) and it stood for Self Contained Heating And Mobility Unit.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 18, 2019 at 1:34 pm
Jeff Moden wrote:MVDBA (Mike Vessey) wrote:while it's slightly off topic, I worked with a team that mixed the V model (kinda like waterfall) and agile.. it had an unfortunate nickname of "vagile"
What did you develop? Properly enumerated numeric information systems and did it support binary uploaded transfer tables? 😀
hahahaha I like it . but it was worse than you can imagine … it was SAP , there was a lot of "constantly updating nonsense tasks" jeff you have a filthy mind although there actually was a man on the project team called peter ennis .. his email address was amusing (lets just say first letter of firstname followed by surname), we called him willy!
I used to know a Paul Ennis at school. And his brother, Tim. Their parents must have been comedians.
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin
June 18, 2019 at 1:43 pm
MVDBA (Mike Vessey) wrote:Jeff Moden wrote:MVDBA (Mike Vessey) wrote:while it's slightly off topic, I worked with a team that mixed the V model (kinda like waterfall) and agile.. it had an unfortunate nickname of "vagile"
What did you develop? Properly enumerated numeric information systems and did it support binary uploaded transfer tables? 😀
hahahaha I like it . but it was worse than you can imagine … it was SAP , there was a lot of "constantly updating nonsense tasks" jeff you have a filthy mind although there actually was a man on the project team called peter ennis .. his email address was amusing (lets just say first letter of firstname followed by surname), we called him willy!
I used to know a Paul Ennis at school. And his brother, Tim. Their parents must have been comedians.
Heh... and I well imagine they both had mo den enough with the jokes that would abound. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
June 18, 2019 at 1:46 pm
In a previous life we were developing a software layer to report across all of our hardware implementations. Each division ran on a different platform and reporting on a customer's complete business with us was an exercise in cut-and-paste and sneaker-net. During the kickoff presentation for the Business Information Gateway (BIG) project, I interrupted the CIO saying "That's Notorious BIG." From then on the logo for the project was a bullet hole.
------------
Buy the ticket, take the ride. -- Hunter S. Thompson
June 18, 2019 at 1:57 pm
Too funny.
On a similar note, I'm not one to use Hungarian Notation (Phil Factor calls it "tbl-ing") for object names but I ran into a bit of a dilemma quite a while back. Of course, I have a Tally table in most of my databases but I also needed an Itzik Ben-Gan type of function that would provide the same functionality in a readless fashion. I couldn't name the function "Tally" because of unique naming requirements. A lot of people would have named it fnc_Tally. Instead, I decided to simply call it fnTally. It worked out well because, when people asked me why their code had performance issues, I could tell them, "Well, if you had used the fn Tally function like I told you, you wouldn't have this problem" without it actually being an HR violation. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
June 18, 2019 at 2:03 pm
It worked out well because, when people ask me why their code had performance issues, I could tell them, "Well, if you had used the fn Tally function like I told you, you wouldn't have this problem" without it actually being an HR violation. 😀
LOL
I have something similar when people say to me there is no I in Team.
I reply
and there is no F in Point
🙂
Far away is close at hand in the images of elsewhere.
Anon.
June 18, 2019 at 2:17 pm
BWAAA-HAAA! I've actually not heard that one before, David. I'm going to remember that one!
Shifting gears a bit and on the subject of people saying "There is no "I" in "Team"", I remind them that a great team has some good bit of diversity in it and that each individual brings something essential to the team that no other team member can. In other words, a great team is made up of many "I's". When they still insist that "There is no "I" in "Team"", I show them this picture I made in Corel Draw...
... and remind them that you need to fill in the gaps to have a proper team.
It also means that everyone has a position even if it's "only" a support role instead of being one of the "major" players.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 19, 2019 at 9:01 am
Jeff Moden wrote:It worked out well because, when people ask me why their code had performance issues, I could tell them, "Well, if you had used the fn Tally function like I told you, you wouldn't have this problem" without it actually being an HR violation. 😀
LOL I have something similar when people say to me there is no I in Team. I reply and there is no F in Point 🙂
haha... I have a similar one with my junior devs
dev :"can i have access to live"
DBA :"no way"
dev : "why"
DBA : "because there is no f in way"
MVDBA
June 19, 2019 at 10:45 am
Where I work the dashboards and performance metrics for production applications and infrastructure is available to all in all environments.
Being told something is one thing. Being shown is another thing entirely.
On the subject of agile nothing in agile says don't plan, don't document, don't <<insert essential discipline here>>. Lack of planning is not a weakness if agile. It is a weakness either of understanding or of the people implementing agile approaches.
I keep reading https://ronjeffries.com/ as he addresses a lot of misconceptions about the movement of which he was one of the founding fathers.
If what you are building is successful it will change the way in which the organisation works. The theory of constraints says that there is ONE key constraint at any one time. If your work addresses this constraint then another will emerge and it won't necessarily be one you foresaw. That is why the agile manifesto values adapting to change over following a plan. It does not mean DON'T PLAN or DON'T FOLLOW A PLAN. It means that if a change in situation occurs evaluate whether the change that has occurred requires a change to the plan.
The emphasis is on what delivers business value. There has to be a holistic view of what constitutes business value. It cannot be what delivers value for a spoilt brat screaming for a lollipop. It has to be from the point of view of sustaining a pace of work indefinitely. If that means stepping back and providing suitable metrics dashboards for the team, operational play books for the team and the consumers of their software product, then so be it.
June 19, 2019 at 11:02 am
Where I work the dashboards and performance metrics for production applications and infrastructure is available to all in all environments. Being told something is one thing. Being shown is another thing entirely. On the subject of agile nothing in agile says don't plan, don't document, don't <<insert essential discipline here>>. Lack of planning is not a weakness if agile. It is a weakness either of understanding or of the people implementing agile approaches. I keep reading https://ronjeffries.com/ as he addresses a lot of misconceptions about the movement of which he was one of the founding fathers. If what you are building is successful it will change the way in which the organisation works. The theory of constraints says that there is ONE key constraint at any one time. If your work addresses this constraint then another will emerge and it won't necessarily be one you foresaw. That is why the agile manifesto values adapting to change over following a plan. It does not mean DON'T PLAN or DON'T FOLLOW A PLAN. It means that if a change in situation occurs evaluate whether the change that has occurred requires a change to the plan. The emphasis is on what delivers business value. There has to be a holistic view of what constitutes business value. It cannot be what delivers value for a spoilt brat screaming for a lollipop. It has to be from the point of view of sustaining a pace of work indefinitely. If that means stepping back and providing suitable metrics dashboards for the team, operational play books for the team and the consumers of their software product, then so be it.
Absolutely. We began our agile journey about 5 years ago. We have gotten reasonably good at it and we still run into misunderstandings. It is a given in any methodology. In agile they surface faster and can be addressed before they are ingrained.
The theory of constraints sounds like a good teaching tool. I'll be sharing that idea internally. Thanks.
------------
Buy the ticket, take the ride. -- Hunter S. Thompson
June 19, 2019 at 12:24 pm
Where I work the dashboards and performance metrics for production applications and infrastructure is available to all in all environments. Being told something is one thing. Being shown is another thing entirely. On the subject of agile nothing in agile says don't plan, don't document, don't <<insert essential discipline here>>. Lack of planning is not a weakness if agile. It is a weakness either of understanding or of the people implementing agile approaches. I keep reading https://ronjeffries.com/ as he addresses a lot of misconceptions about the movement of which he was one of the founding fathers. If what you are building is successful it will change the way in which the organisation works. The theory of constraints says that there is ONE key constraint at any one time. If your work addresses this constraint then another will emerge and it won't necessarily be one you foresaw. That is why the agile manifesto values adapting to change over following a plan. It does not mean DON'T PLAN or DON'T FOLLOW A PLAN. It means that if a change in situation occurs evaluate whether the change that has occurred requires a change to the plan. The emphasis is on what delivers business value. There has to be a holistic view of what constitutes business value. It cannot be what delivers value for a spoilt brat screaming for a lollipop. It has to be from the point of view of sustaining a pace of work indefinitely. If that means stepping back and providing suitable metrics dashboards for the team, operational play books for the team and the consumers of their software product, then so be it.
There isn't a button to give you all the "LIKE"s that I'd like to give this post. Absolutely spot on David.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 19, 2019 at 12:33 pm
The theory of constraints says that there is ONE key constraint at any one time. If your work addresses this constraint then another will emerge and it won't necessarily be one you foresaw. That is why the agile manifesto values adapting to change over following a plan. It does not mean DON'T PLAN or DON'T FOLLOW A PLAN. It means that if a change in situation occurs evaluate whether the change that has occurred requires a change to the plan. The emphasis is on what delivers business value. There has to be a holistic view of what constitutes business value. It cannot be what delivers value for a spoilt brat screaming for a lollipop. It has to be from the point of view of sustaining a pace of work indefinitely.
You could not have described the "Phoenix project" book any better!!! - it should be mandatory reading before working in software development. 🙂
MVDBA
June 19, 2019 at 12:37 pm
And, David, thank you for the Ron Jeffries link... in particular, I really like his post on technical dept (included below).
https://ronjeffries.com/articles/019-01ff/tech-debt/
Again, there is no button that could give your post enough "Like"s.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 14 posts - 16 through 28 (of 28 total)
You must be logged in to reply to this topic. Login to reply