reesesWeb

A few days a week, I've been working with about eight other people to redefine the software development lifecycle for a large-ish organisation. We're trying to achieve compliance with the Sarbanes-Oxley Act for an IT organisation of about 1000 people, within a corporate headquarters of about 6000 people. (100k enterprise)

Within this organisation, they have varying levels of development immaturity. We're talking CMM level 1, with some groups peeking up at the floor of level 2. Not that I'm a big CMM fan, but I think it helps you get the picture.

I've noticed two things that I will call "amusing" for want of a better word. The first is that every company seems to feel the need to tailor their own SDLCs. Usually, they start cutting code and producing software without thinking about how to do so. Eventually, the whole things becomes unwieldy, and they think,"We need some process!"

Two things can happen at this point. What often happens is that someone has read about XP, and taken the superficial view that what they're doing is basically XP. They don't produce design docs, check. They don't do separate QA, check. It's XP!

The other thing that happens, especially in large organisations such as this, is that the company feels that it has to have its own SDLC. Rather than pick one and make the organisation match the process, they have to spend six months reengineering their current process.

Sure, RUP out of box is useless to everyone, and SCRUM isn't for every team. However, I'd much rather just throw something out there and let them struggle with it for a while than sit around jabbering about different document templates and workflow for six months, when it's a basically flawed approach to begin with. There are so many processes out there, there's one for every organisation.

"Small company, one product line using OO? Use x." "Medium-sized company, multiple inter-linked product lines, using OO in various languages? Use y." "Large company, a huge number of de-coupled projects, some legacy COBOL or PL/SQL, some .NET, some J2EE? Use z."

On the bright side, we now have a pattern language for process. Everyone knows, basically, what a "functional spec" is, or what a "design review" entails. QA plan, test plan, test scripts, unit tests are all a fairly clear hierarchy to all concerned.

I'm completely defocused here, so let me tie this back to the other funny thing.

The other funny thing is that, in this situation, everyone is so much more generous in their implicit assumptions about their groups. It's not that they say their group is so disciplined -- quite the opposite. It's that they make these commitments that the teams are going to be completely unable or unwilling to follow. And, because it's a bespoke process, the justification for each of the elements is rather ad hoc. There's absolutely no hope of overcoming intertia by any means other than,"You like your job? Fill out the checklist for the Scope Document."

So, we can sit there, and talk about adding cruft to this elephant, and everyone nods like,"great idea, everyone will tie every class and module back to a specific requirement!" when we know that's not going to happen. Some of these are requirements of sarb-ox and must be done, and some are just capricious.

Couple this with a complete lack of understanding of what SOX really means, and what the requirements really are, (no one knows, not just at my client) so a lot of this is blind feeling in the dark.

Bookmark/Search this post with:

delicious | digg | reddit | technorati