The reason you should start to professionalize your development department is that your team will work faster and produce less bugs. In my job at eFuture I focused mainly on this topic. Even though we implemented the following on a PHP development team, I hope this document will help to achieve a professional IT-department in general.
Have frequent IT-meetings
Meetings are essential to get things done within your department. They will improve communication between developers. When you want to start with your frequent meetings, apply the following basic rules:
- Create a format; without it, your meetings will become a mess.
- Keep track of time; after one hour the level of concentration will be low.
- Early topic announcements; let attendees to prepare themselves.
When your developers are used to meetings, you also can give product-presentations. This will not just improve communication within your department, but it will also improve communication with other department or clients. To prepare developers for product-presentations, start off with simple internal presentations at the end of some part of development: “look at this new feature I developed” .
Whatever meetings you decide to have, you will see your department will function better with than without them.
Write all kinds of documentation
There are several kinds of documentation which all are helpful to improve your companies products. Some of these documents are essential to achieve a better performing IT-department. For short, the following types should at least be created:
- In-line documentation or Doc-blocks; helps understanding parts of the code without reading the code itself (it might also appear in developers IDE’s).
- Technical documentation; how is the application build.
- End-User documentation; how should the application be used.
- Wiki or wiki-like system; about development, database recoveries, managing crashes or other knowledge that’s relevant to share.
Create a backlog
There is no such thing as bug-free software. Keeping track of these bugs is very easy. You can use a bug-tracker or tickets-system to store bugs that appeared within your products. The system you decide to use, should also be accessible to end-users because they probably are the ones that will find bugs. The tickets or bugs together are considered a backlog; which can be used for the next release or patch.
Use a version control system
The main reason you should use version control is that when deployment fails you can go back to the last stable release and fix your code without stress. Even when just one developer is working on an application, it is vital to have some kind of version control system like SVN or GIT. Remember that version control helps you with the following issues:
- Allow multiple users to work on the same files
- Review the code that is added or changed
- Revert code on errors or bugs
- Spot bugs that emerged during development
Create software release cycles
It is very stressful to “develop-test-release-deploy” for each bug that is solved or feature that is created. Instead you should gather some changes or fixes and bundle them in a single release. When you do so, it’s more likely you will be guided by the time to release your software. This approach is called a release cycle. It is cost reducing and is transparent for clients; they know when the next version is released.
Test your application
Software should never be deployed without testing it first. This means you should never allow your developers to edit online!
There are several types of tests: code reviews, performance tests, end-user tests, etc. Each application should at least been approved by doing an end-user test that contains the core functionality. This end-user test is best written before or during the development. You should record the outcome of each test, so they can be approved before releasing.
Finally, what else can you do?
If you’ve managed to implement all that is written above, you can still improve your department. Do you have any kind of coding standard? Does anyone do code reviews? Or what about Agile development, or test-driven-development? I think you and your team can professionalize yourself even further. Just use one of your meetings to talk about it.