Geeks With Blogs
CodeSeeker Just another developer trying to do the right thing

My group is pretty immature as far as anything like CMM(I) goes. We are only a couple steps ahead of complete chaos, which is pretty darn bad. So how do you get from chaos to order? What are the first steps to take?

I'll speak from my own experience over the few months that I've been in this group. A little history: at my last job, the process was more mature. There was only one project, a large one. It was managed pretty well, and everyone was working on the same codebase with the same tools, etc. At this job, management is much weaker, partly due to their skills, partly due to the culture, and partly due to the fact that some of the time they're still doing development tasks. There are many small projects, not just a single one, and they are written in different languages (although primarily VB and ASP, .NET 2003/2005 or earlier). The skill levels of the team members vary from "I'm not a programmer" to myself and one other person who knows that polymorphism has nothing to do with Optimus Prime.

The first thing that was important was to institute the consistent use of source control. The group had Visual SourceSafe (VSS). Better than nothing. I raised awareness of the need for source control, had a couple training sessions, got it installed on everyone's box. (I will leave source control best practices to another post.)

The next thing was to separate the development environment (DEV) from the production environment (PROD). If the developer is really industrious, we even have a TEST environment. This way, the user may make changes to the application that don't affect the production application and can be methodically deployed to the production environment.

I hope to soon institute application versioning for all applications using both a value in the source code itself (I like using web.config) and a label in VSS (in the future we can also incorporate a version number into the corresponding database) so that we can communicate to the user what the current version of the application is as well as return to a previous version of the application should the need arise. We can also support multiple versions of the application in the various environments. We might have a few versions of the application deployed to the TEST environment before we go to PROD with it.

Also as we migrate to Team Foundation Server (TFS) (fingers crossed), we will be restructuring the application directories such that any files not used to compile the application (documentation, etc.) will be in a separate folder than the source files off the root of the project. This will facilitate automated builds and deployment (another future goal).

We are starting to formalize the process of creating and working a ticket (bug, enhancement, etc). We are almost done formalizing our status sheets (which may go away after implementing TFS). We can then formalize the procedure for working with VSS, and then versioning and deploying to the TEST and finally, PROD environments.

A key ingredient that is just getting off the ground is the documentation and publishing of the standards that are developed. A lot of ideas come up in meetings and in the hallways, but unless there is a way to capture those ideas, they are wasted. We are waiting for the Internet group to give us access to the SharePoint Wiki, so until then I have created our own, simple HTML website with the information to be published.

I personally see these items as being the first steps in improving our software process because they are so essential to the "bottom line", which is reliable production applications and "CYA". Your challenges may be different, but I'm sure these are in your top 10.

(While I'm thinking about it, here is a great article on the topic.)

We need to learn how to break down problems into small pieces and work on (and check in) one thing at a time. This allows for better task management, scheduling, and a lower risk to each individual change.

We need to document more. A lot more. Each project needs to be deconstructed to the extent that it can be functionally reproduced in its entirety from the documentation. The documents don't need source code, just how it works. Requirements. We should also document how it looks. Design.

Another thing to look forward to in TFS is database versioning. I don't know all the details yet, but apparently it can version the schema, and hopefully it can version the application metadata. The way I have personally been doing this so far is just creating CREATE scripts out of SQL Server Mgmt Studio and saving them as text files in a directory within the project, then updating them prior to each new version.

I hope to add more on this topic in the future. Stay tuned! Posted on Wednesday, July 25, 2007 4:28 PM | Back to top

Copyright © Mike Ellis | Powered by: