AOPA forums down?

Have none of you ever been involved with an IT project at work? This isn't abnormal...it might be wrong, but it happens far more often than you'd expect. Systems get pushed to go live without being having been fully tested all the time.

Shame on their IT leadership.
 
Have none of you ever been involved with an IT project at work? This isn't abnormal...it might be wrong, but it happens far more often than you'd expect. Systems get pushed to go live without being having been fully tested all the time.

Shame on their IT leadership.

When I fund capital budgets, I assume that IT projects will take 2-3 times the projected time at 2 times the projected cost. Sometimes I am pleasantly surprised, but most of the time that's close to accurate. Though I can also say that in the corporate world there are some folks that gold-plate the IT systems... I've run across one where the service could have been outsourced (to a US-based provider) for 1/3 of the cost of the internal service.
 
Have none of you ever been involved with an IT project at work? This isn't abnormal...it might be wrong, but it happens far more often than you'd expect. Systems get pushed to go live without being having been fully tested all the time.

Shame on their IT leadership.

Have to disagree with you here. Most people outside of IT know very little to nothing of how we do stuff. The amount of back-end changes that can be fatal to front end systems is staggering. I've worked far too many nights, weekends, and holidays to count keeping a customer facing system alive while we rip out the guts of a network or storage system and upgrade to new equipment.

Anyone familiar with Moore's law knows the cycles that IT goes through with rip and replace. Most of it goes without a hitch. Once in a while a huge screw-up like AA's ground stop comes along and gives everyone a black eye, but more often than not customers have no idea that we just migrated > 350TB of data, or that their exchange server has all new stuff behind it.

I'm involved right now in replacing millions of $$$ of hardware at a major, and I mean huge credit reporting agency. Banks, credit unions, CC companies, traders, auto dealers will not feel a thing. They can submit a request, and the response times will be about the same for the next week, but almost everything from the firewall back to the tape drives will be all new gadgetry. I'm a small cog in a much bigger wheel but it doesn't have to go bad, and it shouldn't with engineers and not wanna-be's at the helm.

AOPAs IT issues are a shameful black eye on the industry and most of us are more critical than users. The names of these guys will get around in the industry, and they'll have a hard time getting past this, as it should be.
 
When I fund capital budgets, I assume that IT projects will take 2-3 times the projected time at 2 times the projected cost. Sometimes I am pleasantly surprised, but most of the time that's close to accurate.

Well, funding and participation of stakeholders can often make things work better. As someone who is a consultant in an IT-related field, I can say that I do better than the factor of 2 fairly often, almost never down to a factor of 1, but if I was given all pertinent information in a timely manner and didn't have to pull teeth to get users to say what they need from me, things would go smoother. However, I don't think that's really possible...

It's gotten to the point that I kind of plan to be "done" half to 2/3 of the way through, roll out my system, and let the users bang on it. Once they realize what it's capable of, they tend to have many more ideas about what they'd like, and the last third of the project can be dedicated to those.
 
When I fund capital budgets, I assume that IT projects will take 2-3 times the projected time at 2 times the projected cost.
I take however long I think something will take and double to triple it and build expectations around that. Works out quite well.
 
Well, funding and participation of stakeholders can often make things work better. As someone who is a consultant in an IT-related field, I can say that I do better than the factor of 2 fairly often, almost never down to a factor of 1, but if I was given all pertinent information in a timely manner and didn't have to pull teeth to get users to say what they need from me, things would go smoother. However, I don't think that's really possible...

It's gotten to the point that I kind of plan to be "done" half to 2/3 of the way through, roll out my system, and let the users bang on it. Once they realize what it's capable of, they tend to have many more ideas about what they'd like, and the last third of the project can be dedicated to those.

I take however long I think something will take and double to triple it and build expectations around that. Works out quite well.

Both of which are reasonable ways to go. I wish the folks I've worked with did the same - I'd rather they underpromise & overdeliver.

The issue is that a lot of folks 1) think that they're doing a good thing by trying to save money (rarely happens), 2) don't really understand the task and/or don't work cooperatively on setting parameters/expectations, or 3) want to impress someone and think that asking for a low budget will be a favorable impression (or expedite the project).

You two generally "get it". There are a lot of folks that don't. I'd always set aside some of the corporate capital budget I allocated for IT overruns.
 
I take however long I think something will take and double to triple it and build expectations around that. Works out quite well.

I learned that lesson the hard way in my first 'official' IT project. Sitting in the conference room with 3-4 people drawing out the very early design on the wall, someone said "So how long do you think that would take." Off the cuff I said "Oh, probably 2-3 months to have it ready for initial user testing". When I checked email the next day, I found that the 'official' release date had been set for 3 months from that day. :mad2:

