System iNetwork

July 2005

July 17, 2005 2:05 PM

Love the hype, let's see it work!

It is pretty encouraging to see people outside of IBM being positive on the marketing future for the iSeries. I love the hype! Anything that exposes the iSeries to the world is a good thing. Now we need to be patient and let IBM follow through with their commitment. Let's see it work IBM!

Posted by on July 17, 2005 at 2:05 PM | Comments (6)

July 6, 2005 4:34 PM

Top ways to make a development project fail

Have you seen "classic" ways managers or developers cause a software project to fail? Add them to our list.

As readers of the June 7 Club Tech iSeries Programming Tips Newsletter know, I've recently been watching a development project go south because the project team has broken just about every rule I know for a successful development process. The results are predictable, but the staff is perplexed why the delivered code doesn't work and users are unhappy. That prompted me to come up with a list of "tips" to guarantee a development project fails.

Have you got a favorite "tip"? Share it with the rest of us as an iSpeak comment.

Here's my list ...

1. Follow a "Big Bang" approach to development. Have a few meetings to collect requirements and then go into your "cave" for months of diligent design and coding. Spring the code on users at a single two-hour "review" meeting with the expectation they'll suggest a few tweaks, and you'll be able to deploy with minor additional effort.

2. Impose your overall concept of how the application should work. Seek requirements and suggestions only within that framework. Never consider that you may not have "gotten" the way users conceive of their work and the context in which it occurs -- your experience with lots of other projects assures your concept is bound to be superior anyway.

3. Don't involve users in the day-to-day design and development work. They'll slow you down. Expect users to await your contact and then to provide immediate answers to lists of highly specific questions you present without any context.

4. Don't bother to educate the application "stakeholders" before asking for feedback or approvals. Assume users will grasp immediately your overall application model and all the clever technical elements you've incorporated in the design. Since your design is close to ideal anyway, it's okay if they don't fully understand the system you're proposing they accept -- depend on their faith in you as the "expert."

5. Don't worry about the accuracy or clarity of details in the documentation or presentations you give to users. You know you'll be able to fix mistakes and inconsistencies before or after deployment, so expect users to be satisfied reviewing your rough sketches of how the delivered system will work.

6. Don't plan time for users to have more than a few minutes "hands on" work with prototypes or pre-production implementations. Of course, you have to let users "touch" the system a little bit before you deploy it in production, but there'll be time for an hour or so of "thorough" training once the system is done, and that should be enough.

7. Assume that any technical concerns raised by users are just because they're not as smart or well-trained as you, the software "expert." Nagging questions about the application structure or details in how it's used can be attributed to the users' childlike understanding of application systems as sophisticated as the one you've designed.

8. Spend most of your time in the company of your IT buddies who sympathize with your having to put up with "idiot" department managers and "whining" users. After you've busted your butt trying to create the best system ever for these ingrates, you need a little comfort and reassurance.

9. When users complain as you prepare to roll out the application, explain that a deadline looms and you've already overspent your budget, so changing the soon-to-be-production system would cause serious disruption in the organization. Don't mention that delivering a flawed system will cause even more disruption or that the primary "disruption" you're concerned about is the impact of a missed deadline on your job security.

10. And lastly... Don't pay attention to what's really been going on around you. You already know how to run a project - you've done it for years. So there's nothing of real importance to learn from one more project that ends in chaos.
    

Posted by on July 6, 2005 at 4:34 PM | Comments (21)

Where did you get that test data ?

Ok. Time for my irregular rant.

With HIPAA and the new privacy laws in effect, how do we still get away with using production data in our test environment? Well, it's just so quick and easy to do a CPYLIB from production to test... right?

So, you want to know what terrible disease someone has? Just look at the test data! Want to know someone's Social Security number and their DOB and their spouse's name. Just look at the test data!

I am not a fan of encrypting data in our on-line production data files. But I am a big fan of at least scrambling personally identifieable information in our test files.

I have seen cases where even bank account numbers and PIN codes are left un-altered in test data files. That along with medical diagnosis, and blood test results sitting unprotected in test data files is unconscionable and possibly even illegal.

So... Dan, What's the Big Deal? My end users see all that data every day in the production files. Yes... and that is THEIR JOB. Our job is to write, maintain and enhance programs and systems, not to snoop into personal information.

Technicians should have NO access to production data, except when handling a firecall, and then ONLY when all their actions are being fully audited using the OS/400 audit functions.

Please write some scripts to generate test data while scrambling sensitive information.

nuf said for now....

Dan Riehl

Posted by on July 6, 2005 at 2:56 PM | Comments (9)