selenite0: (desire consequence)
One of the minor flurries in Washington DC right now is a line item in the defense budget an alternate engine for the F-35. Not something I'd care that much about if I wasn't working on that plane. The idea is that having a second company making engines for the plane will provide a back-up against problems and cost savings from competition. Given that both the current and previous administrations have tried to kill that piece of the program it's not that widely held an idea. The case against it is pretty simple--why pay for two designs and production lines when you only need one to get the job done?

So various op-eds are appearing extolling the virtues of competition and offering the historical precedent of the competing F-16 engines. Yes, both companies would have a better incentive to improve on cost and quality as they vie for each year's batch of engines. But everybody offering that argument seems to be just fine with the engines going into a single fighter design produced by one partnership. If competition is such a great thing wouldn't more of it be better? In the absence of those arguments it feels like a typical effort to defense Congressional pork barreling.

I'm not even hoping for someone to question whether it's a good idea for a single plane to replace the F-15, F-16, F-117, F/A-18, A-10, and AV-8.
selenite0: (Kermit)
"The boat is sinking and you are the only one who can help me out. By the time you get this message I may have drowned but please try to call me anyway."

You'd think I could go to one meeting without someone panicking.

Symbolism

Apr. 23rd, 2009 04:00 pm
selenite0: (Sisyphus sign)
Our current "quality" initiative is being promoted with pretty posters in the major hallways. For emphasis the poster are in cases, big glass-front boxes with 3 or 4 inches of depth for the poster to be displayed in. The current version is praising a particular bottom-rank employee for his attention to detail. The posters were put up with weak glue, so they've all come off the back of the box and are slumped against the glass. It's been like that for a couple of weeks now. They're still readable even with all the wrinkles, it's fairly stiff cardboard. But I wonder what impression this "attention to detail" message makes on the test pilots.
selenite0: (Sisyphus sign)
The Chief Engineer has directed that each metric graph is to have an indicator icon showing current status level and the direction of the trend. I've obediently added circles and arrows. I've been denied permission to add a paragraph on the back of each one explaining what it was.
selenite0: (Sisyphus sign)
If you've ever put on white gloves and gone out to play in a mud puddle, you noticed the puddle never got glovey.

Yeah, that captures a lot about this job.
selenite0: (Karl with beard and hat)
I re-read a few old Heinleins recently. I suddenly understand why he may have thought Starship Troopers wouldn't get much reaction for it's political content. Most of the juveniles don't have much politics but Space Cadet is about joining the enforcement arm of a world government. This leads to a conversation between Our Hero and one of the academy instructors going roughly like this:

"Sir, when I was on home leave my mom got upset about how the Patrol could nuke our country."

"Well, son, to keep the peace the Patrol has to smack down any country that acts up. That's why we insist on you swearing loyalty to the Patrol instead of your country."

"Yessir, but that means I might have to drop on a nuke on my home town someday. I'm not sure if I could do that, sir."

"No worries, if your ship is ordered to nuke your home town the captain will have you confined to quarters."

"Oh, that's all right then."

Kinda puts restricting voting rights in perspective, doesn't it? The first thing our hero saw arriving at the Patrol was "Quis custodiet ipsos custodes?" From the rest of the book the answer seems to be "no one," which historically has led to bad ends. The origin of the Patrol is described in the short story "Solution Unsatisfactory" and I still agree with the title.

***

Had my first World PvP honor kill last night. A level 70 belf paladin was attacking the inn in Honor Hold and I took my level 65 warrior to help whack him. Didn't do much damage, but a friendly tree kept me alive and eventually the belf ran out of mana and took off running. I didn't maneuver well enough to stay with him so I was watching him run out the gate with a pack of NPC guards following, too far behind to attack him. Eventually he'd get far enough away the guards would give up and he'd be home free. Then the game decided I was "out of combat" since X seconds had gone by without him trying to hit me or vice versa. Charge. Hamstring. And the guards finished him off.