We're going on 7 months now and it will probably be closer to 9 months before it's ready. I learned my lesson - take your honest assumption, double it, then triple that and that is your communicated estimate.
 
I can do any two of these three, you decide:

1. Fast
2. Cheap
3. Good
 
an amateur is exactly what 100k buys in IT these days.

Incredibly true. There's nothing wrong with that, though - sometimes you need "grunt work" at <100K, and that's just as important as drawing the talent at the higher levels too.

Not everyone can be a thought leader.
 
Actually, the way I'd handle the switch is a DB flag that says if the password was changed since the hash was imported(assuming it was flattened to lowercase before hashing). If not changed lc(input) before checking the hash, else after it's been changed then compare it directly. Of course, it's 50x more likely they were just storing the passwords in plaintext.

The way I'd handle it:

When someone creates a password, convert it to uppercase using existing case change functions, encrypt it and save it encrypted in the database.

Now when someone enters a password, convert it to uppercase and run through the same encryption mechanism. If they match, then the passwords match regardless of case.

But, I suspect the routines that now take out that to_upper call isn't the cause of this being down.
 
Have to disagree with you here. Most people outside of IT know very little to nothing of how we do stuff. The amount of back-end changes that can be fatal to front end systems is staggering.

You disagree that sometimes IT projects are pushed to go live without adequate testing?

Yes, people outside of IT have little idea what it really takes to do this right nor do they typically have enough foresight to see the consequences of something failing. That's why I said "Shame on their IT leadership" for failing to understand that this was not ready and failing to communcate it.

What I suspect, having been through many of these projects and having seen them done, is that someone set a deadline to say "go live on 7/15" and they did it because the project manager has an addiction to food, clothing and shelter and missing the deadline would have threatened his addiction.
 
Last edited:
Absolutely disgusting that AOPA stored passwords as either plan text or at the very most, some un-encryptable format.

Disgusting.
 
And, they're down again. "PHP has encountered an access violation at..."

Getting the same response as of 3 minutes ago.

I can see the list of new topics, but clicking on thread name or the "latest posts" small blue icon gets the PHP error.
 
Getting the same response as of 3 minutes ago.

I can see the list of new topics, but clicking on thread name or the "latest posts" small blue icon gets the PHP error.

Larry, Moe and Curly (the IT Team at AOPA) are on top of it!! They'll have it fixed in no time.


:lol:


Mike
 
Just out of curiosity... do they run on IIS over there?

-Rich
 
You disagree that sometimes IT projects are pushed to go live without adequate testing?

Yes, people outside of IT have little idea what it really takes to do this right nor do they typically have enough foresight to see the consequences of something failing. That's why I said "Shame on their IT leadership" for failing to understand that this was not ready and failing to communcate it.

What I suspect, having been through many of these projects and having seen them done, is that someone set a deadline to say "go live on 7/15" and they did it because the project manager has an addiction to food, clothing and shelter and missing the deadline would have threatened his addiction.

Sorry, I should have snipped. This is what I disagreed with:

"This isn't abnormal...it might be wrong, but it happens far more often than you'd expect. "

In the theme of this thread, complete hash-ups in IT happen very infrequently. And in my abstract, I wanted to express that I do this kind of stuff 6-10 times per year, and yet no one even knows it's happening. When things go horribly wrong, and planes don't fly, or stocks don't get traded, the game locks up, it makes the news. That's why they call it news, because it is rare.

I'm sure that schedules slip, I'm sure that costs overrun, I'm sure that projects do not always go the way they were first intended. I could write a book on the delta between what customers want, and what they say they want. When I do the network part of the deal, I ask customers in a project planning meeting not about speeds and feeds, cause that's my job. I ask them about bulk stuff. How many hits per hour? How many transactions per hour? What is the cost of a delay of 1 second? 30 seconds? 1 minute? 1 hour? Some apps can handle things, some can't. Some customers expect instant interaction(gaming), others won't run a pull and ship until 7PM each night. I have to figure out the speeds a feeds so that everyone gets served(literally).

The gen pop has no idea how this all knits together, with border gateways, routing policies, shadow apps, embedded apps, platform specific architectures, and now the "cloud', which is in the industry we consider an acronym(Can't Locate Or Use Data). None of you know about a major 3 letter company that had a massive network outage a few days ago. No one outside the community would believe what primitive systems a major bank uses. It amazes me that we don't have more meltdowns like AOPA.
 
I can do any two of these three, you decide:

1. Fast
2. Cheap
3. Good


Same thing with airplanes -

1. speed
2. range
3. Payload

