How can we improve our development environment in a small team ?

Question

Since 1.5 years, I am a part of a relative small development team with less than 5 developers (not all of the team members are stable and some have left the project during the time I was here). We have a project manager and a parallel team of 3 people who do mostly business stuff and customer care, occasionally testing the software before the release.

From what I have learned in books, at stackoverflow etc. it has been clear to me that we do a lot of things wrong, let me give you some details before I formulate the question :

+

1. We have introduced the TFS source control and integrated build, we have a deployment machine where the latest version of sources always resides and everyone can play with it.
2. We have a relatively smart way of handling the database versioning with transformation scripts that are automatically executed as a part of the build process.
3. We track bugs and tasks in a SharePoint-based portal, we have a quite stable workflow of resolving them and later closing them when somebody from the business team tests them.

-

1. Apart from manual testing done by the guys occasionally, which is by no means exhaustive, we have absolutely no reliable unit or integration tests and with a relatively huge code base it seems quite problematic to introduce any (with so many dependencies already in place it's hard to write dependency-free testable code)
2. All the developers in the team have their area of responsibility, which is mapped to an area in the code where they are frequently the only person who understands the requirements and the way they are implemented in the code. With a lot of junk in the code it also means that when somebody leaves the team (it has already happened), we have a lot of junk to maintain.

If there are any things I have forgotten, please give me feedback so I can complete them. Now me being one of these developers I have only limited power to actually make anything better, but I am interested in what you think are the most critical things and possible solutions from my position and overall.

Answer 1

http://stackoverflow.com/questions/438530/improving-our-dev-environment-at-work

I'd improve at testing, i.e. add unittest execution to your build process and activate "stop on error".

Answer 2

From your comments about TFS and database versioning, it sounds like you are in a pretty enlightened environment, and that people will be open to process improvements rather than going "you're paid to write code, shut up and get on with it."

Assuming that, I'd suggest that getting more and more of your system under automated unit and integration tests would be the most critical thing. This obviously addresses your point 1, but would also I think help with point 2. Once you have automated tests for a part of the system, those tests to a great extent define the requirements, and they constrain the implementation. So if the owner of Area X leaves and you have to do some work on Area X, your lack of expertise in Area X is less dangerous because the tests will let you know if you make a mistake.

I know this is intimidating for a large, complex and dependency-ridden codebase, which is how you seem to see yours. Sure, it's not something you can or should try to do overnight. But you can pick off bits as you maintain them. You are not alone: techniques exist for breaking dependencies, breaking big bits of code down into smaller and more testable ones, etc. Go buy Michael Feathers' Working Effectively with Legacy Code. It is an awesome resource for progressively getting the kind of codebase you describe under test -- very practical, very pragmatic, very aware of the difficulties of dependency-ridden monolithic systems -- and largely the kind of stuff you can do yourself even if your other team-mates don't immediately buy in.

Answer 3

Adding automated unit testing would clearly be a big win in the short term. It would allow others to attempt to modify legacy code with more confidence because of unit tests supporting them.

In the long-run, you might consider doing design and code reviews and at least writing some minimal design documents. In my own team's experience, having to explain the design and code to another developer always improves the code. This isn't new: the Subversion team does the same thing to reduce the risk of a developer leaving the team and taking critical knowledge with them.