Note that this wasn't my first World PvP kill. But the guy who rezzed right next to me while I was torch tossing in Exodar doesn't count. He was 15 levels below me. Hopefully he's learned to not suddenly appear next to skulls.

***

My MS paper on the history of the NPOESS program got yet another piece of fan mail. This reporter is working on "bungling in federal contracting" and wants to chat about NPOESS as an example. Thanks, not interested in destroying my career. I'd be tempted if I thought I'd be able to get across how the problems are built in from the beginning by government constraints. Looking at his prior work I suspect he's already written a story about evil businessmen stealing from the government and just wants some quotes to support his conclusions.

***

Another fun Warcraft moment. I was on defense in Alterac Valley. We were getting stomped. After one attack on the general I was left the only player alive in the bunker. Four+ horde 70s came in. Charging them was instant death for me, but they didn't want me interfering as they killed the general (which would automatically win the battle). So they started shooting and dotting me. "Ah, it's just a 65, we'll kill him with the dots and then take the general." I just had to stand there and take it, plinking them with my crossbow (no visible effect). While that's going on the victory screen popped up: "Alliance Wins". I stalled them enough for the Alliance offense to get to their general first. I had a huge laugh.

***

Had an ER visit on Saturday night after splashing boiling water on myself. 2nd degree burn on the belly, nothing critical, but very annoying. [livejournal.com profile] celticdragonfly's been taking good care of me. A big part of the annoyance is that I'd just gotten started exercising again after dealing with another problem. It's always something. I also felt bad about making the whole family miss church but after driving me back home at 3am Laura needed sleep and I wasn't up to driving.

***

