Untested Process Guidance
Despite a typical manuals numerous exhortations to test, test, test, software process mandates are obviously not tested by the writers, else they would notice some obvious typical defects of SDLC methodologies.
Team Size Approaches World Population
Each time a new activity is imagine, it is imagined with a specific person to do it. After taking into account which roles act as auditors and check the work of other roles, you can calculate the minimum team size, which often is huge. A throw away sentence that says this strictly mandated process “can be simplified” isn’t exactly guidance.
Manager Wears all Hats, Fills out all Forms
Most of the roles get assigned to the boss. Most of the process documents involve deciding what to do, what order to do it, and so on. As a result, in even if you have a large team of say a dozen developers– the vast majority of the paperwork burdern falls on the project manager.
What @%@^$ company is this for?
Process messes with the existing political hierarchies. Process guidance assumes that certain committees. Often because of the “Manager wears all hats” problem, the process paperwork gets delegated down the chain of command to someone who doesn’t actually have the power to execute the plans he’s planning.
A mandated process without a mandated and funded auditing process is likely to turn into a sham. A sham process uses the same words and some of the same documents as the process dictates, but doesn’t actually follow the process.
Metaplanning and Redundancy
Process for creating process documents is a dubious activity. While software creation is a difficult task that requires more planning and tracking than ditch digging, it’s not clear that applying a SDLC to the process of paperwork generation is a value added one. Ironically, the artifacts most likely make it into version control repositories are the process documents, not the source code!
Because software process promulgators don’t test their own processes, they don’t realize how redundant it gets. If there are twelve documents, the templates are likely to ask the manager to summarize the project history twelve times.
Again, because SDLC processes aren’t actually tested before being finalized, they don’t notice the massive bias they have towards greenfield development. Greenfield development is increasingly rare. Most IT workers subject to SDLC mandates are maintenance developers. Process mandates go into hyperdetail about the creation of brand new systems and give short shrift to dealing with the more common and more interesting process of upgrading a system while it is running without downtime. Worse, organizations tend to have a bias towards living with broken code rather than risking fixing it. Mega processes exacerbate this organizational bias. On one hand, it sounds prudent and cautious. In practice, it is like hiring a plumber to fix the toilet only to hear, “Well, use your neighbors, it might be dangerous to fix anything.”
Long Minimum Paths
Federal SDLC processes often mention how many meetings there should be and how long documents should be made available for review to participants. With a few dozen mentions of minimum review periods, minimum testing periods, minimum planning periods, you get a process that takes a year or two for a single iteration.
SDLC documents often mention the existence of so-called tailoring. Tailoring is adapting a process to deal with reality. Tailoring will happen, either because the SDLC is being ignored, misunderstood and tailored without permission. Formal SDCL documents often use strong language to discourage any tailoring. This has the effect of keeping process in the dark ages. Scrum, Extreme Programming and many other innovate process methodologies are popping up all the time. Using formal and mandated SDLC processes to smother competing methodologies is probably counterproductive. This is especially ironic when SDLC documents themselves tend to be a mix of all the process fads up to the date the SDLC mandate was promulgated.
There often is no “Supreme Court” for SDLC documents. Mandated guidance can be self contradictory, contradict other organizational policies, or just poorly and incompletely written. A typical SDLC document will refer to “architectual boards” and “SDLC advisory comittees”, that are assumed to exist, but don’t actually exist in reality or as phone number to call.
Mandated SDLC processes often ignore that they are mandates that will fail without buy in from the people who have to follow the process. Without buy in from the process participants, the SDLC quickly turns into a process of creating dead documents no one wanted, plans no one will follow, documents no one wants to read.
And on the topic of dead documents, the SDLC tends to assume all documents are dead. Typical SDLC flow charts show document one being created, then the next, then the next, etc. Often project plans, bug databases, feature wish lists are dynamic lists that are being updated daily for the entire life of the project. That these documents are often portrayed as single documents that can be delivered and signed off just go to show that SDLC promugulators haven’t actually used their systems before, or if they did, they didn’t bother to watch how the documents like “Requirements” were used. In reality, a requirements document is a point in time report from a dynamic bug and feature database. Any point in time document that is referring to dynamic real life data will have a usuable life of a day or two.
Blogged with Flock