Pick any two. There are literally two single engine piston airplanes that can do all three - Comanche B and C models and Bonanzas . . . .
 
Same thing with airplanes -

1. speed
2. range
3. Payload

Pick any two. There are literally two single engine piston airplanes that can do all three - Comanche B and C models and Bonanzas . . . .

Define what the terms are... I can take 750 pounds (the payload of our recently-destroyed 182, a well-noted hauler) for over 500nm at 175 KTAS.

Of course, if I don't need to take that much weight, I can go twice as far with 500 pounds, and still just as fast.
 
Define what the terms are... I can take 750 pounds (the payload of our recently-destroyed 182, a well-noted hauler) for over 500nm at 175 KTAS.

Of course, if I don't need to take that much weight, I can go twice as far with 500 pounds, and still just as fast.

I presume it is a T182RG??? Cause no fixed gear 182 I know does 175KTAS . . . .
 
I presume it is a T182RG??? Cause no fixed gear 182 I know does 175KTAS . . . .

Are there 175kt TR182s? The one I flew to osh awhile back was 145kt in the non-cannula altitudes. And at a ridiculous fuel burn.

It sure did haul a load though. :)
 
Are there 175kt TR182s? The one I flew to osh awhile back was 145kt in the non-cannula altitudes. And at a ridiculous fuel burn.

It sure did haul a load though. :)

Most turbo's don't do well in "the non-cannula altitudes." The whole point of a turbo is being able to maintain power to higher altitudes where there's less drag so that you can go faster. A normally aspirated bird can run 65% power up to the 11,000 foot range, so if you keep a turbo bird down in the non-O2 altitudes it won't really do any better than a normally aspirated one unless you flog it.

Go to the flight levels, though, and you'll be whizzing right along...
 
The AOPA Board is as reliable as an Asiana Pilot hand flying an approach to SFO. :rolleyes2:

Cheers
 
They apparently managed to screw up the AOPA Magazine app while they were at it. I got an authentication error when I tried to sign in. Deleted reloaded with no success.

What a bunch of idiots.

Cheers
 
They apparently managed to screw up the AOPA Magazine app while they were at it. I got an authentication error when I tried to sign in. Deleted reloaded with no success.

What a bunch of idiots.

Cheers

They gotta keep expenses low to fund Fuller's golden parachute!
 
They apparently managed to screw up the AOPA Magazine app while they were at it. I got an authentication error when I tried to sign in. Deleted reloaded with no success.

What a bunch of idiots.

Cheers

Mebee try to clear your AOPA cookies and have another go. Your cookie might be pointing the wrong way.

<edit: For all other AOPA users, you might try clearing all your AOPA cookies(instructions can be found in your browser help) and give it another try. Moving DBs, and some new 'enhancements' to their site may have left the wrong trail of crumbs to the cheese.>
 
I take however long I think something will take and double to triple it and build expectations around that. Works out quite well.

I used a similar approach back in the 70s when I worked for the Navy and we had a blue collar contractor who did a number of jobs for us. One job I nailed what his estimate would be to ridiculously close tolerances. Scared him. He asked how I did it. I said I came up with what I thought was reasonable, doubled it and added $100. Just about hit it dead on. Never got that lucky again, either. :D
 
Mebee try to clear your AOPA cookies and have another go. Your cookie might be pointing the wrong way.

<edit: For all other AOPA users, you might try clearing all your AOPA cookies(instructions can be found in your browser help) and give it another try. Moving DBs, and some new 'enhancements' to their site may have left the wrong trail of crumbs to the cheese.>

On the rare recent times when the Forum works, no problem. The app has been removed, reloaded, removed, reloaded, no joy. Glad old fashion paper still works. ;)

Cheers
 
Sorry, I should have snipped. This is what I disagreed with:

"This isn't abnormal...it might be wrong, but it happens far more often than you'd expect. "

In the world of finance, yes it is abnormal. There is too much money at stake for it to be wrong.

But not in the rest of the world. It happens often enough that you can't say it's an abberation. I've seen projects go live that wound up costing a company 100 million dollars because someone refused to allow an extra two months of testing to shake things out. One of my friends just lost his IT managment job because he was pushed to go live with a system that wasn't ready. I like him, but in talking with him, I know that it happened because he didn't speak up. I've been on project teams in the past that had this problem.

As complexity goes up, the number of issues will go up exponentially. You need to prepare with adequate time to shake the issues out. When upper management sees the IT system as a cost in the first place, there can be very high pressure to go live as soon as possible.

What AOPA is facing is the result.
 
It was often down in the wee hours of the morning even before the server change. It's back up now.
 
At times like this, it pays to save what you write to the clipboard.
 
Back
Top