I make money on convincing the customer that it ain't broke but it will break soon. And when it does, all the competitors will already be on the new thing. FOMO works like a charm.
Another IT guy lost to Aviation
- Thread starter kaiser
- Start date
We hired lots of retired military pilots. 20 years military + another 15 or 20 at a defense contractor can leave you with a really nice nest egg when you decide to pack it all in.
Get a post mil gig that pays enough to allow you to drop that entire 30k/yr pension into an investment fund and watch it grow. A Roth IRA could work beautifully for part of it, up to the max allowed.
- Joined
- Mar 2, 2005
- Messages
- 15,263
- Location
- Southeast Tennessee
- Display Name
Display name:
This page intentionally left blank
A buddy of mine did just that, prior enlisted who retired as a Major, then picked up a great job at LockMart in Dallas. He’s sittin pretty.
Dallas (LM - Missiles & Fire Control) or Ft Worth (LM - Aero)? I was with MFC in Orlando, but half the chief engineers I managed were in Dallas so I was out there twice a month.
- Joined
- Mar 2, 2005
- Messages
- 15,263
- Location
- Southeast Tennessee
- Display Name
Display name:
This page intentionally left blank
Dallas. He was a rocket/missile infantry guy.
Cool! Mostly large ground-based Army missile systems in Dallas, like PAC-3. In Orlando we had more air launched stuff (JAGM, JASSM, HELLFIRE), plus EO and radar fire control.
SixPapaCharlie
May the force be with you
- Joined
- Aug 8, 2013
- Messages
- 16,414
- Display Name
Display name:
Sixer
I once found myself needing a job so I got a Scrum Master certification. Weeks later I was in a room with 300 professional, well paid, adults putting post-it notes on the wall and connecting them with yarn and being coached on how to properly format something called a user story. Then we hired a guy called a release train engineer because we were implementing something called "SaFe or scaled Agile".
Dumbest effing thing I have ever been a part of and I have been a part of some dumb ****. Let's hire 6 levels of management to keep 2 developers busy 2 weeks out of every month.
I quit that job and took "Scrum master certified" off my resume. Tech got weird and it hasn't recovered.
masloki
Pattern Altitude
- Joined
- Aug 23, 2011
- Messages
- 2,136
- Display Name
Display name:
Nunya
We just wrapped PI twenty freaking two. Woo. Design is outside looking in so that’s gooder, I think.
masloki
Pattern Altitude
- Joined
- Aug 23, 2011
- Messages
- 2,136
- Display Name
Display name:
Nunya
This scratches the surface…
SAFE imho goes against all that Agile preached...
SixPapaCharlie
May the force be with you
- Joined
- Aug 8, 2013
- Messages
- 16,414
- Display Name
Display name:
Sixer
For real. This is a 6 figure job. Its also why your software is so expensive now.
I recognize most of the words in this post, but they seem to be in the wrong order.
- Joined
- Jun 7, 2008
- Messages
- 23,964
- Display Name
Display name:
Bob Noel
microcrap doesn't have to convince the customer that it is broken. It forces the update. Besides, everyone knows microcrap is broken.
(I once saw a microsoft.com page proclaiming the virtues of the new version of windows NT, the new version had "tens of thousands of bug fixes")
kaiser
Pattern Altitude
- Joined
- Mar 6, 2019
- Messages
- 2,441
- Location
- Chicagoland
- Display Name
Display name:
The pilot formerly known as Cool Beard Guy
In my world - security and risk - it's already a moving target. Absolutely no need to tell you it's broken, the standards on what's secure just keep becoming more and more. So then I have to deal with all you whiny software engineers - "we just upgraded, what do you mean it's no longer secure enough??" 
schmookeeg
En-Route
More pilatus photos. Less scrum mastery. 
- Joined
- Mar 10, 2013
- Messages
- 19,562
- Location
- Oakland, CA
- Display Name
Display name:
Bro do you even lift
More pilatus photos. Less scrum mastery.
this is the way
Stan Bergey
Pre-takeoff checklist
- Joined
- Dec 30, 2021
- Messages
- 111
- Display Name
Display name:
86SierraBravo
I have no clue what I'm looking at here, and fervently hope I never have a need to know.
- Joined
- Apr 18, 2013
- Messages
- 4,266
- Location
- Live from the Grill-o-mat
- Display Name
Display name:
Mantis Toboggan, MD
CJones
Final Approach
Ha. I always use "Management by in-flight magazine", but that one works, too.
I worked for a guy 15 years ago that literally came into the office one day and told our IT manager (who I worked for) "Hey, I read this magazine article on my flight yesterday about something called 'Second Life'.. It's the way of the future. We all need to be on Second Life to market our business - let's get that going!". We both looked at each other with the YGTBSM look, but he didn't laugh or anything as he walked away. So she had to figure out how to get Second Life on everybody's office PC - including upgrades to some folks' hardware to make it happen - rather than focusing on getting the website refreshed and operational.
mark.staggs
Pre-takeoff checklist
Holy s***! I've worked as a software engineer for 20-mumble-mumble years, and this is just...gross, wrong, and I would've walked from that job, too. Or, more than likely, been so sarcastically disruptive then asked to leave.
bflynn
Final Approach
Agile has gone off track. The original idea was brilliant but what they've turned it into is worse than before. I cringe every time I see Jira mentioned as a means of managing. I've run a very successful scrum program with a backlog in Excel, 4 project teams and we delivered on time. Then someone read about these things called User Stories and Epics and management got a visit from the Good Idea Fairy.
I've also taken scrum master off my resume. Agile today violates every principle of being agile.
Last edited:
- Joined
- Apr 23, 2013
- Messages
- 6,526
- Display Name
Display name:
3G
The definition of infinite loop.
Agile can sometimes be sorta helpful for some limited types of SW design. Maybe. Constrain it and don't rely on it. What drove me insane was that people were trying to cram Agile onto hardware design, and at the wrong levels.
First of all, Agile simply cannot substitute for disciplined design and robust analysis, nor is "responding to change" a replacement for detailed and comprehensive requirements. A "working solution" in lieu of thorough documentation is difficult to assess when the definition of "working" requires a 100-page verification matrix. "Fail Fast" doesn't work very well when the hardware that fails costs millions and takes a year or more to create and the failure is a smoking hole in the desert floor.
Agile can work for certain small pieces of the design, to test out a principle at a low level and get a quick result to inform design choices, but not a final answer (I'm a big proponent of Fermi experiments to do this, BTW).
"Airline magazine management" is about the best description I've heard so far!
MarkH
Line Up and Wait
My current scrum contains 9 people, and only myself and one other are active technical contributors to the project.
rwellner98
Cleared for Takeoff
- Joined
- Jul 26, 2009
- Messages
- 1,383
- Display Name
Display name:
rw2
I've been doing agile for 20+ years and worked with Mike Beedle when he and Ken were writing their book (one of the first, if not the first, on the subject). I'm absolutely astounded at some of the comments here and really sad to read how badly people are applying what should be a pretty simple and very powerful idea.
The problem is that large organizations do not want to practice agile, they want to magically be agile. They can force the dev teams to jump through the hoops, but the rest of the organization doesn’t want to practice agile, they just want it to magically happen. Half fast has a great example and mine is similar. “Fail fast” but it better never break.
rwellner98
Cleared for Takeoff
- Joined
- Jul 26, 2009
- Messages
- 1,383
- Display Name
Display name:
rw2
My experience has been that organization size doesn't matter much. I've worked for massive companies that had groups that could do agile effectively and I've worked for small ones that basically wanted to do waterfall, but call it agile.
I will say, that "fail fast" was not supposed to be about breaking production systems. If someplace has a "but it better never break" application (e.g. I did a project for a major power company and they had legislative obligations to meet, so their production systems couldn't fail), they can still do agile. Agile doesn't mean no QA. It doesn't mean "cross your fingers and ship it". It means build things, figure out what's broken and fix them.
I did a project for Siemens back in the day, and while I have never worked in hardware my software did connect to the hardware that was being coincidentally developed. Agile was effective for both teams, so I pretty much reject the notion that incremental development, frequent building and frequent breaking doesn't work for hardware.
- Joined
- Apr 23, 2013
- Messages
- 6,526
- Display Name
Display name:
3G
And that becomes the problem as business sponsors expects an on-time, self-licking ice cream cone of a solution that only gets better over time not understanding what iterative development means.
I think the breakdown really is in expectations management and requirements definition which results in horse trading to meet a delivery timeline.
rwellner98
Cleared for Takeoff
- Joined
- Jul 26, 2009
- Messages
- 1,383
- Display Name
Display name:
rw2
Aaaaaaaand, now I want ice cream...
Seriously, that all seems fair. It's the project managers job (not the agile lead, though sometimes they are the same person[1]) to manage customer expectations. Having worked in IT prior to agile and since agile, I can assure you that project managers aren't any better or worse at managing expectations regardless of what methodology the developers are using.
[1] Coming back to this point. One of the reasons I took the job I have now is that I'm neither a project manager nor a product owner. This was very much deliberate. What I did was setup almost a professional services/development team within a larger organization and we do development work for a portfolio of (mostly) internal customers. So far it's working.
- Joined
- Apr 23, 2013
- Messages
- 6,526
- Display Name
Display name:
3G
Concur. Would that be the Technical PM or the business PM? Are we talking PMO, functional, matrixed, or hybrid structures?
Personally, it’s the gosh darn good idea fairies that muck it all up layering too much process with too many people.
Pinecone
En-Route
I am semi retired and loving it.
And I make more money than when I worked. Go figure.
TrueCourse
Line Up and Wait
- Joined
- Dec 10, 2019
- Messages
- 944
- Display Name
Display name:
TrueCourse
As mentioned at least once already. Don’t do this.
And therein lies the problem, at least in the HW world.
What's the "thing," and what defines "broken?"
If the thing is something like a portion of a circuit card that we want to breadboard, or maybe it's an actuator, or an optical assembly, Agile might be useful. If the thing is a multi-million dollar cruise missile prototype that takes two years to build, "fail fast" is going to be a disaster. Careful selection of where to apply Agile and where NOT to apply it is the key.
And then we must define what constitutes "broken." Does broken mean a soft failure, in which the item stops working but returns to operation when a test condition is removed? Does it mean a hard failure in which the device is permanently damaged? What about if the device continues to operate, but the performance is outside spec conditions? Let's also keep in mind that there are likely hundreds of performance requirements to be met, so the testing is complicated and time consuming and hence expensive.
And what about the conditions in which it breaks? We could be testing in lab conditions, in field environments, in a qualification environment, etc. And how about HALT/HASS environments? And bear in mind that these environments themselves are complex and interactive: temperature, humidity, vibration, shock, chemical exposure, radiation, electromagnetic effects, salt fog, acceleration, altitude/vacuum, etc., etc.
So breaking the item can in itself be a long and expensive process, because it might break in one environment but not in another so we have to try them all.
In the real world of complex hardware systems, it's impossible to test and break stuff in every combination of environment and performance variation. Therefore we must do much of the verification by analysis and simulation, testing enough portions of the envelope to verify the models.
Agile can be useful for some small subsets of hardware development when it's used to inform the final design. But I've seen managers try to impose it in too many areas where it won't work and use it as justification to eliminate budgets for disciplined design/analysis/simulation. Usually this happens during a proposal, where the company is trying to win a competition and give a low bid, but it comes back to bite later on in the form of overruns and delays.
AGREED!
At our place, it's the project chief engineer's responsibility to bring sanity to these insane situations. The CE is the one whose head is on the block when it comes to the technical success or failure of the project. The chief works for the engineering organization, not the program manager.
rwellner98
Cleared for Takeoff
- Joined
- Jul 26, 2009
- Messages
- 1,383
- Display Name
Display name:
rw2
I think that confuses "fail fast" with "ship to the customer and let them tell you what's broken".
That missile is composed of PCBs, servos, sensors, packaging, fuel, etc. Every one of those had to be designed, implemented/prototyped, tested, redesigned, etc, etc, long before they were put into something going out to a customer.
I don't know, man. I think we're talking past each other somehow. When I worked for Raytheon I didn't build missiles, but I went to one of the facilities a few times and we talked about a lot of things. They weren't doing waterfall. Each component (the in-house ones anyway) was prototyped, tested, tweaked, integrated, tweaked more, etc. In software we call that 'unit testing'. Then at various points full system prototypes were assembled and tested. In software we call that system testing. That's pretty agile.
Also, I googled them to refresh my memory and, I'll be damned if the guy we (I was at Raytheon Intelligence & Space) were working with at RMD isn't president of the division now. Time flies. (or, I'm old. You pick)
Yes. All those, depending on the specification for the part. Software complexity isn't any different. Acceptance criteria have to be defined or there is no way to say what is broken. Software testing is complicated. Which is why so few places do it effectively. And usually that's ok. Anyone who has ever owned a gopro can testify that lots of hardware ships that hasn't been tested effectively either.
But, in places where it matters (e.g. health and safety. missile control systems. security.) the testing is better defined and more rigorous.
Yep. Same failure modes in software. I really don't think the worlds are all that different.