If you have Shadow IT in your world, you have already failed. - Part 3

There is nothing I find more exciting than finding a small team who has build something great for their customers without the official blessing of some corporate team. Unfortunately, rolling it out to the larger company can be a disaster.

In the first post in this series, I discussed how a team of developers can protect and isolate themselves from the corporate IT team and it's oppressive standards. In Part 2, I discussed a cultural shift IT could adopt to provide some structure and light governance to Shadow IT. The final piece of the puzzle is for the development team to adopt some basic standards that make it easy to integrate with the larger organization and take their small app. to the entire company.

First Principle
Even if no one provides a set of big rules for you to follow when you are designing an application, it's helpful to be able to articulate *"how"* you build something. The first principle should always be that at some time, someone else will need to use what I (we) have just made. Even if this thing is a small one-off to solve a very specific problem.

​Someone else will need to use what I have just made.

 This applies even if what you are developing is only for your use. At some point, you will want to look at it again to help solve another problem and having clear documentation will be invaluable. These rules don't apply only to traditional code either. Being able to understand the data and business logic in an Excel spreadsheet can be extremely difficult. I can't begin to count up the hours I've spent trying to find an old spreadsheet only to spend more time trying to decipher a bunch of nested links.

So, let's assume you are a developer for a large global IT shop building a great product for a small set of users in some regional data center. Your managers have done a great job convincing their managers that everyone in the company should be using your application. As a developer, what could you be doing to help move this project along?

I think the following list is a good set of guidelines for building anything you (or someone else) might need later. 

At some point …
1. Someone else will need to access your data
You need both a GUI and an API.

2. Someone else will need to see your documentation
The GUI and API must be obvious.
The API must be self documenting.

3. Someone else will need to reverse engineer part or all of your application
The code must be easy to figure out.

4. The incoming data will change
Validate everything coming in.
Validate everything going out.
    
5. The outgoing data will need to be changed
The code must be easy to change.

6. The business logic will change
Make configuration changes not code changes. 
Test everything based on the outcomes of the business logic.

The bottom line is simple. Make it as easy as possible for someone else to use what you've made. -Click to Tweet