The House passed the AMT bill...

[K Frame]

Thank God.

The Senate has passed it, and Bush backs it.

I very likely would have gotten hit with it this year.

[matis]

I'm glad, too, that they passed this.

But what about next year?  The bill they passed applies only to 2007.

Think the Dems will renew this?

matis

[Leatherneck]

Thank God.

And Amen. I was truly fearful of getting caught again this year like I was a few years back, being RICH and all...

Why the Hell can't they just eliminate the damned AMT?

TC

[HankB]

Why the Hell can't they just eliminate the damned AMT?

It would be harder to fund things like Alaska's Bridge to Nowhere, the Rock & Roll Museum, driver's licenses for illegal aliens, and gay indoctrination for first graders.

[The Rabbi]

Actually they eliminated the wrong tax.  They should have eliminated the standard tax code, retained the AMT, and lowered the marginal rates.

[Paddy]

Because Congress acted so late this year, people expecting refunds will have to wait.  IRS says it will take 7 weeks to reprogram their computers, and they can't start processing returns until that's done.  They usually start about Jan 15, so you'll be waiting a long time for your refund.

[BrokenPaw]

Seven weeks?

[jbt@taxcomputer.irs.gov]$ mv amtcalculator.cfg amtcalculator.cfg.old
[jbt@taxcomputer.irs.gov]$ cat amtcalculator.cfg.old | sed -e "s/oldamount/newamount/" > amtcalculator.cfg
[jbt@taxcomputer.irs.gov]$ /etc/init.d/amtcalculator restart

Done.

[Paddy]

That's not me talking, that's the tax experts at Edward Jones where I attended the Year-End Tax Update broadcast last week for 5 CPE credits.  They said 7 weeks.  Maybe they're just pessimists.

[roo_ster]

BrokenPaw:

That's how I would do it. 

But, they are likely CMMI Level 5, so to actually implement your three command lines it will take seven weeks of process whipping to allow the one actual coder at the IRS to perform the task.

[K Frame]

Seven weeks sounds about right, and maybe even a bit fast.

You've got to remember that it's not as simple and popping a disk into a desktop computer, downloading a chunk of code, and hitting the ground running.

There's development, item testing, development testing, module testing, integration testing, and system testing that needs to be done throughout out the software development cycle.

Installation documentation needs to be developed concurrently, as does testing procedure documentation. That's all for the managed test environment. If the software fails at any point in that cycle, it has to be fixed, and it starts the testing all over again.

Once the software goes through the development and testing cycle on the "off-line" side of the house, it has to be installed on the production side of the house, and that also involves a series of measured steps followed by verification testing.

[BrokenPaw]

FTR, Riley, I wasn't sniping at you; I realize you were just the messenger of ridiculous news.

Mike, I've worked on contracts like that, too.  In fact, I'm on one now, for a customer that your company probably does extensive work for as well.  But things like "changing a threshold value" aren't really engineering issues; at least, they shouldn't be...they should be configurable values in a resource file or config file somewhere, and all possible ranges of values should have been tested prior to release.  That was really the point I was trying to make.

If I told my customers that it was going to be a 7-week turnaround when they wanted to change a system setting (like, for instance, "make sure the disk array never gets more than 90% full, instead of 95% like we have now"), I'd have a brief but very exciting exit interview.

The sad part is, my company uses the Scrum process, with 4-week staggered sprints, so the minimum time from standard feature-request to feature release is 8 weeks, 4 for dev and 4 for QA.  But even if we had to QRC it, I imagine that BrokenCo could get a change like this out the door in less than 7 weeks.

-BP

[K Frame]

Paw,

I sincerely doubt that changing the software baselines that run across all of IRS' systems is as simply as keying in a few changes to a config file. It's not a matter of changing system settings, it's often a matter of changing the very basic construct of a system, or more often a number of systems.

Unless things have changed dramatically in just the last couple of years, IRS has an amazingly diverse system of systems, some of which are as old as the AMT itself, and which haven't really been changed since AMT was adopted.

A lot of that 7 weeks involves making sure that the code changes (and mainframe coding is a lot different from PC coding) propagate across all of IRS' systems seamlessly. I worked briefly on an IRS contract (subbed out from my main when work was slow), and if anything, IRS' computer situation was even more bizarre than EPA's, and EPA's was a freakshow. As of less than 5 years ago EPA was still using an employee timecard and payroll mainframe system that was state of the art.... when it was installed in 1962. EPA inherited it from the originating agency, and it was grown from there.

Legend has it that Grace Hopper herself plugged the damned thing in. 

That's one of the major chall

[K Frame]

Good example of something bad happening when proper testing wasn't done in a test environment.

A couple of year ago Cox Cable ran out big software enhancement to their high-speed internet service.

The change spiked something like 80,000 Toshiba modems in the Fairfax County area, the modems that Cox themselves rented out with their service. I talked to the CEO of Cox during their big "exchange your dead modem for a new, live modem." They rushed the software through development and into the production environment without proper testing, and ended up eating a lot of money because of it.