There is much discussion online about how an over abundance of processes can kill a web development shop. Developers and designers get choked under a plethora of ‘Gather these requirements using this form’ and ‘Estimate your hours using this form’ and ‘Structure your project files this way’. I don’t disagree that too many of these types of processes can turn into flashes of Lumberg asking about your TPS Reports. But what about the opposite problem? What if there are no processes?
Imagine this: Your supervisor resigns, and you are placed in charge of of all of her/his projects. Two weeks later, the Globex Corporation calls. Your company designed Globex Corporation’s website like 5 years ago. Globex needs to update the email adress that receives the Contact Us form on their website. So, you grab the latest version of Globex Corporation’s code from source control and start digging through the code, looking for the email address. It turns out that the email is hard coded in three different places. You update it, and start to look for the stage and production versions of the site. After combing through the six possible servers they could be on, you discover that they are in fact of a seventh server you didn’t even know about, and stage and production are different from what’s in source control. They were updated without the changes being committed to source control.
You see where I am going with this. So, some processes need to exist to ensure that different employees are all doing things the same way, and so that everything is documented. In fact, I would say that documentation might be the one essential process. The one you really can’t do without. When documenting, I try to envision just such a scenario. If a totally new person needed to pick up my project, how difficult would it be for them to find everything and figure out whats going on with the project?
At eCity we have begun creating an internal application to prevent some of these problems from arising. This could of course be done with a simple spreasheet, but the more we dug into the problem, the more an application makes sense because this can quickly become a deep, deep rabbit hole.
First, we just wanted a list of sites we have worked on. And, this list should probabaly contain credentials for accessing all the resources associated with the site. But, when we thought about it, a lot of this information is duplicative. Site A and Site B are hosted on the same server. We don’t want to have to document the server information multiple times. And, really, we want to quickly and easily see a list of what other sites are on any given server. It can get complex quickly.
The entities we forsee in the project so far are:
- Site
- Server
- Hosting Company
- Database
- DNS
- All of these entities’ associated credentials
- User management
- A password manager of some sort for storing credentials to accounts not associated with a specific website
Having this application does not ensure that any of the information will be completed by the appropriate parties. This will require management buy in. But, if a situation like the one described above ever happens and you dont have a system like this in place, you should get management buy in pretty quickly. Even so it will take diligence from all parties involved to keep things up to date.
Building an internal app takes time, time that you really might be spent working on a paying client’s project. But not having this information can be costly. It’s worth the time. This application will help our team work more efficiently, it will help smooth future staff transitions, and will ensure that those old projects that suddenly creep out of the woodwork will not require hours and hours to recreate.
