DIY and the Dumb Rules of Prevention

Check out this little item in eWeek. "Transforming DIY Projects from the Painful to the Productive".

As an outside consultant in a large number of organizations, I've seen a lot of DIY projects—what we used to call "end user computing". Indeed, I've even been hired by the user organizations because IT was ineffective.

But IT gets in it's own way. There are some Dumb Rules of IT that creates an environment in which software development and project management are nightmares over burdensome inefficiency. Why? How?

How is easy. IT has too much process. I sat with angry users at meetings where they begged me to influence the CIO to stop making everything into a large-scale, heavy-weight, closely-monitored "project". All that the users wanted were simple conversations on how best to interface with existing applications and frameworks.

They didn't want a "project".

Root Cause

Why does IT anger the users with too much process?

That's sometimes hard to see when we're an insider. From end-users, I learned that IT's response to the inherent complexity of software development is to treat the act of creating software solutions as if the development work were—itself—just more software. Software executed by people and organizations. They write process they way they write code.

Here's Dumb Rule 1 of success in IT: "When in doubt, define a process."

And that rule is often just wrong. Users hate it.

Process is wrong? For software development, yes, too much process is a bad thing. Why do you think we had to invent Agile methods? The way we create complex software is not helped in any way by having a large-scale, heavy-weight process defined. Adding process steps to the already complex task of creating software merely slows the work down.

All processes aren't bad. Processes to create software are demonstrably unhelpful.

Suggestion One: Lighten UP

"The first step is to bring business developers out of the shadows and into the limelight."

This is important, and difficult. IT is so enamored of large processes that simply embracing non-IT developers means wrapping them in processes they don't need and can't comply with.

While good advice, this isn't the real first step.

The real first step is stop weighing down everything with overly-defined, heavy-weight process definitions. Embrace Agile development where there are sprints and releases and leave it at that.

DIY folks who are not in IT can understand sprint and release, since that's how they work anyway. IT needs to help them get started and help them release. The rest has to be hands-off. Inside corporate IT and outside the corporate IT enclave.

Suggestion Two: Open The Door

"Next, it’s important for IT to take the lead in providing tools and guidelines that make it easy for business developers to start off on the right foot."

While also good advice, it's almost impossible to actually do.

Why? IT folks who have drunk the Proprietary (i.e., Microsoft) Kool Aid laced with contractual terms and conditions won't let end-users have expensive Visual Studio toolkits. And the true believers in Microsoft hegemony can't let users have non-Microsoft tools. All the large IT organizations that are all-singing, all-dancing, all-Microsoft can't empower end users very well at all.

They offer up Sharepoint and MS-Access and then shut down all further access to tools.

Here's Dumb Rule 2 of success in IT: "Measure Success By Licensing Fees".

Visual Studio works because its expensive. Right? Oracle is "enterprise" scale because it's expensive. SQLite is unacceptable because there's no support, right?

To provide tools and guidelines, Corporate IT has to either (1) stop paying so much for tools or (2) budget for user departments to have access to real tools or both.

If we don't allow the DIY folks a decent tool set they'll still create software using crappy tools. They're remarkably capable of building vast shadow systems in MS-Access. Seven interlocked Access databases that all magically work together on a single desktop is the kind of thing they'll do if we don't help them do something better.

Suggestion Three: Stop Driving and Start Guiding

DIY folks want first class access to servers, data and tools.

"IT can take the lead in providing guidelines and even code snippets or basic scripts that work with platforms that are commonly used to create DIY projects in your organization."

"Provide small doses of advice on how to design applications for scale and security that are led by your professional-development staff. "

This can't happen, of course. The reason is that we can't "trust" the end users. If we give them access to the data, they'll make a total mess of it. We know they'll make a mess of it because we have columns in the database where the users have stopped entering the data we carefully defined in the data dictionary and started entering other data.

Why, oh why do end users corrupt the columns in the database? We tear at our hair and rend our clothes asking this. Everyone asks this. It's the great rhetorical argument against allowing users into the hallowed halls of IT.

No one tries to answer it, of course. It's a rhetorical question. The answer is embarrassing.

Users corrupt and misuse the database because a small change to add a column is a 9-month delay preceded by endless useless meetings, endless useless IT process. While waiting for IT to make a simple change, it's easier to simply enter the data into another unused field.

IT creates they're own nightmare by being unable to adapt to business change.

Here's Dumb Rule 3 of success in IT: "Control The Data".

Rather than adapt to business changes, wrap them in process as a way to say "no". Have elaborate processes. Complex budget negotiations. Project prioritization meetings.

Yes, the resources are finite. More process, however, means fewer resources devoted to solving business problems.

Code that does updates needs a lot of code review and testing no matter who wrote it. If end-users have a DIY project, IT should be deeply involved in the QA process. End users don't particularly like the kind of rigorous, expensive, sophisticated testing that IT imposes on itself. That doesn't remove the need to engage the DIY folks in some kind of test plan.

Making Progress

IT needs to offer a menu of services including "secure, reliable and available data and processing resources".

IT needs to have a simple, easy-to-understand quality threshold for software.

Programming, software purchase, integration installation and configuration and the like can be done by IT or by anyone else who meets the simple quality threshold.

A test plan. Evidence that the tests are passed. Compatibility with some standards.

It should be very, very simple so that DIY can be made to work efficiently. Since it's going to happen anyway, it's better to do it well than to fight against it with Dumb Rules.