Jamie's getting better at talking. He's starting up actual conversations. Usually this is a way to avoid going to bed or potty-time or something, but hey, it's progress.
selenite0: (can't take2)
Not, amazingly, a meme, though maybe I should turn it into a quiz.

[livejournal.com profile] montedavis challenges all space cadets to confess Which X-Treme Spacer Are you?

I clearly fall into "Free-Fall Enterprise" and "Skunk Wonks" except I've done too much math to hold to the former and have too many responsibilities (>0) to be the latter.
selenite0: (can't take2)
My former employer made the news again, this time for a good reason. They've announced a new design of their tourist rocketplane. This is three designs past where it was when I left. I helped produce this concept:



That was the first stage of a cargo launcher. The grey compartment in the middle opened to release a satellite and upper stage before reentering. This was right when Iridium was going bankrupt and the market for LEO commsats went *poof*. So I went back to my old job and the rest of the company converted it into a tourist vehicle. When the new guard took over they announced a new design based on a Learjet fuselage. That's out in the latest one, they're doing a from scratch structure, and I'm not at all surprised. Their design does have a few features that intrigue me.



The first bit that catches my eye is the canards (fins by the nose) and T-tail. The old crew had worked under the assumption that flat pieces smaller than the wings couldn't handle reentry. Looks like all that wind-tunnel testing says differently.

The jet engines are now afterburning and the rocket is ignited at 40,000 feet. They say this increases total thrust-to-weight by 50% so I suspect they increased the ignition altitude so they could use a larger nozzle without flow separation issues. The engine is a modification of an Atlas vernier, which is braver than the old design. We'd worked to the rule that any engine development would go over schedule so we only designed to off-the-shelf parts.

Another big concern for us was making sure the jet engines wouldn't have to endure the heat of reentry. The easiest way to tell the difference between design iterations was to check the location of the engine inlet, which always had a solid door blocking it during reentry. But the new team says they "Don't need to protect inlets during reentry". If the engines can handle the maximum reentry heat and pressure I'm impressed. Though it may be that they've positioned the engines in the lee of the wings so the reentry loads will be reduced to what they can handle.

The article says the trajectory would be "nearly vertical" which surprises me quite a bit. I can't help wondering if the reporter got it wrong. Wings can give you a good boost on the way up by counteracting gravity, but you need to have a relatively shallow trajectory to get the best use of them (it's a complicated optimization problem). I'd gone round on this once with a professor who'd done an analysis of the launch vehicle concepts out there and (in my opinion unfairly) ranked assisted-horizontal-take-off very low. Turned out he was constraining the first stage to be vertical at 2nd stage separation and that hurt performance. The 2nd stage benefited from all the horizontal velocity the rocketplane had as orbital velocity needs to be horizontal anyway. Then again, that's not an issue for tourists. What a vertical trajectory does for tourists is maximize the peak Gs on reentry. That's acceptable if the peak isn't too high.

I'll be watching Rocketplane as they build this design and I wish them the best of luck.
selenite0: (Kill the unfit)
Rocketplane Kistler, the remnant of my onetime employer, made the Wall Street Journal today. Not in a good way. Their financing deal has fallen through, which means they won't be able to assemble the rocket and carry through on their NASA contract or promises to Oklahoma (which gave them a bunch of money).

Have to say I'm not very sympathetic to their troubles. The vehicle the company was working on when I left was completely unsupported by the market. The tourism rocketplane they switched to when they moved to Oklahoma didn't thrill me but could work. But then they decided to merge with Kistler Aerospace. That monstrosity is an attempt to take a conventional expendable booster and redesign it to be reusable. It's already burned more money than most of the other rocket start-ups combined, leaving a bunch of parts awaiting assembly into a ridiculously unreliable RLV. So by hooking up with Kistler they doomed whatever chance they had of making a working rocket.

I have no clue what the hell they were thinking.
selenite0: (Beware the Engineer)
Aerospace and software engineering have many tales of huge projects that ate incredible amounts of resources and then failed, sometimes completely, sometimes producing something with a fraction of the capability originally desired. There's a ton of case studies on them, sometimes whole books of them. These get blamed on forcing the technology beyond achievable limits, requirements creep, poor management, lack of resources, etc. I think all of those come down to one problem—too many requirements.

The requirements I'm talking about here are:
1. Top level. They describe what the system must do, not just a part of it. A complicated vehicle can have many, many derived requirements allocating the top level ones to each subsystem, but the derived ones aren't part of this discussion.

2. Top priority. Any requirement that can be sacrificed to meet another one isn't really a requirement, it's a goal, something optional. Of course, how the requirement is designated officially may not match that definition. If a "goal" has to be met or the project loses funding, then it's really a requirement and equal to all the other "top" priority ones.

3. Not just technical. Any constraints on the schedule or budget for a project count as requirements. If the project has to stay under $1.5M/yr, deliver the production version for $3000 each, and be shipping by 6/1/2009, that's three more requirements. Other constraints count too—if a specific development methodology or tool set must be used, that's a requirement. So is a security regime imposed on the project staff (classified, ITAR, proprietary—they all complicate things).

4. Not just formal. The informal requirements on a project can be the most difficult ones. US government projects are infamous for these . . . despite thousands of pages of requirement studies, the design can be driven by an "understanding" that work will be done in a particular Congressional district, or the employment level at a NASA facility will not be cut.
The more requirements there are on a system the more likely it is that two or more of them will directly conflict. Ideally such conflicts will be recognized before the project gets go-ahead, but there are projects that never resolve those conflicts and instead will thrash about trying to square the circle without realizing (or admitting) what the problem is. But fixing them isn't enough to assure success.

Even if all the conflicts are carefully ironed out of the top-level requirements the project's chance of success will depend on the number of requirements:



Every requirement added reduces the chance of success.

Everone accepts that you can't get everything you want. Lots of engineers have a sign saying "Cheap, Fast, Good: Pick Two" in their cubicles. But even if you "pick two" you haven't capped the number of requirements for your system.

Technical performance—"good"—can go in many directions. The more different tasks the system has to do the less the designers can focus on any one of them. In practice each task gets assigned to a different design team, with the project management and/or systems engineers trying to make sure they don't interfere with each other's performance.

Let's look at an example: the often longed-for flying car. Even if you don't set any limits on the cost or schedule, there's going to be a lot of requirements describing what you want it to do: Speed X in the air. Speed Y on the ground. Road handling characteristics. What kind of fuel it takes. Cargo capacity. How many passengers and how much room they get. Essentially you'll be adding the requirements for a Cessna 150 to those of a Mazda Miata, with only a small percentage being eliminated in the overlap.

Doubling the number of requirements doesn't just double the complexity of your design. When you design a part to meet a particular requirements, you have to look at its effect on every other requirement on the system. The number of interactions increases roughly with the square of the total number of requirements [I = (x^2 - x)/2 ].

In the flying car example, look at what the air bag designer has to deal with. For a car it has to meet NHTSA safety requirements, interface with the car's electrical system, and not interfere with the steering wheel's function (various other requirements such as acceleration and range aren't affected but still have to be checked to make sure). Adding the requirements for a flying forces changes to the design to comply with FAA regulations, keep the airbag from going off during a rough landing, and make it lower weight to support flying performance.

Some requirements don't directly conflict but push the design in different directions. Take the flying car's wheels. Improving the traction and responsiveness on roads requires wider tires and heavier brakes and suspension. For better performance in the air the tires need to be narrow (to reduce drag) and all components must be low weight. In situations like this the performance allocations to the subsystems must be made carefully to ensure both requirements can be met.

Since engineers tend to advocate for their favorite requirements, allocations and flow-down to lower-level requirements can be contentious. The more top level requirements pull in different directions, the harder it is to find an acceptable compromise. The compromise may be vague wording that postpones the conflict to the next level of detail.

With conflicting agendas among the different development teams, each protecting their pet requirements, engineers have to take time away from their own tasks to check up on other teams. It's easy for someone to make a change to his design that impacts another team's performance. Avoiding that requires studying the whole project's requirements, annoying supervisors who want their tasks done on time. Frequently Team B won't realize they've been affected by Team A's change until after it's been approved and incorporated into the baseline. This can produce thrashing—A's change forces B to redesign their subsystem, causing a problem for C. If C's proposed fix affects A's subsystem the cycle will repeat until the system-level management recognizes the problem and imposes a common solution (or the system is delivered with flaws intact). This can be averted by each team reviewing proposed changes before they're approved—as required by every project's CM process—but analyzing piles of change requests is always a low priority task, discarded when the team is behind schedule.

This illustrates what the most precious resource of a project is:
The attention of the workers
If the engineers try to pay attention to too many requirements, they won't be able to focus on creating their designs. So they pick the ones that matter the most to them and ignore the rest. This is where process and security requirements do their damage. Time spent on learning new change forms, adding required markings to drawings, or evaluating data to see if it's classified or ITAR-restricted takes away from designing. Hiring more people can help with the technical workload but adding them for process/security enforcement just adds interruptions without reducing anyone's workload.

Concentrating attention is how the Apollo Program succeeded at its incredibly difficult task. "Man, Moon, decade" was a requirements set that everyone could grasp and apply to the problem in front of them. With a common goal and priorities engineers could trust each other and focus on their own jobs. Apollo proves even a very large project can be at the top of the success curve.

Projects at the bottom of the curve fail in multiple directions. Time spent arguing priorities or struggling with new processes causes schedule delays. The salary hours used add to the cost overruns. Thrashing from repeated changes drives up both. Technical performance suffers because no part of the design gets the attention needed to optimize total system performance. Worse, a conflict between requirements or subsystem designs could be missed, producing a product that doesn't meet the original need. Actual flying cars have been built but suffer from these requirement conflicts. Their performance is inferior to cars and light planes while costing more than the combined cost of both. Flying car makers have repeatedly gone bankrupt while nearly all Cessna owners also have a car.

When managers realize their projects are in trouble they start climbing the success curve. Cost and schedule requirements fall off the list once they've been passed but the design choices that gave up performance for low cost or quick manufacturing are still part of the design. Process requirements are frequently removed informally by paying lip service while bypassing the process steps. Deleting a performance requirement can be essential for getting back on track but can threaten the viability of the project. Removing a feature drives away the customers who wanted that capability. Government projects have their funding cut as stakeholders lose interest. If that doesn't leave enough money to meet the remaining requirements the project can go into a "death spiral".

A system can be built with a huge number of requirements if you go about it the right way—get a basic version working and only then add the advanced features. The C-130 Hercules cargo plane has been expanded to land on skis, fly into hurricanes, refuel other planes, infiltrate hostile territory, and be a platform for radio stations and artillery pieces. Developing all of those capabilities at once would have pulled the engineers in so many different directions they may not have delivered a working system at all.

In the software world this is called Spiral Development. The define requirements-design-build-test process is repeated several times, adding more requirements on each loop. The cycles continue until all requirements are implemented or the project runs out of time or money (This works in other industries. The author used it on an aerospace project.) Introducing a new development process should be done as a "zero" iteration, practicing the new methods on a "build one to throw away" prototype.

Not every project can be a spiral development. Some requirement sets can't be split into useful packages. More resistance comes from corporate (and government) cultures which believe a "Great Leap Forward" is faster and cheaper. They can still succeed if they don't let their requirements list get too long. Deciding on spiral vs. waterfall development is the job of project managers and chief engineers but all developers can push back on a new requirement. The success curve can be a useful tool for making it clear that someone's "tiny little new feature" can have an out of proportion effect on the whole project.

Too many requirements can kill a project.

Kill them first.
selenite0: (Advanced Weapons Testing)
This is the right way to do military procurement. Get something out to the field so it can 1. help the troops, 2. test against the real world, and 3. help figure out what the real requirements should be.
selenite0: (Beware the Engineer)
I heard a bit on NPR about a whistleblower who'd been driven to put his revelations on YouTube after being blown off. He'd gone to Lockheed Martin management, the Coast Guard, Homeland Security's inspector general, and Congress without getting anyone to take action on his complaints. So I got curious and watched his video.

He struck me as a little out of it from the beginning when he talked about how amazing it was that Lockheed Martin could have an ethical violaton. What planet has he been on?

The first complaint was that the automated cameras for providing perimeter security while the ship was docked had gaps in their coverage. Yeah, they could fix that by adding more cameras. But taking advantage of that gap would require coming in a straight line at the correct angle from the horizon to the ship. That's pretty damn tough if you're maneuvering through a harbor (or walking on the dock) to get to the thing. So I'm not shocked that the Coast Guard decided they could live with that coverage.

The second was that after the Lockheed team he led finished the design of the new sensor gear the Coast Guard gave them the environmental for what the equipment was supposed to be able to endure. Lo and behold, the spec called for handling negative 40 degrees Farenheit, while the hardware they'd already bought could only stand negative 5. Options: 1. Toss all of the paid-for work and design a new system. 2. Decide negative 5 is acceptable and move on. Response of the government: 2.

I only got halfway through his ten-minute video. It's clear that this guy is one of a type of engineer who annoys me: the "cost doesn't matter" engineer. I had a professor in an aerospace engineering class once say that "Cost is not something we normally think of as an engineering parameter." In the real world you can't make everything perfect. Often it's better to have ten slightly flawed boats instead of one perfect one. That's part of the design process if you're trying to meet the customer's true needs, instead of creating a work of art.

I was still curious enough to research it a little more and found an article on Defense News about it. Now I really understand why he was totally blown off. Adding new electronics wasn't the only part of the contract. The patrol boats were being lengthened from 110 to 123 feet. Which didn't work out so well: "structural flaws found in the converted boats caused the Coast Guard to scuttle the program after eight conversions." [of 49 planned] When they're dealing with cracks in the hull tempermental IR gear isn't going to be the biggest worry. And if they've already cancelled the contract there's not much to be gained from examining the other problems. Mr. Whistleblower needs to get his priorities straight, even if from now on he'll be balancing taking the fries out of the oil against providing drink refills.
selenite0: (anvil)
"They're not lighting a match for the bridge. They've dropped a nuke on the bridge."
- A co-worker, describing a vendor's relationship with our project.

QOTD

Mar. 2nd, 2006 03:24 pm
selenite0: (This is Terrible)
Overheard:

"The only way to succeed on this program is to fail. Nobody listens to you until you start failing."

- My boss, on getting support from management.
selenite0: (Looked so good on paper)
My project is launching an interesting initiative. Managers with work they don't have anyone to do right away can post the tasks on an internal bulletin board. Any employee can take a look at the list and volunteer to take one on. This is being pitched as "career-broadening" opportunities. Engineers can try out working in another area without having to make a big jump into the unknown. I figure I'll check it out, there might be some fun stuff to do.

I'm wondering what management's actual motive for this is. It's an open admission that resources are badly allocated if they think some people have the spare time to do stuff like that. Which they are, but I'm surprised they'd admit it. The bigger motive might be trying to fight turnover. If people can experiment like that it reduces boredom and the sense of being trapped, both motives to quit. There's also the overtime problem. Lots of people are working huge amounts of overtime for show, without actually having work to do because they're waiting on somebody else. The task-sharing project may be a way to get some value from that.
selenite0: (anvil)
. . . to have your project mentioned on the front page of the Wall Street Journal. (pay site)

PENTAGON JUGGLES weapons programs amid budget squeeze.

Senior Defense officials pored over options this week as Deputy Secretary England pushes to trim the huge Joint Strike Fighter jet program. Air Force officials are resisting.


Not that I can I claim it's what's most needed in the current war, but I'd hate to be hit by the layoff.
selenite0: (Beware the Engineer)
"We should build the plane so if a pilot ever gets into that situation it self-destructs and takes him out of the gene pool."

Apparently some of the Flight Controls folks aren't happy with their requirements.

So it goes

Sep. 1st, 2005 04:51 pm
selenite0: (Beware the Engineer)
My former project, the NPOESS weather satellite, was written up in the Wall Street Journal today. Good news? Don't be silly:

The multisatellite project, being built by Los Angeles-based Northrop Grumman Corp. with Defense Department oversight, is running as much as 15% over budget and more than 18 months behind a previously extended schedule

Good heavens, how could that happen?

The satellites were conceived as a way to save money by replacing separate fleets of civilian and military spacecraft. Many problems stem from loading up the satellites with an unusually wide range of sensitive sensors.

Yep, let's take the needs of the military weather community (global coverage, rapid delivery), the US domestic weather support (detailed data, specific sun conditions), and the climatology science community (very high resolution data on many different wavelengths) and merge them into one system. Can't be any conflict between--gack. Sorry, I choked on that.

When I did a USC paper on NPOESS I compared it to the Department of Agriculture deciding to breed an animal that produced both eggs and milk. NPOESS is a lot more complicated and expensive than the predecessor DMSP, POES, and EOS systems. So how can we make this worse? Well, let's start with the desire to have all the latest high-tech gadgets on the bird.

Sophisticated infrared and other types of sensors under development have "problems with technology, with design shortfalls...and fabrication," Fred Ricker, Northrop's program manager, said.

Yep. Take a whole bunch of high-risk efforts and have the system depend on all of them so the worst one drives the schedule.

Ronald Sega, the Air Force's recently appointed undersecretary, . . . . told the Long Beach conference attendees that for future projects, he is looking to "distribute risks in a different way" by focusing on "a modular type of approach" [snip] "splitting the capability into multiple spacecraft."

Known outside defense circles as "not putting all your eggs in one basket." What an amazing idea.

QOTD

Apr. 15th, 2005 11:34 am
selenite0: (software sucks)
"We all laugh, because crying would be unprofessional."
- Software Board chairman after a subcontractor's excuse cracks up the whole room.

Profile

selenite0: (Default)
selenite0

July 2017

S M T W T F S
      1
2345678
9101112131415
16171819202122
23242526272829
3031     

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 24th, 2017 10:46 pm
Powered by Dreamwidth Studios