How to Run a Successful IT Development Practice

Posted in: Blog, Methodologies, Project Delivery | Jan 16, 2013 at 10:42 AM

No comments

INTRODUCTION

In this article I want to talk about running a successful development practice. I will list the tools and automation that you can use to ensure that your development practice runs smoothly.

THE TOOLS

The tools we need are:

Development environment, testing environment, UAT environment and production environment. If possible ALL environments are configured with the same spec and settings. Otherwise, the least you have to do is UAT and Prod are configured with exactly the same spec and settings.

Development environment is where the developer does the work. This environment should be personal to the developer. Why? Because when a developer needs to perform a server restart or SQL service restart, debugging, etc it will not affect other developers.

Testing environment is where alpha testing (ie. internal testing) takes place. If you have multiple developers working on a project, you will need to check-in the code and test the integrated code. This is the environment to do it.

UAT environment is where user/client testing takes place. Once the alpha testing passed, the code is now ready to be deployed for UAT testing. This is the environment to do it.

Production environment is the LIVE environment where the application is used by the entire client organisation.

Why – ideally – do we need to configure all environments to have the same spec and settings? This is to eliminate any risks of the code works in one environment but not the other. I know though that this is probably too much to ask since resources ain’t cheap. Therefore, if you can’t configure all environments to have the same spec and settings, at least UAT and Prod are configured the same. This way, if the application passes UAT, it will also pass Production.

When I say “configured exactly the same”, I literally mean “configured exactly the same”. Meaning, the topology has to mimic (eg. if Prod has 1 server in DMZ, 1 server internal and 1 DB server, the UAT needs to be the same). Any third party applications that you may install need to be of exactly the same version. Don’t install V1.0 in UAT then V2.0 in Prod otherwise you are introducing a risk.

Source control application

This is what has always been missing in most of my clients’ organisations especially if they are not an IT consulting organisation. You HAVE TO HAVE a source control application where you can version, check-in/out your code into. Otherwise, you may risk yourselves of losing your source code.

The source control app I often use are Microsoft Team Foundation Server, Microsoft Visual SourceSafe and SVN Server. There must be others but as I work mostly with Microsoft technologies, the above are the ones I normally use.

The source control application you use needs to have the ability of check-in, check-out, versioning, labeling, branching and merging. You need to be able to identify which version of code is currently deployed in which environment. If your source control application is not supporting these functionalities, you better find another one.

Development IDE (Integrated Development Environment)

Do you have a proper IDE such as Visual Studio? There are many others such as Sun One, etc but the ones you’re looking for are the ones that can debug your code and also provide you with good text-editing functionalities. The good one can also label different part of the code with different color which makes it easier to read.

I used to develop HTML in Notepad but not anymore. It’s all black-and-white which makes it harder to read. Ensure you have a good IDE so that you can work efficiently.

Task and bug tracking application

You need to use task and bug tracking application. This way everyday you can always track how your application is performing and also everyone in the team knows that he/she needs to do.

I use Team Foundation Server and Team System Web Access mostly as it allows me to assign task and report bugs easily. There are a lot of open-source ones that you can download for free.

Common methodology and best practices

Do you follow a development methodology such as Agile Development Methodology? It is good to follow a particular methodology because it helps you keeping things in order.

How about MVC, MVP, design patterns? Do you follow any of these?

I also often use Microsoft Enterprise Library for all my “standard ground work” such as logging, encryption, etc. Do you have a common library that you use for development?

When everyone in the team uses the same standard, although the way they code may look different, but at least your application is a lot more manageable.

Deployment process and procedure

When it comes to deploying your code, do you have a standard deployment process and procedure? This is useful to avoid “cowboy”-style deployment where your developers can just deploy whenever they like.

Some of my procedure is:
– Deployment Change Request document needs to be created and signed off by the client
– All deployment to UAT and Prod need to be done after hours and only on Tuesday and Thursday or any hour on the weekend (Saturday and Sunday);
– Deployment to UAT and Prod needs to be communicated to the business at least 24 hours prior to the actual deployment;

Timesheet application

Do you run a timesheet application? A lot of my clients are using paper-based timesheet. Nowadays there are a lot of web-timesheet application that you can utilise. This is important to track budget.

A paper-based timesheet will create more overhead than anything because you then have to re-import all the hours to a separate spreadsheet, etc.

Ticketing and support application

You may also need a ticketing application especially if you are running a help-desk practice. This application allows you to track all phone-calls or support requests and attend to them appropriately.

Do NOT let the employees of your client’s organisation to talk directly to your team members. Always force them to use the ticketing application. This way you can assign tasks to your team members in a more manageable way.

Shared directory

Do you have a shared directory where all your downloaded applications are located? This is useful so that your team members don’t have to keep downloading applications that may have been downloaded previously.

I also use it to share movies and other interesting documents 🙂

Project documents storage (ie. document management system)

I use something like SharePoint to store and share the project documents. Use a similar system so that your team members can always refer to these documents (eg. Business Requirements, etc) anytime without bothering you.

THE RESOURCES

All in all a successful development practice depends on the resources themselves ie. the developers and you as the manager. Look for someone who is easy to work with and not the one who always wants to do things his own way.

The pitfall is normally: the smarter and more experienced someone is, the harder to work with. Therefore, during the interview ensure that the person can work with your methodologies and procedures.

Do things that can tighten the bond within the team such as Friday lunch or daily coffee break. It is very important to keep the morale high. You can also send jokes around.

Get everyone in the team to present something interesting once a month or once a week eg. new technologies, etc.

CONCLUSION

Running a development practice should not be that hard but you have to have the right tools and methodologies.

Feel free to add more items in this list.

No Comments Yet.